I've got a decent idea on how to do this...but the game world geometry and textures would have to have restrictions...the end result would be something sorta like the Tomb Raider engine (but not exactly)...Erm...it would depend on how fast Blitz can free small meshes of less then 64 verticies and triangles...if it takes too long to do that (cause a visual hickup) then...well, the more Tomb Raider like the geography of the game world will have to be :P
Basicly have a pivot named world...then parent that to a set of 64 pivots arranged in an evenly spaced matrix...each of these pivots is a parent to a mesh with one surface (each mesh haveing the same number of verticies, and triangles...64 surfaces, one for each model of the 4 by 4 matrix...64 256 by 256 32-bit color textures would be something around 16MB)...you can only see a section of 3 by 3 of these meshes at any one time (the camera stays at world center at all times)...move so far (translate the world pivot in the opposite direction) and the models outside of the 3 by 3 area get deformed, then their parent pivots get translated to the opposite side (effectively "building" a new section of the map)...
You would need a bank or two to store file seek points and such (tell where in a file to find the mesh deformation data, as well as tell where to find the texure to surface it with)...maybe a bank that acts like a 3 dimentional array...you "slice" the game world into equal size chunks (sorta like a 2D tile map...but in 3D) each cell pointing to a specfic mesh and texture (the textures would all be the same size, but the meshes could be nearly any size/shape...as long as they have the same number of verticies/triangles and the triangles refrence the same verticies....however if Blitz can free such small meshs and such quickly enough then this wouldn't be much of an issue)
Textures would be a pain, however by useing a sort of set resource file to store them all (each haveing a ID number or something)...textures could be stored as higher resolution versions, that you would reduce to working size when running...maybe store them as 32-bit 1024 by 1024 textures...that the game can scale down to 128 by 128 16-bit versions as it loads them (this way players with more videoram can use the higher resolution textures and such)...and by keeping track of which textures from the file are loaded, you can then check if it isn't already loaded and just apply it to the game mesh that needs it as it's already loaded and converted to the game settings ...also useing paletted textures would be a good idea, you could use an array or two to store the actual colors to writepixelfast with and by useing some sort of 2D array with a "lightmap" that exists in a bank you can bake a "lightmap" onto the texture as you write it pixel by pixel to video memory...(actualy this isn't a bad idea anyway :P )
If Blitz can free the small meshes fast enough then instead of useing a bank to store a 3D array pointing to the meshes and textures in a file...a oct-tree structure could be implamented...would do the same thing basicly, but allow much more variety in the game world geometry...
Basicly have a pivot named world...then parent that to a set of 64 pivots arranged in an evenly spaced matrix...each of these pivots is a parent to a mesh with one surface (each mesh haveing the same number of verticies, and triangles...64 surfaces, one for each model of the 4 by 4 matrix...64 256 by 256 32-bit color textures would be something around 16MB)...you can only see a section of 3 by 3 of these meshes at any one time (the camera stays at world center at all times)...move so far (translate the world pivot in the opposite direction) and the models outside of the 3 by 3 area get deformed, then their parent pivots get translated to the opposite side (effectively "building" a new section of the map)...
You would need a bank or two to store file seek points and such (tell where in a file to find the mesh deformation data, as well as tell where to find the texure to surface it with)...maybe a bank that acts like a 3 dimentional array...you "slice" the game world into equal size chunks (sorta like a 2D tile map...but in 3D) each cell pointing to a specfic mesh and texture (the textures would all be the same size, but the meshes could be nearly any size/shape...as long as they have the same number of verticies/triangles and the triangles refrence the same verticies....however if Blitz can free such small meshs and such quickly enough then this wouldn't be much of an issue)
Textures would be a pain, however by useing a sort of set resource file to store them all (each haveing a ID number or something)...textures could be stored as higher resolution versions, that you would reduce to working size when running...maybe store them as 32-bit 1024 by 1024 textures...that the game can scale down to 128 by 128 16-bit versions as it loads them (this way players with more videoram can use the higher resolution textures and such)...and by keeping track of which textures from the file are loaded, you can then check if it isn't already loaded and just apply it to the game mesh that needs it as it's already loaded and converted to the game settings ...also useing paletted textures would be a good idea, you could use an array or two to store the actual colors to writepixelfast with and by useing some sort of 2D array with a "lightmap" that exists in a bank you can bake a "lightmap" onto the texture as you write it pixel by pixel to video memory...(actualy this isn't a bad idea anyway :P )
If Blitz can free the small meshes fast enough then instead of useing a bank to store a 3D array pointing to the meshes and textures in a file...a oct-tree structure could be implamented...would do the same thing basicly, but allow much more variety in the game world geometry...