Not logged inGosu Forums
Forum back to libgosu.org Help Search Register Login
Up Topic Gosu / Gosu Exchange / BUG: draw/update order (Windows)
- - By Spooner Date 2010-10-25 10:29
The order of draw and update is actually inverted on Windows! I think this is quite a serious bug, since it means that following the convention of using #update to make calculations ready for #draw will mean that your game will always lag exactly one frame behind (assuming that the calling order is #update then #draw, rather than that there just isn't an #update call in the first frame)! It also means you can't assume that all values to be used in draw must be set to valid values in initialize, otherwise they will cause problems in the first #draw.

http://gist.github.com/644723
Parent - - By ippa Date 2010-10-26 15:08 Edited 2010-10-26 16:17
This thread from 2009 might be relative: http://www.libgosu.org/cgi-bin/mwf/topic_show.pl?tid=222

*edit: corrected the url, tnx erisdiscord.
Parent - - By erisdiscord Date 2010-10-26 15:50
I think you accidentally the wrong link! Did you mean this topic?
Parent - By ippa Date 2010-10-26 16:17
indeed I did, tnx :)
Parent - By Spooner Date 2010-10-27 14:38
Thanks for pointing me at that thread. At least I know I'm not going crazy :)

The fact that Linux starts with an update rather invalidates the arguments put forward against having update first (that initial state should all be done in initialize).
Parent - By erisdiscord Date 2010-10-26 15:54
Seems that this is a known fact (not a bug) and isn't likely to change. In the mean time, you can either se up your objects to be ready to draw in initialize or just issue a call to update before it returns so everything's set up.
Parent - - By Maytsh Date 2010-10-26 16:02
You say that as if it was obvious what the "correct" behaviour is. For getting smooth animations you normally want to keep the times between frames as constant as possible. This means that when the timer event arrives, you might want to get drawing as fast as possible - without an possibly unpredictable update pass.

So, what do you prefer - slight delay or slight stutters? ;)
Parent - - By RavensKrag Date 2010-10-27 01:04
Personally, I think the order should at least be consistent between platforms, regardless of which order gosu decides to use.
Parent - By Spooner Date 2010-10-27 14:33
Yes, I was just going to say that. If the draw/update order has been considered then it should be consistent. As it is, it looks arbitrary (though there could be absolute reasons why Linux should be different, but I dunno).

If the correct order in a frame is draw/update, since I have to admit that your explanation is perfectly good, I still think that the first _ever_ call should be to update, even if it is update/draw/update/draw/update on Windows and update/update/draw/update/draw on Linux. To have to always call update at the end of initialize, seems unnecessary boilerplate that should be in the framework and not having it is a bit of an obscure gotcha making cross-platform development that bit harder.
Parent - - By jlnr (dev) Date 2010-10-27 23:10
I reworked the Wiki page to cover a lot things from this thread and IRC. Thanks for the discussion, The diagram was certainly misleading without explanation.

http://code.google.com/p/gosu/wiki/WindowMainLoop

The remaining question is this. Where in this loop does the sleeping/idle time occur? Seriously, I don't have any clue since it happens thanks to screen vsync nowadays. Even when glFinish returns, I don't know if this means that the data has been transferred to the OS, to VRAM or to the screen. Maytsh, I think your ideal order depends on this fact and I hope nobody is ever fast enough of a gamer to notice it. ;)
Parent - By Spooner Date 2010-10-27 23:12
That is great, thanks!
Parent - - By Maytsh Date 2010-10-28 11:13
Well, I checked and Clonk does it the other way round, so I am in no position to complain ;)

My guess is that VSync doesn't really buy you much here, on the contrary: If your drawing code generally is finished right around the mark the VSync happens, slight inaccuracies could get magnified greatly. Worst case you could get into some kind of 1-2 rythm, which the human eye *would* notice as stutters. If there's one thing our perception is really good at it's detecting slight movements.

Well, the discussion is a bit acamedical, as there is no easy "right" answer. I just wanted to point out that this isn't an easy question :)
Parent - By jlnr (dev) Date 2010-10-28 15:04
Yeah, I understand the vsync danger. So far I haven't seen it happen though. As long as simple games run at exactly 60 FPS, things are right in the general case. :)
Up Topic Gosu / Gosu Exchange / BUG: draw/update order (Windows)

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill