As I said, my idea was to use twbt to make the screen renderer in the game process render NOTHING and instead having the screen rendering done by a seperate process which can run on a different cpu core. Seeing as the screen rendering takes ~10% of the total 25% available, this could potentially almost double fps in any scenario.
The problem, as I said, is in synchronisation. You don't want a dwarf to appear twice on screen because while your rendering thread was rendering tile by tile, another thread moved that dwarf to another tile. That's why rendering thread pauses main loop while it's rendering, and this will have to be done regardless of whether it's a separate thread, process, whatsoever.
What if you have one piece of code that's synchronous with the main loop, which puts tile update events in a queue? Then the renderer can consume the queue asynchronously. It may lag a little, but there should be no problems with double-rendering.
This is the classic race-condition scenario. The render thread has references to objects that the main loop is mutating (such as removing goblins that die, or changing a dwarf's state so they no longer have a job pointer; these examples are unburdened by the specifics of the data structures, but I'm pretty confident that such pointer updates occur), leading to crashes and other fun.
Unless you mean that the main loop flattens all of that out, effectively copying the tree of display-relevant structures over so it's immutable from the render thread's perspective? Is it the paint or the what-and-how-to-paint calculations that consume the time? I assumed the latter, and that just pushing the draw-command stuff to another thread wouldn't win very much at all.
Author
Topic: Text Will Be Text - dfhack plugin (Read 801240 times)