@Germanunkol - Great Idea I had not thought of that. My Idea was to basically save the tile specs in a String in a double nested arraylist of strings. each string would represent a section of the map and would be initialized when the player traveled to that section. The tiles would first try to generate based on the string. If the tile had not been created before then a random tile would be selected and saved in the string then loaded into the level. This would allow the player to revisit areas previously discovered.
The infinite terrain generation slowly came together as I was experimenting with some new things. first I had created the tiles to generate as the player moved in any given direction and remove the tile behind the player. This worked well so I applied a grass texture and decided it was to plain so I added a dirt texture and randomized the textures creation. The problem then was that there was a clear line between the grass and dirt tiles.
To fix this I took a detour into BMAP manipulation. I wrote some functions that would blend the edges of a texture into the other by a specified amount. Once this worked well and I could blend textures I implemented it into my terrain generation. A quick problem I ran into was that changing the skins to these modified bmap textures would change all of the skins of that model type. after messing around with ent_copyskin and so on I decided to ditch the models and use ent_createterrain. After switching over to that I had sucessfully implimented my blend texture functions.
It worked but now the terrain seemed to flat so I changed the height of the tiles and wrote some new functions that would sew the tiles together. Sure this worked but it was blocky and the terrain was rough so I wrote another function that would smooth the terrain tiles out. This worked great so I added some vegetation to give it a better feel.
At this point there was a major problem. every tile created had its texture blended to the one next to it and its vertex's altered. each new tile had to run hundreds of thousands of calculations and each tile section contained ten tiles. I had been making the program run through millions of calculations every time it created a new tile section. This would make the program glitch a bit when this happened. To fix this I created a library of bmaps that would store the blended textures that had been created based on the tiles and its neighbors. When a new tile is created it checks the library for the correct bmap. If it exists then it simply copies it. If the bmap does not exist then it is created and saved in the library. This way the calculations would only need to be done once.
That is how it is currently done.
A problem that I am currently faceing is the nexus is filling up. This takes a while but is still not desired. ent_remove removes the tile from the map but it is still stored in the nexus. I have been thinking about this problem a bit and I believe I have come up with a solution but I have not tried it yet. My idea is to recycle the tiles instead of removeing them. when a tile becomes out of range that tile's texture, location, and vertexes will be reset to its new location and from there the tile manipulation functions can do their job.
This is all experimental right now and suggestions are appreciated. Ill keep trying things and improving things until I have a solid foundation for a new game.
@ratchet - Thoes are great Ideas. I will play around with them and see what works. My idea is to have the general look of the terrain change as the player travels. sort of like entering different biomes. perhaps desert or snow or islands and mountains all with their specific settings for the terrain generation. I will experiment with that soon hopefully.
