wraggster
September 20th, 2006, 01:23
More WIP news:
I looked at this last night and most of the bugs were in the PC version dealing with the tilemaps. I fixed that and then started looking at how I would hold all this info in memory. My current plan is to use one tilemap in the VRAM and use the rest to store graphics. The C&C maps are much bigger than one tilemap block however, but I will be storing the actual C&C tilemap in system memory. This will be as big as memory will allow. The C&C tilemap will point to and index of C&C tile blocks, these are like mini 3x3 tilemaps. (A native C&C tile is 24x24 pixels, while DS tiles are 8x8. So it's 3x3 DS tiles to make one C&C tile). I will then copy over the correct tiles to the DS tilemap as needed from the C&C tilemap in system memory. Whenever a scroll happens it will update the DS tilemap from the master C&C tilemap. If I begin to run out of space in VRAM for C&C tile graphics it would be in this scroll that I would swap tile graphics in memory to let me render everything I need. Hopefully this should be pretty quick, especially if I predict what tiles I need ahead of time and do a maximum of one tile graphics swap per frame for example.
I'm hoping the C&C tilemaps can get pretty big. Red Alert maps are typically these sizes: 64x64 (32kb), 96x96 (72kb), 126x64 (about 63kb), and 64x126. That is using 8bits for each tile cell. (http://ourworld.compuserve.com/homepages/CGibke/cells.html). This doesn't take into account anything else for the map, like objects, buildings, triggers etc. but just the terrain graphics layer.
This will give a limit of 256 unique C&C tiles per map, which I hope will be enough. If it's not I may have to just byte the bullet and use more memory, but we'll see.
Ok I hope most of this makes sense! It may not be the best approach, but I want to free as much VRAM memory as possible for graphics. I need to cram a lot of sprites in there too!
I had some screenies to bring in today but I forgot - sorry guys hopefully I'll have them tommorow.
More info --> http://cncds_project.livejournal.com/
I looked at this last night and most of the bugs were in the PC version dealing with the tilemaps. I fixed that and then started looking at how I would hold all this info in memory. My current plan is to use one tilemap in the VRAM and use the rest to store graphics. The C&C maps are much bigger than one tilemap block however, but I will be storing the actual C&C tilemap in system memory. This will be as big as memory will allow. The C&C tilemap will point to and index of C&C tile blocks, these are like mini 3x3 tilemaps. (A native C&C tile is 24x24 pixels, while DS tiles are 8x8. So it's 3x3 DS tiles to make one C&C tile). I will then copy over the correct tiles to the DS tilemap as needed from the C&C tilemap in system memory. Whenever a scroll happens it will update the DS tilemap from the master C&C tilemap. If I begin to run out of space in VRAM for C&C tile graphics it would be in this scroll that I would swap tile graphics in memory to let me render everything I need. Hopefully this should be pretty quick, especially if I predict what tiles I need ahead of time and do a maximum of one tile graphics swap per frame for example.
I'm hoping the C&C tilemaps can get pretty big. Red Alert maps are typically these sizes: 64x64 (32kb), 96x96 (72kb), 126x64 (about 63kb), and 64x126. That is using 8bits for each tile cell. (http://ourworld.compuserve.com/homepages/CGibke/cells.html). This doesn't take into account anything else for the map, like objects, buildings, triggers etc. but just the terrain graphics layer.
This will give a limit of 256 unique C&C tiles per map, which I hope will be enough. If it's not I may have to just byte the bullet and use more memory, but we'll see.
Ok I hope most of this makes sense! It may not be the best approach, but I want to free as much VRAM memory as possible for graphics. I need to cram a lot of sprites in there too!
I had some screenies to bring in today but I forgot - sorry guys hopefully I'll have them tommorow.
More info --> http://cncds_project.livejournal.com/