Double Buffer my DOS program??

This is a discussion on Double Buffer my DOS program?? within the C++ Programming forums, part of the General Programming Boards category; I am using graphics.h to make a DOS program, and like in a windows program I have it draw frames ...

  1. #1
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,691

    Exclamation 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.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  2. #2
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    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.

  3. #3
    Registered User nempo's Avatar
    Join Date
    Aug 2007
    Posts
    39
    Can't PDCurses do something like this?

  4. #4
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    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?

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Modern graphics doesn't use the method of copying the content from one frame to another, but rather just moves the pointer to the frame-buffer within the graphics memory. This is hardware specific, but with OpenGL or DirectX, it's hidden from you and "just works". Much easier.

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

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #6
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,691
    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!
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  7. #7
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,598
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 8
    Last Post: 04-25-2008, 03:45 PM
  2. Copying 2-d arrays
    By Holtzy in forum C++ Programming
    Replies: 11
    Last Post: 03-14-2008, 04:44 PM
  3. Need some help with a beginner functions program!
    By nelledawg in forum C Programming
    Replies: 5
    Last Post: 03-03-2008, 07:05 AM
  4. C++ to C Conversion
    By dicon in forum C Programming
    Replies: 7
    Last Post: 06-11-2007, 09:38 PM
  5. Conversion From C++ To C
    By dicon in forum C++ Programming
    Replies: 2
    Last Post: 06-10-2007, 03:54 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21