mvminer can start asynchronous jobs

Before today, mvminer was a single-threaded program. Today, mvminer has a job queue and can load chunks in the background! Gone are the days of waiting several minutes for the (horribly slow) texture generator to run 1,048,576 times before the display comes up.

Mapping tiles into the virtual texture and loading vertices cause a slight pause while they block the GL thread, so I will build rate limiters into their classes. Right now the virtual tile map and shared vertex buffer can only be operated from the GL thread; they should buffer changes and submit them in reasonably-sized batches per frame.

Here are a few screenshots taken as chunks load around the origin:


mvminer has started loading


oh my this texture generator is slow


mvminer continues to load

As always in the first undesigned iteration, this implementation is a complete hack (the asynchronous jobs are all queued up on startup and aren't owned -- quitting before they finish causes a segfault as their working sets are reclaimed by the system).

Once the code is cleaner again I will need to start on a "loading manager" (not sure of the clearest name for it). This system will maintain a prioritized record of nearby chunks and, if they are loaded, their exposed tile counts. It will issue all of the load/save/map-tiles/unmap-tiles requests.

mvminer has semi-static shared vertex buffers

This image was rendered in a single draw call from a shared VBO/IBO polygon pool. Right now it can hold 1M tiles in a 32MB VBO with a 24MB IBO. The index buffer is extra large since I have to use 32-bit indices, but it ends up being a huge performance win when the polygon pool is only partially full; unused polygons can be made explicitly degenerate by zeroing out the indices.

I may end up switching back to unindexed triangle soup in a 48MB VBO depending on performance. (or 32MB of unindexed quads, but quads are deprecated in newer GL releases) The goal will be to keep the polygon pool and virtual tile map full at all times, prioritizing exposed tiles closest to the player. Of course, none of that logic has been implemented yet, and the indexed-triangle solution is better for a scene like this where the buffers are only 22% full.