Open ykafia opened 1 year ago
This is how I do multithreaded Bepu physics in Focus Engine, but haven't messed with updating game logic in parallel. What you can do, and can provide similar performance bonuses, is to write your game simulation logic to be multithreaded (e.g. update lots of in-game objects at once).
Interestingly, a lot of our rendering architecture is inspired from this exact GDC talk. We have the Extract/Prepare/Render pipeline (as described in the slides), with lot of inner parts happening in multithread.
We don't do the render frame - 1 thing yet (it's quite a lot of work to generalize it for a game engine -- possibly a lot of it would have to be done by the user/game anyway).
It does make sense now,
(it's quite a lot of work to generalize it for a game engine -- possibly a lot of it would have to be done by the user/game anyway)
I'm not sure i understand what you mean by that, what would make it complicated to be generalized ?
it would be nice if we can push game logic to second thread, so game won't freeze while you dragging window
Bungie has made a presentation on multithreaded rendering.
In their engine, the game simulation and rendering are done in parallel with a step of synchronization where a specific selection of data is copied, transformed and prepared for the next frame to be rendered. This step of synchronization is where no game logic nor rendering is running to avoid data race condition.
This would involve a lot of change in how the engine currently works (ECS, Renderer, maybe the asset system etc).