More on FPS

Yesterday I wrote some test code that instead of updating the backbuffer memory directly, like HH does now; uses a offscreen memory buffer, the size of the screen, for the pattern, and just present it to GDI, using BitBlt.

( EDIT: What I mean here, is that I put the other offscreen buffer, first into the BackBuffer, and then the text, and then the final thing (graphics + FPS measurement (drawtext)) to the frontbuffer. If I skip the step for the backbuffer, and end up doing 2 calls to the frontbuffer, I lose 60 frames/s (gdi)).

I could then get a framerate of about 260 frames. Because the pattern is updated only once. This is HD (1920x1080) on a 4 years old graphics card.

I also tried it in DirectX9, and that gave me a wooping 3500+ FPS.

I have a question. Will the monitor, running at 60hz never be able to display more then 60 of these?

If so, then there looks like there is ample time even in GDI to make a small game. I tried also with several buffers, just to test. I tried 100! HD buffers, (800 megabytes) and the framerate was still the same! (showing 1 at the time, but a different one, each frame)

So that means you can do many simple games just for GDI now?

Edited by Livet Ersomen Strøm on
Yes, the monitor refresh rate is a hard bound on how many frames per second you can show. If you want more than that, you would have to "tear", if the display supports it (showing many frames on one screen by switching which frame you're showing depending on the scan line), which is probably undesirable for most things except devices specifically designed for this (such as potentially VR headsets, which have "rolling judder" - see http://blogs.valvesoftware.com/ab...the-vr-rabbit-hole-fixing-judder/).

- Casey