[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Cheap COW clones for surfaces



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