This system decouples the Secondary threads from the Render thread. Once a chunk is meshed, only the mesh data is sent to the rendering thread, which does not use any direct reference to the chunk itself
- Use parallel_for to iterate over all the stored chunks
- Only push a chunk to a queue if it is not already present, using chunk state bitfield (solves
memory leak, continously adding new elements to a queue)
- Properly delete an element from chunks concurrent_hash_map using accessor, then free the memory
(solves memory leak: not being able to delete old elements and always adding new ones)
Breaks:
- Rendering (will be properly refactored in a future commit)
- Block picking (will be refactored in a future commit)
And then render the texture onto a quad that fills the screen
The screen-filled quad upon which the texture is rendered must never be rendered in wireframe. Rendering in wireframe only makes sense when rendering the world on the texture
Returning Block::AIR when chunk is not yet generated (CHUNK_STATE_GENERATED set to false) is also a way to avoid thread-unsafe concurrent
access to the IntervalMaps data structure, since CHUNK_STATE_GENERATED is set to false before
generating the Chunk and set again to true after generation is complete
previously the current number of vertices was stored in the chunk, and the same variable got later reused for the number of triangles. This modification increases clarity and avoid glitches when blockpicking
This way I can better watch how changes affect FPS/frame times, rather than have it capped at
60FPS/16.6ms
Does not introduce visible tearing.
The engine runs at about 170 FPS on my Tesla M40, and so does minecraft. It never goes past that, I think this is a
limitation of using prime offloading. Runs at 300FPS on average on the Radeon HD6850 to which I
normally offload the Tesla to
EmaMaker