3 ms·

I wonder if somebody have tried using a STM style approach to making games? For a couple of LudumDares I did try (in java) and for the games I was able to do i

by Ingon 11y ago

I wonder if somebody have tried using a STM style approach to making games? For a couple of LudumDares I did try (in java) and for the games I was able to do it worked fairly well. Basically the drawing thread is seeing a frozen readonly version of the world (and keeps 60 fps) while the update thread will try to run simlation over readwrite version of the world. When the update thread finishes it will "publish" the new state and start over. I have ever wondered how it will perform at scale, maybe it will start braking apart if it grows too much?

m_mueller 11y ago
IANAGameEngineProgrammer, but I'd say it all depends on how you do the 'publishing' part. To do this in a performant way you need a language that supports pointers, so all you need to do in the thread safe part of your code is to swap two pointers (current and new). I'd assume the thread sync overhead once a frame becomes negligable (is there a good analysis for thread sync overheads on current x86?).
orbifold 11y ago
It breaks down when you approach the hardware limits, i.e. for rts games with thousands of units on the screen, particle effects and so on, or if you have complex cad models in automotive applications. Essentially you then need to minimize driver overhead and avoid data copying at all costs. In particular you need to do memory mapped IO (using glMapBufferRange) between the GPU and main memory as fast as possible. That is only possible if you do tripple buffering with a ring buffer, at any given time one part of the buffer will be in flight to the GPU, one will be processed by it and the third will be modified by the CPU. You "publish" with synchronization (glFenceSync() and glClientWaitSync()), see for example http://gdcvault.com/play/1020791/ http://gdcvault.com/play/1020791/. In particular you have to organize all your world data in flat mutable arrays because even on the CPU your data has to be presented in a way that avoids cache misses as much as possible, this philosophy goes by "data-oriented design", see for example https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc.
- davexunit 11y ago
  This is all very low-level stuff, though. Functional systems are high level abstractions typically erected on top of a low-level, imperative foundation. Let's use the particle effects example: One can describe how a particle system should behave using pure functions and immutable data whilst letting the actual simulation and rendering be handled by a low-level system that does all the dirty stuff necessary for speed.
  - Veedrac 11y ago
    I agree that it's potentially possible to make a functional layer on top, but it still seems somewhat irreconcilable with the idea of STM.
  - deleted 11y ago
    [deleted]

by Ingon 11y ago

m_mueller 11y ago

IANAGameEngineProgrammer, but I'd say it all depends on how you do the 'publishing' part. To do this in a performant way you need a language that supports pointers, so all you need to do in the thread safe part of your code is to swap two pointers (current and new). I'd assume the thread sync overhead once a frame becomes negligable (is there a good analysis for thread sync overheads on current x86?).

orbifold 11y ago

It breaks down when you approach the hardware limits, i.e. for rts games with thousands of units on the screen, particle effects and so on, or if you have complex cad models in automotive applications. Essentially you then need to minimize driver overhead and avoid data copying at all costs. In particular you need to do memory mapped IO (using glMapBufferRange) between the GPU and main memory as fast as possible. That is only possible if you do tripple buffering with a ring buffer, at any given time one part of the buffer will be in flight to the GPU, one will be processed by it and the third will be modified by the CPU. You "publish" with synchronization (glFenceSync() and glClientWaitSync()), see for example http://gdcvault.com/play/1020791/ http://gdcvault.com/play/1020791/. In particular you have to organize all your world data in flat mutable arrays because even on the CPU your data has to be presented in a way that avoids cache misses as much as possible, this philosophy goes by "data-oriented design", see for example https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc.

davexunit 11y ago
This is all very low-level stuff, though. Functional systems are high level abstractions typically erected on top of a low-level, imperative foundation. Let's use the particle effects example: One can describe how a particle system should behave using pure functions and immutable data whilst letting the actual simulation and rendering be handled by a low-level system that does all the dirty stuff necessary for speed.
- Veedrac 11y ago
  I agree that it's potentially possible to make a functional layer on top, but it still seems somewhat irreconcilable with the idea of STM.
- deleted 11y ago
  [deleted]