Thread: Double Buffer my DOS program??

I am using graphics.h to make a DOS program, and like in a windows program I have it draw frames to the screen. And like in any windows program it goes all flashy. The only way I know of fixing this in windows is by Double Buffering; can you do that with DOS' graphics.h? Or somthing similar? Thanks for any help you can provide.

For a console program, no you can't.

For a DOS program in a DOS session, yes you can, but only for certain modes.
For a DOS program in PM using a DOS extender, yes you can but XP will be your worst enemy.

But I have no idea why you would want to.

Can't PDCurses do something like this?

If you are using graphics.h then stop. It is harder to use than just accessing the hardware. The starting memory location for mode 13h is A000:0000 and CGA is B800:0000.

You will need to create a memory buffer than can hold 320*200 bytes or 64000 bytes. Then create a FAR pointer to video memory. It is FAR because A000:0000 will lie outside of your program's segment.

Draw to the memory like this:

Buffer[y*screen_width+x]=color;

Where color is an unsigned char. When you want to double buffer memcpy from the buffer to the FAR screen pointer. You can also use inline assembler for this and may want to given that Turbo C is very old.

Code:

void Flip(unsigned char *pSource,unsigned char far *pScreen)
{
   asm {
      push ds
      lds si,[pSource]
      les di,[pScreen]
      mov cx,32000d
      rep movsw
      pop ds
   }
}

You can also just use memcpy() if you want to.

Better than this why don't you just use DirectX or OpenGL?

Thanks for the replies, but I've decided junked this project; while running one of my compilations my computer blue screened, then wouldn't start. Thankfully it was a temp thing for the first next startup. To dangerus!

Shouldn't the first pointer in Flip also be far, judging from the assembler-code?

Yes, it probably should but I recall having problems under Turbo C by declaring either the screen or the buffer pointer as far. It would simply crash. Not sure why since video memory is most assuredly not in your program's segment and the buffer cannot be in your segment since it's size is 64K which is the size of a segment in real mode. So yes technically they both should be far pointers.

However by using the assembly code you can bypass this issue because lds and les by nature load the segment registers. As long as the addresses in them are addressable by your code then it will work.