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 thought it was update(), draw() too!

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.

Some more opinions to push jlrn in the direction of doing the right thing? ... having update() first ;)

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 do the state thing now too. but even when I didn't I never ran into any problems. good to know tho

i always used libraries with the draw first and the update later :3

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

cool with alot of input.. I guess it would take a clear majority to justify a change of status qou.

I haven't given much thought in the past...
If you ask me, I vote for draw(), update() as well.

deps you traitor >:O .. hah, when are you gonna be back in #gosu? =)

When I remember to open my irc client, probably. :)
I think I pop in now...