GDI Vertical blank and vertical retrace test

[felipe]

In this second computer with a resolution of 1280x1024 (and windows 8.1):

The format is fine now (no lines overlapping).

average VerticalBlankPeriod: 0.670040437 miliseconds.
average MonitorFrequency:60.018938442hz.
PixelFormat ?? (Type):22 Firts frame, vertical blank 0.667589508 ms, Frame delta 16.656695063 ms.

Btw, i like to see those numbers moving so fast. 

[LordAdef]

Marinus,

I've got an old laptop running XP. If no one tested, I could get it running and I'll test it for yoh

[Siekmanski]

Marinus,

I've got an old laptop running XP. If no one tested, I could get it running and I'll test it for yoh

I would really appreciate it, many thanks in advance.  :t
XP is not tested yet.

[LordAdef]

I'll do it, no problems!

[Lonewolff]

Windows 10  :t

[FORTRANS]

Hi Marinus,

Marinus,

I've got an old laptop running XP. If no one tested, I could get it running and I'll test it for yoh

I would really appreciate it, many thanks in advance.  :t
XP is not tested yet.

   My XP laptop said; "GDIVERTI.EXE has encountered a problem
and needs to close.  We are sorry for the inconvenience."  And goes
on like that for quite a bit.

   Do I need to download a DLL or some such?

HTH,

Steve N.

[Siekmanski]

Hi Steve,

Not that I'm aware of.
The test program continuously polls the Vertical blank signal using all the CPU resources of the thread it is running on. (this will be reduced to 1 poll per screen refresh rate in the final routine)
15 years ago I made an attempt using this same technique, back then there where video cards that didn't support that function too.
I'll see if I can check the capabilities of the video cards and report if it supports polling the Vertical blank signal.

Thanks for the report, almost forgot about this issue.

[daydreamer]

Hi Steve,

Not that I'm aware of.
The test program continuously polls the Vertical blank signal using all the CPU resources of the thread it is running on. (this will be reduced to 1 poll per screen refresh rate in the final routine)
15 years ago I made an attempt using this same technique, back then there where video cards that didn't support that function too.
I'll see if I can check the capabilities of the video cards and report if it supports polling the Vertical blank signal.

Thanks for the report, almost forgot about this issue.

is it possible to use two cores/two threads and use LOCK prefix to synchronize
or some other way to backbuffer ->screen copy so that it doesnt flicker?
one thread is drawing,second thread is checking Vblank and scanline
maybe start/stop workerthread when vblank/notvblank?

[Siekmanski]

That's the plan, 1 backbuffer that blits to the front buffer while the drawing starts immediatly at the second backbuffer, using 2 threads each on another core.

http://masm32.com/board/index.php?topic=7075.msg76192#msg76192

[FORTRANS]

Hi,

   Ran the program on another notebook with WinXP to see if
changing the video chipset makes a difference.  It did not, same
error occurred.  ATI Mobility Radeon in the first, Intel in the second.

Regards,

Steve N.

[LordAdef]

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 )

Marinus, you don't need BeginPaint/EndPaint. I was cleaning my code logic and spent some time researching this. Game develpers do paint outside ==Paint. It's in fact how I am doing right now. I set my window as OWNED, so we can freely paint to it.

[avcaballero]

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 )

Marinus, you don't need BeginPaint/EndPaint. I was cleaning my code logic and spent some time researching this. Game develpers do paint outside ==Paint. It's in fact how I am doing right now. I set my window as OWNED, so we can freely paint to it.

How interesting, an example, please

[LordAdef]

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 )

Marinus, you don't need BeginPaint/EndPaint. I was cleaning my code logic and spent some time researching this. Game develpers do paint outside ==Paint. It's in fact how I am doing right now. I set my window as OWNED, so we can freely paint to it.

How interesting, an example, please

Sure! but in the mean time, have a look at the link I provided of Casey Moratori's C game (the thread of references I posted here at the gave forum). He is one example, ==PAINT is only used to refresh the gui. the whole game is rendered outside the win message. It's called from the game loop.


I am doing this way and I find the blt to be more steady


Are you in win10? My code is currently broken for win 7. If so, I could post it for you

[avcaballero]

W7 here, but you could post it here any way and we may have a look to it.

[Siekmanski]

Own the window,  wc.style, CS_HREDRAW or CS_VREDRAW or CS_OWNDC
Call your routines from the timer and the hdc from the owned window
Don't use WM_PAINT, BeginPaint and EndPaint
Don't use InvalidateRect

I have tested this and it works ( although still without a backbuffer )