search

eugeneloza / castle-editor-tutorial

Moved to https://gitlab.com/EugeneLoza/castle-editor-tutorial
MIT License
2 stars 0 forks source link

6.18. Fix a Possible Bug with Update Order #10

Open and3md opened 3 years ago

and3md commented 3 years ago

@michaliskambi @eugeneloza Maybe this should be fixed in CGE in some way?

michaliskambi commented 3 years ago

I read 6.18 ( https://github.com/eugeneloza/castle-editor-tutorial/blob/master/clicker-game-tutorial.adoc#618-fix-a-possible-bug-with-update-order ). This is indeed a hacky way of calling Update, I would not like to advise this to users.

Discussion about whether we want to do something in CGE:

  1. Indeed we do not guarantee the order of Update vs Render in CGE in general, and I do not think we should start to guarantee it. It would be difficult to do cross-platform.

    Update and Render do not have to always be fired as a "pair" at the same time, even if in practice they often are fired as a pair (esp. on typical Windows, Linux desktop). But e.g.

    • with AutoRedisplay = false, the Render may be more seldom than Update.

    • with a window manager requesting redraw when moving the window, the Render may be more often than Update (this is purely theoretical case now, in practice we only set "invalidate" flag when you move the window).

    • with a CastleWindow "backend" where we don't control the message loop, like CASTLE_WINDOW_LIBRARY (used by default on iOS and Nintendo Switch) we may have no control over this. In case of iOS, right now it in practice depends on Objective-C GLKView behavior (so anything is possible). In case of Nintendo Switch we actually control the order but outside of Pascal code. In general, in this case CGE leaves the decision to the outside code to call CGEApp_Render, CGEApp_Update in any order.

    So I'd prefer to keep this order undefined, it avoids guaranteeing something that 1. may be very hard to guarantee in some cases, 2. is often not necessary.

  2. This particular case (TUIState) could be patched specifically. That is, in TUIState implementation we could explicitly do Update at the end of InternalStart, thus implementing this hack at CGE level. But it is still a hack, and only for this one control (TUIState), so I'd like not to do this at CGE level.

General advise what to do:

The general guideline is "make sure your state always reflects something that can be shown to the user (when the method like Start or Update ends) ". This is, as far as I know, similar to guideline of LCL or Unity. So do not leave UI in a "placeholder" state at the end of Start. Yes, this is exactly what 6.18 actually does, but it does so using a "hack" --- introducing UnusedBooleanVariable raises an eyebrow "why" :)

The solution to the case of 6.18 is just to introduce a private method like RefreshUI in the state, and call it both from Update and from the end of Start. Maybe this RefreshUI should have the same content as current Update or maybe it should only be a subset (as it doesn't have to account for time passing).