![]() |
|
vsync |
23yrold3yrold
Member #1,134
March 2001
![]() |
Tearing is when you do a screen update between screen refreshes. So the bottom of the screen looks like the current frame and the top of the screen looks like the last frame. They don't quite match up in the middle (or whereever), so it looks like the screen is "torn". vsync() is the standard way to avoid that. Page Flipping and Triple Buffering work too. -- |
gillius
Member #119
April 2000
|
Yep, that's right. If you really want to see it, I'll bet you might be able to exaggerate the effect by blitting two opposite colors every other frame, without vsync on, and turning your refresh to its highest rate (something I've noticed, maybe wrong, is that the faster your computer and the lower the refresh, the less tearing is visible.) Gillius |
Richard Phipps
Member #1,632
November 2001
![]() |
It's not so bad with a static display, but any kind of scrolling shows the effect up badly. |
Thomas Harte
Member #33
April 2000
![]() |
Quote: But "how fast the game runs when not restricted (...)" ? If your screen has a rate of 75Hz, displaying more than 75 frames per second is NOT faster, it's only more CPU/memcopy stress... Don't get started on this, you'll be surprised how many allegro.cc people completely disagree without any logical reason whatsoever. On the topic of vsync, Allegro implements this on win32 via: /* gfx_directx_sync: * wait for vertical sync */ void gfx_directx_sync(void) { IDirectDraw2_WaitForVerticalBlank(directdraw, DDWAITVB_BLOCKBEGIN, NULL); } It completely ignores the return result, which may be DDERR_UNSUPPORTED (i.e. your video driver does not support vertical sync) or, assuming Allegro overlaps drawing when possible, DDERR_WASSTILLDRAWING. Just from DDERR_UNSUPPORTED, it is perfectly possible that vsync() is doing absolutely nothing. In this case, Allegro simply wouldn't tell you. So, if a user writes asking why your game features completely torn up graphics and runs at a stupid rate, vsync may well be to blame. If Allegro overlaps drawing, then vsync() may do absolutely nothing on any card without Allegro telling you, depending on the timing of the last blit to the primary surface and the timing characteristics of that card. If Allegro does not overlap drawing then it is probably a substantially slower library than it needs to be. Moral of the story: don't use vsync. Use 'page flipping' (to stick with the Allegro community orthodoxy for naming) instead! [My site] [Tetrominoes] |
Derezo
Member #1,666
April 2001
![]() |
Quote: you'll be surprised how many allegro.cc people completely disagree without any logical reason whatsoever. Well, they're just plain wrong. Page flipping is nice, but can be much slower. "He who controls the stuffing controls the Universe" |
Thomas Harte
Member #33
April 2000
![]() |
Quote: Page flipping is nice, but can be much slower. Well, as the page flip is all but free, I don't see any performance difference between preparing everything on a memory buffer and blitting it to an unseen video surface, then making that video surface the front at next vertical sync through one function call and preparing everything on a memory buffer, waiting for vsync through one function call then blitting to the seen video surface. Certainly using two buffers in video memory is much more likely to include a working vertical synchronisation under Allegro. [My site] [Tetrominoes] |
Richard Phipps
Member #1,632
November 2001
![]() |
We all know Triple Buffering is the best. |
Yves Rizoud
Member #909
January 2001
![]() |
Anyway, the Allegro function for "page flipping" (edit: show_video_bitmap() ) is supposed to wait for a VBL to prevent tearing. If it calls the same IDirectDraw2_WaitForVerticalBlank() function, synchronization will not work either? edit: and for triple buffering, request_scroll() "is only possible on certain hardware", alas |
Oscar Giner
Member #2,207
April 2002
![]() |
Quote:
On a DOS machine with VGA card, vsync() works but page flipping is impossible if your card has not enough memory for 2 screens. If there's not enough vram for a second page, create_video_bitmap will fail and in such case you can use double buffer. The best you can do is write a wrapper that handles the update method for you. -- |
Yves Rizoud
Member #909
January 2001
![]() |
Yes, you can detect if you have enough video ram while grabbing it. Now what really annoys me there is a lack of GFX_CAN_VSYNC in gfx_capabilities ... |
gillius
Member #119
April 2000
|
You know, I'm starting to think that Allegro should provide an API that allows you to choose (or if it can, choose itself), the best update method. The main interaction with that API would be two methods. One method to grab BITMAP* you draw to. And another method would be to tell the API that you are done drawing that BITMAP. Direct3D does something similar so it is easy to do buffering. Allegro could allocate memory for triple buf if there is enough VRAM, or it might try to double otherwise. It would handle the vsync for you. Gillius |
Thomas Harte
Member #33
April 2000
![]() |
Quote: Anyway, the Allegro function for "page flipping" (edit: show_video_bitmap() ) is supposed to wait for a VBL to prevent tearing. If it calls the same IDirectDraw2_WaitForVerticalBlank() function, synchronization will not work either? No, it won't use WaitForVerticalBlank for that purpose - DirectDraw has a thing called a flipping chain. You connect a bunch of video surfaces in a chain, then move from one to the next using the Flip method. To that you can pass a parameter stating that you don't want the change to occur until the next vertical sync. How do I know this? I've consulted an aged and wise sage, who remembers back to the deep dark ages and beyond - to the age of the DirectDraw interface Allegro continues to use! That is the normal way to do 'page flipping' in DirectDraw. Thinking about it, I'm not sure how Allegro does it, using its theoretical ability to use any old video bitmap in any old order as the new front buffer. I guess I'll go and have a look at the code again, unless someone can refresh my memory? It being an Allegro thing, I expect it goes through some hideously complicated mess of stodge code. [My site] [Tetrominoes] |
Oscar Giner
Member #2,207
April 2002
![]() |
Quote: using its theoretical ability to use any old video bitmap in any old order as the new front buffer. maybe theoretical, but not real in the practice, if you mean that you can use any video bitmap for page flipping. If you create any video bitmap before the page flipping video pages, page flipping doesnt work propertly. That is, video pages must be the first two video bitmaps you create. -- |
Richard Phipps
Member #1,632
November 2001
![]() |
Have a look Thomas. Maybe you can improve the code. |
Evert
Member #794
November 2000
![]() |
Quote: Just from DDERR_UNSUPPORTED, it is perfectly possible that vsync() is doing absolutely nothing. In this case, Allegro simply wouldn't tell you. vsync is unreliable on some hardware. I thought this was in the docs somewhere, but I can't seem to find where, so maybe it's not there. Quote: Now what really annoys me there is a lack of GFX_CAN_VSYNC in gfx_capabilities ... Yes, this would be a sensible thing to add. I'm not sure how to test for this on all hardware, but it's something that should be looked into. Quote: You know, I'm starting to think that Allegro should provide an API that allows you to choose (or if it can, choose itself), the best update method. Yes, this was discussed (and I think more or less agreed on) on AD. The set_color_depth()/set_gfx_mode() combom is in need of deprecation anyway. What form such an API will take hasn't been finalized though. Quote: I've consulted an aged and wise sage, who remembers back to the deep dark ages and beyond - to the age of the DirectDraw interface Allegro continues to use! As you may or may not have picked up, a minority of Allegro developers uses Windows at the moment. So if you care to assist in that area... Quote: It being an Allegro thing, I expect it goes through some hideously complicated mess of stodge code. Again, feel free to help out. |
Rosen Iliev
Member #4,911
August 2004
|
What is page flipping ? And what is the advantage of 3ple buffering? |
Tobias Dammers
Member #2,604
August 2002
![]() |
Double buffering: Now, each method has its advantages. And finally: Quote: If i calculate exactly when the frame is drawn i blit to screen at that moment,will that problem dissapear? This is exactly what vsync() tries to do, so I'm afraid this will not solve your problem. --- |
Rosen Iliev
Member #4,911
August 2004
|
Thanks for nfo. |
Richard Phipps
Member #1,632
November 2001
![]() |
Have a look at this for a way to do all update options:
|
Tobias Dammers
Member #2,604
August 2002
![]() |
Quote: So if I use triple buffer my program can do usefull job or free cpu time for other windows jobs, right? Sort of. The biggest advantage is that you stay in sync with the screen, without waiting for the retrace. --- |
gillius
Member #119
April 2000
|
If you render more than one frame ahead, a good implementation of triple buffering (I mean at the API level) will block the CPU until vsync. That requires hardware and OS support. For Direct3D, I know it is possible, at least on my video card. Gillius |
Thomas Harte
Member #33
April 2000
![]() |
Evert said: feel free to help out. The whole thing is already too much of a mess for someone of my limited resources (time and ability for comprehension of other people's code - especially very large projects) to help! Anyway, when the problem is that the API simply isn't up to the job (in this case - what could a win32 implementation ever do on DDERR_WASSTILLDRAWING? How could the innate 'goodness' of flipping chains ever be realised by Allegro?), what help could a new programmer possibly be? Personally I'm looking forward to AllegroPro. I've not really been looking too hard at the specification, but Korval seems focussed and knowledgable. In the meantime my SDL conversion remains all but complete. [My site] [Tetrominoes] |
Yves Rizoud
Member #909
January 2001
![]() |
with MSVC6, Win98, a GeForce card, allegro 4.1.15 freshly installed, Triple buffer on the demo program does: And little grey men invaded my computer. Also, Page flipping now works ok in ModeX, DirectX (all supported modes) but in VESA (compiled with DJGPP) the top of the screen flickers black like crazy.. Never mind, with Doom3 out I'll get a new computer anyway.. |
X-G
Member #856
December 2000
![]() |
Quote: GDI: unsupported Expected. You can never do triple buffering in windowed mode, as far as I know. -- |
Richard Phipps
Member #1,632
November 2001
![]() |
I thought I'd done it actually.. |
|
|