It is currently Wed Dec 13, 2017 2:27 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Wed Nov 02, 2016 1:19 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2424
I'm writing a level editor, but my game uses HiROM, and from what I can find, Nintendo's HiROM cartridges can only store 256kB of SRAM, but in 8kB banks. Is there a way to configure a ROM so that it has 512 kB of SRAM in a linear mapping from, say, $40:0000-$47:FFFF?


Top
 Profile  
 
PostPosted: Wed Nov 02, 2016 2:25 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19335
Location: NE Indiana, USA (NTSC)
I don't see how 8K chunks are so bad. Think of it like a disk with 8K clusters. You store the level that the user is building in $7F0000-$7FFFFF, then you save it out to $006000-$007FFF, $016000-$017FFF, ..., $3F6000-$3F7FFF.

But in practice, I'm not sure how the user is going to be able to fill 512K with just a controller. Are you planning to support a Super NES Mouse? Could you give a short breakdown of how the 512K will be allocated? Because Dezaemon uses only 128K. Even Animal Crossing: Wild World for DS only uses 88K or so out of the 256K serial flash in the Game Card, with the rest used for a backup copy in case saving goes wrong and for letters stored at the Post Office, and much of that is used with developer time prioritized over space. And a few years ago, we discussed how to simplify the design to cut the save file to under 32K.


Top
 Profile  
 
PostPosted: Wed Nov 02, 2016 3:35 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2424
2 bytes per 16x16 block * 512x32 blocks per level * 16 levels = 512 kB.

Of course I probably won't need 16 levels, and I could bring it down to 1 bytes per block, but there would still be a break in the middle of the level.


Top
 Profile  
 
PostPosted: Wed Nov 02, 2016 3:57 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19335
Location: NE Indiana, USA (NTSC)
One way to cut this down is to use compression when loading and saving levels. For each 32-metatile column of the level, store a 32-bit word saying which metatiles are identical to the one above it: 0 for different or 1 for a repeat.

If not all 65536 metatiles are used, such as if you have 1024 or fewer unique metatiles, you can use a prediction trick to compress even those vertical sequences that aren't exact repeats: use the current metatile as an index into a lookup table of what metatile is most likely to be below it. Then your RLE scheme becomes 0 for the most likely or 1 for something else. So what needs more than 256 distinct metatiles? What sort of "break in the middle of the level" are you talking about if there are more than 256?


Top
 Profile  
 
PostPosted: Wed Nov 02, 2016 4:58 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2424
A level would take about 32kB if using 2 bytes per metatile, or 16kB if using 1 byte per metatile. So it still needs to be split in half if stored in 8kb chunks.

I do have an idea. Since a level editor isn't very CPU intensive, I can just use a subroutine to calculate the 24-bit address of collumns.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group