GDI Vertical blank and vertical retrace test

[Siekmanski]

I managed to get access to the video card rasterizer, hope it works on other cards too.
Next step is to implement a nanotimer interrupt and sync it with the monitor refresh rate and vertical blank so we can blit the backbuffer to the frontbuffer inside the vertical blank period. ( prevent tearing )

Made a small test proggy to see if it gets data back from the video rasterizer.
Simple test with (Sleep,20) as timer used here, thus no synchronization yet.
Have to learn more about GDI also.

Can you guys give me some feedback if the rasterizer gives data back to the screen?
Does the "Inside Vertical Blank" flip to 1 now and then and is the "ScanLine number" running?

[Lonewolff]

Arrgh! Another one.



Do you UPX your exe's also?

[Siekmanski]

No, didn't use a resource.  but it's safe  :t

[Lonewolff]

No, didn't use a resource.  but it's safe  :t

This is what it shows for me

[Lonewolff]

On a side note, I wonder if you built using the latest libs whether you'd bypass the virus flagging issue.

I used to build all my programs with VS2003 until a few years back. But people were reporting false positives. After I switched to a newer version of VS the warnings went away, even though I was using the same source code.

[Siekmanski]

No, the Masm32 libs.
Did you see the "Inside Vertical Blank" flip to 1 now and then and is the "ScanLine number" running?

[Lonewolff]

Yeah scanline number is incrementing rapidly.

Not catching any change with the vertical blank number. Maybe it's happening too quick to see?

[Siekmanski]

Yes I think so, will see.

[LordAdef]

Hi Marinus,

Scan lines seem to run up to 9.??? (too fast to know)
Eventually, there is a flicker in the letters, and occasionally Inside Vert blank flips into 1, but very briefly and then returns to 0

[Siekmanski]

Thanks guys.

[avcaballero]

Hello, here is what I have proved, all of them with TinyC:

- FloorWC01. Bucle con GetMessage and SetTimer(20)
- FloorWC01b. Bucle con PeekMessage and SetTimer(20)
- FloorWc01c. Bucle con PeekMessage and GetTickCount and boolProcessing.
- FloorWc01d. Bucle con PeekMessage and WINMM timer and boolProcessing.

I cannot see any difference between them regarding flickering :lol:, but the first one is much more light weight than the others, so I can not see any reason for using PeekMessage.

I guess that one can not achieve 100% of flickerless in any system. It depends on the demo presented and the the system load at every moment. Of course is mandatory that the sucesives frames join well, otherwise you will get flickering with no doubt.

I have thought on using parallel threads to have data prepared when required with the hope of reducing the elapsed times between free buffer and data filling that could produce flickering, but I do not want to keep on trying, I prefer the first version.

[Siekmanski]

Hi Alfonso,

Sad to say, the demos won't run on my Win8.1 machine.

I guess that one can not achieve 100% of flickerless in any system. It depends on the demo presented and the the system load at every moment. Of course is mandatory that the sucesives frames join well, otherwise you will get flickering with no doubt.

I don't know exactly how the graphics pipeline works in GDI.
It seems to me that the painting procedures are stored in some kind of an event queue or something, controlled by BeginPaint and EndPaint. ( don't know enough of GDI yet, still have some reading todo. )
If I'm right and we own the window (like in DX9), you can paint immediatly using the window hdc and skip BeginPaint and EndPaint.
But, blitting to the window must be in sync with the monitors refresh rate, this is the thing to tackle, prevent tearing. ( preventing tearing, I think this is the task for BeginPaint and EndPaint )

Alfonso, you are using a timer routine, that does the blitting to the window every 20 milliseconds.
This is out of sync by 3.333 milliseconds with a 60 Hz monitor refresh rate what causes the stutters because now and then you'll skip frame updates.
Just to prove this for yourself, try 33 milliseconds in your timer and see if the stutters are less frequently or not.
Yes, you will skip every second frame but it is more in sync with the monitor at 30.303 Hz, this is of course only a test case.

My ideas to prevent stutters in GDI are these steps:

1. Start a 16.666666 millisecond ( if the monitor refresh rate is 60 Hz ) nanotimer interrupt thread.
2. Wait for the Vertical blank period to start. ( think I got that covered, still have to prove it behaves well )
3. Switch buffer pointers. ( I will use 2 backbuffers )
4. Send an event to the routines thread ( on another core if possible ) so you can start immediately with your routines again, hence the 2 backbuffers.
5. Blit the finished backbuffer to the window. ( we are inside the Vertical blank period, there will be no screen tearing if the blit finishes within the Vertical blank period. )
6. Adjust the nanotimer interrupt with 100 nano seconds slices up or down for the next interrupt. ( synchronize it with the Vertical blank. )
7. Clear the just blitted backbuffer if necessary.
8. Goto step 2.

If this all works out, GDI drawing will be as smooth as DirectX and OpenGL I hope.

[LordAdef]

Guys, I'm following this discussion.

And if any of you manages to get a nice gameloop routine to achieve this 60FPS please share with me. I made one but didn't seem to work as expected. I wouldn't mind getting one as a friendly help, so I can carry on.

[Siekmanski]

 If it works 100% correct, I will post the sources.

[LordAdef]

If it works 100% correct, I will post the sources.

Thank you my friend. By the way, mine was that one where I mixed integers in registers and FPU. We've been through that