   worms-armageddon map storage
  I'm working on a side-scroller that uses terrain like worms-armageddon (and is being written entirely with OpenGL calls).  Their maps are huge; I'm wondering how to most effectively store all that information such that I can smoothly scroll from one side of the map to the other?  Say, for example, my map is an 8x8 grid of 1024x1024 screens.  At 4 bytes per pixel, that's 256 megabytes of information.  Obviously I don't want to keep that all on hand at once, so how can I best page it in and out?  Specifically, how can I most effectively do what I want using OpenGL?  How do you specify which textures are actually stored in memory, how do you unload ones that have been loaded, and can I load the textures in during runtime from the disk without experiencing a stutter in the scrolling?   
  The trick here is that you dont need to store every single pixel in the map itself. Let me explain.If you were to chop up a map in worms 2 for example into pieces then you would see that there are relatively few tiles, and then the monuments / extras are kept separate.If you store the map as a matrix of integers which lookup into the tile map then you could shrink the storage requirements by quite a lot. Also you could probably RLE encode your map because whole integers might not vary often.Also, they might use vectors and or parametric curves to describe a map, and then have rules like 'there is grass above a curve, and dirt below it' so then you end up using even less space, and you gain more flexibility for describing a map.At runtime you would load up the map and 'bake' the pixels into a texture which fills the screen. For handling larger worlds you can either copy / shift in different parts of the map as the view scrolls around or you could keep several textures and just display them at the same time.   ;  Just an idea: what about using smaller textures (i.e. 512x512) and loading those that are displayed and those that come next(in every movement direction)? Then when the user scrolls the map and a previously hidden texture piece is shown, you load only the adjacent textures that are not yet in memory, and release those that are no longer adjacent to the visible tiles...   ;  This boils down to memory / CPU speed. Personally I would say that on-demand loading of the world map is a bit over the top for this problem. Besides, you're never going to be able to load on-demand and get perfect smooth frame-rates unless you background load which could bring with it a whole world of hurt when sorting out the thread synch.Put it like this, a screen size of 1024x768, 4 bytes for each pixel (full RGBA) = 3,145,728 bytes. If you have a 32MB budget for map data then you could store a map in memory with dimensions of 10419x768 without breaking a sweat. That's about 10 screens wide.   ;  Gilb I've been coming to the same conclusions on my own.  I actually only need terrain that runs along the bottom of the screen, so I can actually store my terrain as a single array.  I've set up a method of tiles that works pretty damn well, and I figure I'll just let OpenGL handle the texture management.  ( I broke the data up into 64x64 tiles, and I can pack all the surface tiles into one 512x512 atlas texture).  I should really have no problem, thanks!  rate++   