VOGONS

Search

Common searches

How does DOSBox know when to swap screen buffers ?

Topic actions

First post, by tigrou

Posted on 
User metadata
Rank Newbie
Rank
Newbie

I ran the following program in DOSBox (it display a spinning 3D cube)
I was surprised to see that FRAPS can report very precisely the number of FPS (probably because it hooks page_flip() or vsync() methods of DOSBox).

Program source is available in the zip file and if you take a look at it, you will see the only thing it does each frame is to call a Flip() method which to copy one buffer to another using rep movsw. There is no vsync call. There is also one Cls() call, but it is similar to Flip() : it set to zero all bytes of the screenbuffer.
So my question is : how does DOSBox detect when to do the swap the screen buffers ? if there is no swap (and no vsync as explained earlier), how can Fraps calculate the FPS ?

Reply 1 of 4, by Scali

Posted on 
User metadata
Rank l33t
Rank
l33t

There doesn't need to be a vsync-call.
I assume the rep movsw is just copying data from a temporary buffer to the actual simulated framebuffer. You still need to perform some kind of action to get it on screen (as in the native OS screen), depending on what renderer you choose (GDI, DirectDraw, OpenGL etc). So that's where you need to look.
(Fraps obviously measures the FPS of the DOSBox window, which is not necessarily the same as the DOS program running inside it).

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 2 of 4, by tigrou

Posted on 
User metadata
Rank Newbie
Rank
Newbie

You still need to perform some kind of action to get it on screen

AFAIK In DOS mode 13h (320x200 256 colors) you don't need anything, as long as a byte is copied to 0xA0000 it will show up on the screen.

How DOSBOX know there is something to blit ?
Is there a routine called periodically (eg : 70 times per second) and if DOSBOX detect there has been any write in 0xA0000 - 0xB0000 range, it will blit the surface ?

Reply 3 of 4, by ripa

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

Look into vga_memory.cpp and the page handlers. There's some kind of caching that detects which video areas are updated. Dosbox draws those every for emulated frame. Relevant code: VGA_SetupDrawing, RENDER_StartUpdate and EndUpdate, GFX_StartUpdate and EndUpdate...

Reply 4 of 4, by Scali

Posted on 
User metadata
Rank l33t
Rank
l33t
tigrou wrote:

You still need to perform some kind of action to get it on screen

AFAIK In DOS mode 13h (320x200 256 colors) you don't need anything, as long as a byte is copied to 0xA0000 it will show up on the screen.

As I said, the 'native' screen, the DOSBox window (that is what Fraps measures, it doesn't know anything that goes in inside the emulator).
0xA0000 is an emulated piece of memory. The emulator needs to convert it to an OS window and put it on your physical screen.

tigrou wrote:

How DOSBOX know there is something to blit ?

It doesn't, and it doesn't need to know.
It simply emulates the hardware. The hardware outputs images to the display at a fixed framerate (70 Hz for 320x200 VGA mode). That is what it simulates. It basically takes a 'snapshot' of videomemory at a fixed framerate, and blits that.
On real hardware you basically get the same effect: The RAMDAC just sends the pixels from the frontbuffer to the monitor left-to-right and top-to-bottom. Whatever pixel is in memory at the moment the RAMDAC gets there, is displayed.
Which is why you would get tearing when you don't apply vsync to your frontbuffer updates.
DOSBox does not emulate this very accurately though (as in: not at all when you use SVGA, and only on a per-scanline basis when you use VGAONLY).

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Go to top of page Go to top of page
Back to DOSBox Development
Close window
Close window