Some ppl might not even have noticed this (or care about it) but still. Everybody knows, when Gosu is "started" it starts to call draw() and update() after eachother, but which one comes first? :)
I've always assumed update() first, then draw() .. first update the gamelogic.. then put the updated logic on screen, makes sense in my mind. But in the current GOSU draw() comes first.
I've been surprised a couple of times by this since it feels backwards to me, a common example where I get caught it:
class Player def initialize @animation = Animation.new(.....) end
def update @image = @animation.next! end
def draw @image.draw ... # @image is NIL if update() hasn't been called. end end
Yes, it's easy to solve with 1 extra line in initialize.. but still, I'm curious, is there a case to be made for having draw() first? I brought this up with jlnr and he suggested asking the community, so here it is =).
I suppose it might be useful if you already set your @x's and @y's in the 'initialize' step, and draw first so you don't miss a step, but it just seems wrong. I'd prefer update(), draw(), as it gives me time to fix my stuff first.
yeah i think there's a case for either one. All depends whether you need an update() to bring your game object into state 0 or whether it's in state 0 on initialization. In my case my game objects are usually constructed to be in state 0 and so calling update() would bring it to state 1. So, in my case, if update() is called before draw() state 0 would never be drawn to the screen and state 1 would be the first visible state. In Ippa's case he evidently needs an update() to bring his game objects into state 0...neither approach is right/wrong imo.
My games all work like banister said, so it's a 2:2 tie now ;)
Hmm, what happens if the order of draw/update was switched, but someone created a new game state in update()? Would the same problems arise? I don't know. :)
I'm pretty new to Gosu and game libraries in general, but the few things I've done have worked as it is now, so I guess I'm doing something right ;)
I also agree with bannister's logic concerning "state 0" and "state 1" (although, since the difference between the two is 1/60 of a second, it's a bit moot :P )
So, I guess I vote for "draw() -> update()".
As a side note, the "PopCap" framework also uses the update/draw model. The last time I looked at it, it went in the "update -> draw" order. Just throwing that out there...
One last thing I just thought of... What if it did something like: "prepare() -> draw() -> update()"? Then the programmer could choose the order or even use both (which may provide some hidden benefit, as well). Would the extra overhead make this impractical? Don't cry "n00b" too loudly, I'm just thinking out loud... :P