The main change I have done is adding support for an infinite tile world. I divided the world map into 32x32 tile chunks and introduced a 3 stage cache along the lines of Disk -> RAM -> Video memory.
What I was doing before was rendering each tile in a separate DrawUserPrimitives() call. This was fine for a dungeon it seems, but for an outside world in which I want to be able to zoom out quite far...well 100x100 tiles = 10,000 batches each frame which is just stupid. I got slowdown on my card when zooming out a fair distance, although admittedly my card isn't a particularly fast piece of hardware.
What I am doing now is using a VertexBuffer. When a map chunk comes into view I load it's vertices into the buffer. The vertices's are then kept in the card memory and I don't have to pass them all to the card each frame (at least that's how I think it works..still learning this stuff).
The VertexBuffer is big enough to hold about 25 map chunks. That's more than enough to cover a large enough area if the player zooms out. From what I've read it's a bit expensive to set data in the vertexbuffer, in fact I've read people saying don't set data in the vertex buffer during the game, only do it during initialization....well ok but I couldn't see any other way. So as the player moves across the map the older chunks in the vertexbuffer are replaced.
The RAM cache is for chunks that used for a non-drawing use, eg calculating a line of sight in a distant area. It would be bad to load a chunk into the vertexbuffer that wasn't even going to be drawn. I suspect there will be a lot of processing of non-visible chunks.
The disk cache is what enables the "infinity". The RAM cache is limited in size and reads/writes chunks from the disk cache as needed. It seems to work smoothly enough. The Map Generator itself has no concept of chunks, it just writes terrain in tile coordinates. Behind the scenes the necessary chunk is loading into the RAM cache and the tile modified.
Tile Textures
Textures are a big problem now. Before when I was drawing a single tile at a time it was easy (although very inefficient): I would just set a different texture depending on the tile background before the draw. Now I am drawing 32x32 tiles at once and some of those tiles could be grass, some could be rock, etc.
What I am currently doing is having a big sprite sheet texture, well it's not that big - 512x512 at the moment which holds 64 64x64 tile textures. Then for each 32x32 map chunk I have the vertex texture coordinates set to correct offsets into the sprite sheet to pick up the right terrain type for each tile. A problem is that texture cordinates are proportional and not absolute so the offset into pixel 64,64 of the sprite sheet is 0.125f, 0.125f which threatens precision problems. It can be dealt with but it isn't great.
Another possibility I might try is to pre-render each chunk to a single texture and save that to disk, then load that on the fly using a similar disk->ram->video memory cache system as used for vertices. Unfortunately that means more loading of content during the game. On the otherhand having a single texture for the entire chunk means I don't need to draw a chunk as a 32x32 grid of triangles anymore, it can be a single quad. Kind of negates the need for the vertex buffer...
So yeah you can see I don't know what I am doing. Still reading/experimenting trying to understand how video cards work and what i need to worry about in terms of performance and what I don't. Mainly trying to figure out the traps (Eg here's one I fell into: http://www.altdevblogaday.com/2012/02/05/dont-store-that-in-a-float/). I guess it was a stretch to imagine I could just "make a game" without the overhead of having to read stuff. Maybe my 2nd game will go faster.
Field of Vision
This is about field of vision in roguelikes. You are looking down on the dungeon/world and yet certain tiles are not drawn because even though you can see them from above, your character cannot because eg a wall is in the way. This is different from line of sight. This is about calculating an occlusion mask that is drawn over the map for areas your character cannot see.
I disabled field of vision as soon as I switched to a surface world map because my inefficient implementation that could only just cope with small dungeons failed miserably with wide open spaces. Calculating whether each tile on the screen is visible to the player's tile each frame was too much.
I could spend time understanding and implementing one of the more modern fancy algorithms.
http://roguebasin.roguelikedevelopment.org/index.php/Field_of_Vision
But I am lazy so I started thinking if field of vision was worth it. Inside a dungeon yes it is, somewhat. But outside...I think gameplay would work without it. A maximum radial view distance works fine. Creatures could still be hidden if they were out of line of sight.
/longwinded unformated update
