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
I think you accidentally the wrong link! Did you mean this topic
indeed I did, tnx :)
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).
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.
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? ;)
Personally, I think the order should at least be consistent between platforms, regardless of which order gosu decides to use.
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.
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. ;)
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 :)
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. :)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill