After spending over an hour yesterday, trying to put my finger on an error, I found myself puzzled about why my freezepoint-detecting print line was working after initialization, however not at the beginning of updating. Randomly, I tried putting it in other places, which is how I figured out that draw actually get called before update in Gosu's code (I figure this might be Ruby Gosu only).

While not trying to blame anyone for this, and being aware of the other thread that basically had a tie between which one should be called first and which shouldn't, I have a suggestion to satisfy everyone: Another definition in Window class, wrapping the calls for update, draw, button_up and button_down, named something like call_order, and obviously looking like this:

class Window

  def initialize(width, height, fullscreen, whatnot)
    # regular stuff
    calling_order
  end

  def calling_order
    button_down(key)
    button_up(key)
    draw
    update
  end

end

That'd allow everyone to choose their own order of calling the methods while perfectly keeping everything the way it is at the moment, which would make everyone happy on the cost of a nanobit of performance (estimated ;) ).

What do you guys think?

I think this is overengineering because it's actually only about perceived performance: When you hit a button, should it first redraw the game or first call update to be able to react to the call before drawing etc. It is not really about where the loop starts, I think I should point that out in the diagram.

If you have an error because of the order, then it is an error nevertheless. You should never rely on draw() being called exactly once between updates. It might not be called if the OS realizes the window is obscured or it might be called twice if the user drags a window over the Gosu window etc.

If you need to be sure that draw has been called once, set a variable in draw.

Well, the way I see it is that draw draws what results from update. Therefore, calling draw before update would resulting in whatever gets updated will get drawn a frame later, essentially delaying all draw commands by 1 frame, no?

And the error I had was in no way related to the order really, I just had a hard time spotting what's causing that error, as I was putting print commands to find out where it stops executing (because of the known black-screen-freeze-bug whatever), and it took me a while to realize I actually have my error in def draw, as I was checking the end of initialize and the beginning of update and was like "wtf gets called inbetween? O_o"

Well, if you take input callbacks out of the picture it is really just

1: zero to n calls of draw
2: update
3: goto 1

Which means that any sequence of update and draw is possible. The diagram is mostly there for the most common case, in which the two alternate, and you want to fine-tune the game's reaction to input.