(I'm using Open GL, but I belive this is a more general problem) Please advice: I have a problem deciding how to do the background levels in my top-down 2D shooter. It's in many ways similar to Uridium and Uridium 2 or even Space Tripper. Here are some images of Uridium 2 on the Amiga that shows what I'm thinking of: http://www.classicgaming.com/shmups/reviews/uridium2/images/snap20.gif http://www.classicgaming.com/shmups/reviews/uridium2/images/snap22.gif http://www.classicgaming.com/shmups/reviews/uridium2/images/snap01.gif http://www.classicgaming.com/shmups/reviews/uridium2/images/snap04.gif http://www.classicgaming.com/shmups/reviews/uridium2/images/snap18.gif I belive Uridium to uses tilemaps... My problem is that I want maybe 20 maps (one for each level) and the maps are very big - some are 2000 * 16000 pixels and I want 1 pixel = 1 texel - no scaling/bluring. I might even store a level as several layers and composite and texture them at startup - all to save disk space. Possible solutions I can think of: 1) One big texture: Uses far too much VRAM. 2000 * 16000 pixel map is 128 MB. I would like to keep a map < 32 MB of VRAM. 2) Proper 3D using Open GL geometry: I don't have the know-how to do this (and make it as detailed with shadows etc.). I prefer to focus on completing the game. 3) Classic tile engine: This makes it so damn fiddly creating the tiles and the maps - especially getting all the overlapping shadows right and all those irritating tiles need where only a little bit needs to be changed to get transients pretty. It would be much faster if I can just render the complete background (or maybe section of it) in Cinema 4D. 4) Pre-rendered LEGO-style objects (basically big sprites) where each goes into a texture in VRAM. They are positioned in the map to together create the big background ships. This is the most practical solution, but I still have the problem of getting them to fit together seamlessly with shadows etc. And it may cause obvious repetition. 5) Split the huge texture into 256*256 textures and expect Open GL to move just a few of them at a time between VRAM and RAM while the player scrolls across the map. Any ideas or recommendations? /Marcus

The screenshots you provided are all simple tile engines - it, simply put, is the best way to do it I think. The key to removing the boxy look is to have well-made artwork. There's an article about it somewhere, lemmie see if I can dig it up...

Great Scotts! That was hard to find.

Anyway, you'll probably want to read this.

[Edited by - Mushu on May 17, 2006 9:37:39 PM]

I'd go with number 5. From what I hear, John Carmack used a similar method with his megatexture. :p It's the logical choice to minimise the size of the texture required in memory. Stream in the textures as you need them.

Also, compression is your friend. :)

Thank you for your replies, both of you!

I've got to think more about this. The difficult tradeoff for me is the ease to create contents (tiles are hard since I want shadows to look OK:ish) vs. the VRAM-strain the game puts on Open GL...


A new idea I have:

6) Same as 4) but cover the repetition by decorating with lots of tiny objects, like towers and decals. This makes it possible to render the big LEGO-block textures in Cinema 4D - basically big ship-parts, but design them to be less rememberable - basically just shapes. Then draw lots of smaller textures on top to add the detailing.

Clever?


/Marcus