Ravey
06-24-2008, 09:56 PM
I'm working on a remake of Magic Carpet in FreeBasic and I have a few ideas in mind. I'm not very experienced yet, however I think Magic Carpet should be small enough to be achievable in a higher level language. I also figured i'd talk about it here in hopes of getting a little motivation and a better sense of direction for the project.
Glenn Corpes actually wrote a presentation about Procedural Landscapes which is only available through web archives, first i'm going to find out more about the original Magic Carpet engine... Hopefully it's an interesting read. ;)
The kinds of things that i'm undecided on:
Low polygon terrain or High polygon terrain?
Low Draw Distance or High Draw Distance?
Filtered textured or Non-filtered textures?
Models or Sprites?
Detail textures?
Music Format? MIDI, MOD, MP3, OGG?
Keep the same speed? Magic Carpet didn't have a constant framerate...
Resolution?
Even share your Magic Carpet experiences.
Magic Carpet PC (1994)
Dynamic landscape, real time modification of:
Geometry
Textures- or rather the tiles
Magic Carpet Illustrates one of the real advantages of Heightfields:
Data so simple you can change it on the fly. In fact the game programmers got chasms, volcanoes and castles smoothly morphing from it and made this a major element of the gameplay. Just a shame you couldn't see more than 100 yards, changing textures on the fly though was a bigger issue though.
Magic Carpet's tile system
Vertex based, each could be:
Water, Grass, Rock, Sand, Beach, Snow, Scrub or Path
It used a very similar fractal generator to Powermonger, then each point was set to one of these types according to altitude, slope and info from the level editor.
4 Corners, 8 materials = 8*8*8*8 = 4096 possible tiles = 4MB @ 1k per texture = too much !
Target platform = PC, 4MB of RAM
then ported to Playstation and Saturn
Final Tileset
150 textures
4k look up table
Each corner could be any of those 8 types so we potentially needed 4k of textures, We really needed to cut this down, First option would have been farm off to tools guys to write a tile editor and give the artists a limitation of 256 textures But we needed a dynamic system, We also didn't have any tool guys and I'd have been writing the editor. so we introduced some limitations, no snow on same square as water. No path on desert etc.
This Gave us a rough idea of the texture set we needed, these were drawn up by the art department and at load time, each was flipped 8 ways and compared with the 4k of possible tiles resulting in a 4k lookup table of how to make each possible tile from a real tile and an orientation. Of course the vast majority of these didn't exist. We pointed these at a tile with bollocks written through it. These rules were added to the generator to remove combinations that weren't supported. We Ran the game and looked out for bollocks tiles, we tweaked the algorithm to remove more combinations or got the artists to draw more tiles and tried again. After a few iterations it worked, this process was much quicker than writing the editor would have been and it still supported a dynamic landscape.
The point is we got down to about 150 textures from 4k, Small enough to fit in the Playstation and Saturn.
http://img237.imageshack.us/img237/3255/slide0037image024ph9.gif
Basically, the whole world is split into 64*64 cells but we don't want to use over 4000 pieces of geometry.
For a given viewpoint, these are at various LODs, green=1x1 etc
This wouldn't be very friendly to modern PC or console hardware, which can generally draw millions of polygons but would rather be fed hundreds at a time to get decent performance. For this reason we keep a vertex buffer available for drawing the whole island at the lowest detail level (the green stuff), this typically gets rid of over bulk of those draws.
Every frame we scan through all 64x64 cells and work out an LOD for each one, based on the screen size. Cells at the minimum LOD are a special case and are handled simply by adding a few vertices to that low detail version. Any at a higher levels of detail grab an appropriately sized vertex buffer from a pre-allocated pool, this vertex data is filled in from the heightfield and kept around for as long as possible. In practice, we only see three or four of these rebuilds per frame, the rest of the engine is just a case of matching a similarly generated texture with these vertices and drawing it with an appropriate mesh of indices.
Our dynamic shadows for moving objects are basically drawn by reusing the landscape geometry with a projected texture. Not only was the old, hierarchical system a complete PITA for this but the amount of overdraw was hideous. Because the new system uses constant sized chunks of landscape it's all just so much cleaner.
Glenn Corpes actually wrote a presentation about Procedural Landscapes which is only available through web archives, first i'm going to find out more about the original Magic Carpet engine... Hopefully it's an interesting read. ;)
The kinds of things that i'm undecided on:
Low polygon terrain or High polygon terrain?
Low Draw Distance or High Draw Distance?
Filtered textured or Non-filtered textures?
Models or Sprites?
Detail textures?
Music Format? MIDI, MOD, MP3, OGG?
Keep the same speed? Magic Carpet didn't have a constant framerate...
Resolution?
Even share your Magic Carpet experiences.
Magic Carpet PC (1994)
Dynamic landscape, real time modification of:
Geometry
Textures- or rather the tiles
Magic Carpet Illustrates one of the real advantages of Heightfields:
Data so simple you can change it on the fly. In fact the game programmers got chasms, volcanoes and castles smoothly morphing from it and made this a major element of the gameplay. Just a shame you couldn't see more than 100 yards, changing textures on the fly though was a bigger issue though.
Magic Carpet's tile system
Vertex based, each could be:
Water, Grass, Rock, Sand, Beach, Snow, Scrub or Path
It used a very similar fractal generator to Powermonger, then each point was set to one of these types according to altitude, slope and info from the level editor.
4 Corners, 8 materials = 8*8*8*8 = 4096 possible tiles = 4MB @ 1k per texture = too much !
Target platform = PC, 4MB of RAM
then ported to Playstation and Saturn
Final Tileset
150 textures
4k look up table
Each corner could be any of those 8 types so we potentially needed 4k of textures, We really needed to cut this down, First option would have been farm off to tools guys to write a tile editor and give the artists a limitation of 256 textures But we needed a dynamic system, We also didn't have any tool guys and I'd have been writing the editor. so we introduced some limitations, no snow on same square as water. No path on desert etc.
This Gave us a rough idea of the texture set we needed, these were drawn up by the art department and at load time, each was flipped 8 ways and compared with the 4k of possible tiles resulting in a 4k lookup table of how to make each possible tile from a real tile and an orientation. Of course the vast majority of these didn't exist. We pointed these at a tile with bollocks written through it. These rules were added to the generator to remove combinations that weren't supported. We Ran the game and looked out for bollocks tiles, we tweaked the algorithm to remove more combinations or got the artists to draw more tiles and tried again. After a few iterations it worked, this process was much quicker than writing the editor would have been and it still supported a dynamic landscape.
The point is we got down to about 150 textures from 4k, Small enough to fit in the Playstation and Saturn.
http://img237.imageshack.us/img237/3255/slide0037image024ph9.gif
Basically, the whole world is split into 64*64 cells but we don't want to use over 4000 pieces of geometry.
For a given viewpoint, these are at various LODs, green=1x1 etc
This wouldn't be very friendly to modern PC or console hardware, which can generally draw millions of polygons but would rather be fed hundreds at a time to get decent performance. For this reason we keep a vertex buffer available for drawing the whole island at the lowest detail level (the green stuff), this typically gets rid of over bulk of those draws.
Every frame we scan through all 64x64 cells and work out an LOD for each one, based on the screen size. Cells at the minimum LOD are a special case and are handled simply by adding a few vertices to that low detail version. Any at a higher levels of detail grab an appropriately sized vertex buffer from a pre-allocated pool, this vertex data is filled in from the heightfield and kept around for as long as possible. In practice, we only see three or four of these rebuilds per frame, the rest of the engine is just a case of matching a similarly generated texture with these vertices and drawing it with an appropriate mesh of indices.
Our dynamic shadows for moving objects are basically drawn by reusing the landscape geometry with a projected texture. Not only was the old, hierarchical system a complete PITA for this but the amount of overdraw was hideous. Because the new system uses constant sized chunks of landscape it's all just so much cleaner.