3 ms·
It's not only conceptual difference. It is a good practice to decouple state manipulation from drawing (even to do drawing in different thread, and with differ
by ajuc 11y ago
It's not only conceptual difference.
It is a good practice to decouple state manipulation from drawing (even to do drawing in different thread, and with different frequency, than state manipulation).
This allows for computers with wastly different processing power to run the same simulation in sync, while the more powerful computer can draw 10 times as many intermediate frames.
Alternatives are variable step length (makes it hard to write deterministic simulation), or fixed step length and capping framerate to it (sacrifices animation quality on better computers for easy implementation).
EDIT: also - the ordering between drawManuel and drawBackground probably do matter, and there's probably some state related to drawing (like animation frame numbers etc) so there should be separate screenState that reflects that.
state = processInput(state);
screenState = drawBackground(state, screenState);
screenState = drawManuel(state, screenState);
- dkersten 11y agoI meant conceptually because of what you say in your edit. As far as your state variable is concerned, they are parallel. But as you point out, there is implicit screen state (either in the code or in the GPU or wherever) and when updating that, order certainly does matter. If each draw* function drew to a temp buffer to be composited later, then they could be parallel. But none of this is really relevant to the game-state discussion, though, since we were both talking about (and agreeing, I think) that decoupling is good regardless. Even if just to aid reasoning.