On 18.06.2018 00:33, Luke Paireepinart wrote:
If you are multithreading a game, the "main" thread should be mutating
the game state, not the surfaces directly. The render thread should be
the view of the model state at the snapshot in time at which the
render is called. The logic thread should have a control that is
determining the time between updates and applying the appropriate
amount of ticks to the game state / emulating physics / etc. Then
whenever the previous draw has completed, the render thread would
snapshot the state and represent it appropriately (either redrawing or
comparing to its previous state). If there needs to be multiple draw
calls to represent the state properly since the last state, then they
can all be done before the display buffer is flipped.
In the 1-9 example, each font would be represented by a game object
that had a positional element, and you could add them to the map
asynchronous of the draws since the render thread would display them
on the next iteration of the render loop where they existed.
Hi again
this is exactly what I have described in my email earlier... (draw the
game state snapshot)
But if I understand you correctly you actually want something like a
asynchronous blit method that takes a list of blit commands (this would
not require any threads in the game logic/draw logic but of course in
the async blit method which would be written in C). If you do proper
game state handling by just drawing a gamestate snapshot then this
method would be fine too (no copy needed, only a gamestate snapshot).
I think the problems arise when the game logic does manipulate surfaces
directly that should be drawn (not sure if that is desired, maybe try to
avoid that). In that case a COW and async blit list is probably the best
way to go.
I still think teaching how to separate the game logic from the draw
logic is more future proof, but might not be the goal of pygame zero.
What I prefer to do in my games is to use a light weight sprite (not the
pygame.sprite.Sprite) and a Spritesystem that render all sprites. Here
normally the sprite image is not manipulated by the game logic (only by
the spritesystem but then it keeps a copy of the original because of
rotation and other distortions). In this way game logic and draw logic
is somewhat separated (of course you could manipulate the surface an
break the gfx as in the 1-9 number example, but normally all game
entities are represented by a surface that does not change).
~DR0ID
