Bay 12 Games Forum

This means that any slowdown you may experience will absolutely only come from OpenGL bogging down under the load of how much it has to draw.

If OpenGL rendering is what's slowing it down then you're doing something wrong . Seriously, the numbers of triangles you're drawing is trivial, the trick is just knowing how to correctly and efficiently cache the geometry data on the video card. My suggestion would be:
Use Vertex Buffer Objects. These are the most optimised way and also give you more control than display lists.
For each terrain block:
   1 vertex buffer containing triangle vertices (ideally these should be optimised for vertex sharing between triangles)
   1 index buffer containing all the indices for drawing triangles, sorted by triangle texture (so that you have all 'granite' textured triangle indices, followed by 'loam' ect). It may be easier to use a different index buffer for each texture, but this adds the overhead of an additional GL pointer call.
   A structure containing the textures and their first index and number of triangles. To draw the block you iterate through the textures and call glDrawArrays once for each texture.
When you update the blocks it may also be faster to do a memcmp on the tile data to avoid regenerating the buffers when no changes take place.

Which leads to the next thing. I think i have solved the problem of "Omg, i have 10 layers of stones in my stone bunker and the 3000 item are bogging down the performance!" The problem here is: I figured, since items aren't very static, i wouldn't need to put them in a display list. Reason being: Display list generation isn't very cheap and requires for me to create structures to organize them. However i'm pretty much forced to do it in some way.

Each object's model should be stored *once* in vertex/index buffers as outlined above (or a display list if you really want to). Then draw this model as many times as necessary to represent the visible objects, and it won't make any difference whether they are moving or not.

If you have any interest in performance at all you should absolutely avoid sending *any* geometry to the graphics card during the rendering loop, and just be drawing precached data. This will give you many more cycles to spend on updating the map.

Maybe I'm being moronic, but the post doesn't actually seem to say what the purpose of the tool actually is.

Is it designed to allow patterns to be created so that tools can automatically find the memory offsets based on pieces of assembly code that use them, even when a new version is released (as long as the pattern still holds)? If so, cool

I'm actually working on a more advanced renderer at the mo. and to be honest the concern about performance is largely unneccessary.

My current fortress (relatively small  <60 dwarves) on an 18x18x34 map (6 region squares, 288x288x544) tiles is rendered with:
452272 triangles
328313 verticies (optimal sharing isn't always possible because of texture-coord issues)
24 textures (this will probably go up, I'm using the same texture for multiple materials at the moment)
only 1 draw call per texture using 1 vertex buffer and 1 index buffer for all geometry
per-pixel lighting (simple) and shadow mapping
And performance is fine, and much much faster than 3Dwarf on my Radeon X800. It even runs without GPU shaders on the GeForce2MX at work (although a bit slowly)

TBH using a 3D-party renderer would only help with certain things. The difficult work is in the geometry creation, but it would help with things like dynamic LOD for trees and best case senarios such as when the view is inside. What it probably wouldn't help with is the exterior view (worst-case) where you just want to push geometry as fast as possible to the GPU and using paging/BSP/occlusion culling might just increase the overhead. I also suspect that the nature of the geometry combined with the floating viewpoint maps isn't very well suited to the usual optimisation techniques for landscapes.
But then I'm only an amateur so I may be wrong , and writing the renderer is mainly the point of the exercise for me.

Also I think the reasons people have been focused on hacking memory rather than the save file is:
1- There is already some info on it from tool writers who need to hack the running process anyway
2- Perhaps most importantly it's much easier to find the information, since you can step through the assembler in a debugger to find where things are. With so little information on the internal data structures used this is really the only way - just finding the type of material used for a virgin rock tile requires knowledge of 4-5 different structures.

As for using the file-depot format, I've looked at it and I'm not sure it contains enough information. There is no actual data on the type of the tiles, just the image.

I'll be releasing my renderer when it's finished, or nearly so (I'll probably release before implementing good trees, since these are a real PITA). As I have the geometry anyway I could also export it to some other format, but that's not high on my list of priorities