Tips on saving space for your SNES homebrews.

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
LucianoTheWindowsFan
Posts: 28
Joined: Mon Jun 22, 2020 9:39 am

Tips on saving space for your SNES homebrews.

Post by LucianoTheWindowsFan » Fri Aug 07, 2020 4:53 pm

1. Compressing graphics, yet it is a bit harder to do so you might skip this.
2. Lowering the filesize of graphics without compressing them, just remove the last empty bytes in your favorite hex editor.
3. Moving sprite pieces to save space.
4. Optimizing graphics as well as music.
If I missed any, let me know.

User avatar
Nikku4211
Posts: 102
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: Tips on saving space for your SNES homebrews.

Post by Nikku4211 » Fri Aug 07, 2020 8:25 pm

5. Use 2BPP background graphics. They take up less space in VRAM.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

User avatar
Memblers
Site Admin
Posts: 3877
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: Tips on saving space for your SNES homebrews.

Post by Memblers » Fri Aug 07, 2020 11:58 pm

6. With WRAM being plentiful, you might also choose to decompress level data, look-up tables, or even code (unrolled loops will compress well - but likely are still slower than code in FastROM). You can decompress music data (but don't bother with BRR samples) before sending it onward to the SPC.

When I made my SNES NSF player, I was astounded at how much I was able to fit into 4Mbytes. I used RNC Pro-Pack by Rob Northen Computing, compressed all the NSF files, screenshot tiles and tilemaps. The intro music is the only NSF that isn't compressed, so it loads faster.

Maybe this is only a problem for big projects, but in that case there were so many banks, and so many included binary files with a wide range of sizes. I distributed the files among the banks by hand, but even better would have been to..

7. Have a tool to "tetris" all the packed data together optimally into multiple banks. Alternatively, you could have your reading loop span banks, but it seems a little overkill when you have a bunch of small files, so it only crosses a boundary like 0.005 percent of the time anyways.

It could be really cheap to make a 512kB SNES cart. If a game is going to be released digitally, honestly probably better off not worrying about size at all, since compression adds loading times, and all that.

none
Posts: 38
Joined: Thu Sep 03, 2020 12:56 am

Re: Tips on saving space for your SNES homebrews.

Post by none » Thu Sep 03, 2020 11:41 am

Think about whether 8x8 or 16x16 tiles are better suited for level / sprite data.
Try to make a good packing scheme for stuff like collision data.
When designing a level / tilemap, think about how you can reuse tiles for different purposes. Remember that you can mirror tiles and do palette tricks.
If you have enough time for loading, try to generate some data in code.
You can implement a "room" / "object" scheme in your level data so that things can be reused in different places.
Use run length encoding where it makes sense. It decompresses fast and its quite good in many cases. Depending on use case, you might even decode on the fly and your algorithm is faster than without compression.
For music, try to use really tiny samples. But don't overdo compression here, you will quickly notice artifacts. Use patterns, if you can.
Look at examples of how other games did it.

User avatar
Nikku4211
Posts: 102
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: Tips on saving space for your SNES homebrews.

Post by Nikku4211 » Thu Sep 03, 2020 2:41 pm

9. Don't use too many lookup tables. Lookup tables are data, just like graphics, music, and levels. While they may usually take up less space, if you use too many, you can end up having half your ROM be lookup tables after lookup tables after lookup tables, leaving less space for graphics, music, and levels.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

lidnariq
Posts: 9659
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Tips on saving space for your SNES homebrews.

Post by lidnariq » Thu Sep 03, 2020 3:54 pm

Eh, on a NES game that's valid, because using lots of lookup tables is going to start running into constraints of the platform (64KB address space, most comparable games being 768KB or smaller). But of the SNES, almost no-one even considers trying to fit into the all-new-5V-parts limit of 512KB, so you may as well take advantage of a full 8MB 3V chunk of flash and its associated voltage translation. And unless you're baking in streaming content (i.e. video, audio), it's going to be a ridiculous amount of work to make as much resources as Pier Solar.

User avatar
tokumaru
Posts: 11858
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Tips on saving space for your SNES homebrews.

Post by tokumaru » Thu Sep 03, 2020 4:24 pm

Lookup tables are good when they're actually needed, even if they take up a lot of space. If your project wouldn't be viable without them, then they're probably more valuable than other things that could be using the same storage space.

User avatar
Nikku4211
Posts: 102
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: Tips on saving space for your SNES homebrews.

Post by Nikku4211 » Thu Sep 03, 2020 4:31 pm

tokumaru wrote:
Thu Sep 03, 2020 4:24 pm
Lookup tables are good when they're actually needed, even if they take up a lot of space. If your project wouldn't be viable without them, then they're probably more valuable than other things that could be using the same storage space.
That doesn't mean you shouldn't restrict their use to when they're necessary, and it doesn't mean you shouldn't take the time to optimise them for ROM usage.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

creaothceann
Posts: 253
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Tips on saving space for your SNES homebrews.

Post by creaothceann » Thu Sep 03, 2020 10:25 pm

Nikku4211 wrote:
Thu Sep 03, 2020 4:31 pm
doesn't mean you shouldn't restrict their use to when they're necessary, and it doesn't mean you shouldn't take the time to optimize them for ROM usage
It's very easy to make them necessary: just increase the number of calculations per frame until the game would be too slow without LUTs.

Also, increasing the ROM size has very little drawbacks these days, while decreasing ROM size would involve longer development times and lower performance, and perhaps reduced features and longer loading times.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

lidnariq
Posts: 9659
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Tips on saving space for your SNES homebrews.

Post by lidnariq » Thu Sep 03, 2020 11:28 pm

To rephrase what I and what creaothceann said:

There's exactly three relevant sizes for modern SNES homebrew that cares about a hardware release:

1- 512KB or less. The cheapest way to make any SNES cart at all using all-new parts, involving exactly two parts (a microcontroller for the CIC, and a single SST39SF flash)

2- 2MB or less. The cheapest way to make any SNES cart using used parts, involving exactly two parts (a microcontroller for the CIC, and a 2MB UVEPROM like the 27C160)

3- 12MB or less. Once you pay for the 3V regulator, the voltage translation, and the CIC, the incremental cost of a large chunk of suitable flash is small, so you're only limited by the SNES's native memory map.


Now, maybe what you really mean is "don't optimize prematurely", and that's always good advice. But that's very different from "try to not use space-for-time optimizations".

none
Posts: 38
Joined: Thu Sep 03, 2020 12:56 am

Re: Tips on saving space for your SNES homebrews.

Post by none » Fri Sep 04, 2020 1:42 am

I have lots of LUTs in my project and they are absolutely needed for speed. However, there is always a trade off, you can always use more tables to speed things up a little bit more. Just try to find the sweet spot between speed / size optimization.

Also, there are cases where LUT sizes can be reduced if you are intelligent about it, like when you use a sine / cosine table and only store a quarter of the function for example.

User avatar
Nikku4211
Posts: 102
Joined: Sun Dec 15, 2019 1:28 pm
Location: Bronx, New York
Contact:

Re: Tips on saving space for your SNES homebrews.

Post by Nikku4211 » Fri Sep 04, 2020 9:28 am

none wrote:
Fri Sep 04, 2020 1:42 am
I have lots of LUTs in my project and they are absolutely needed for speed. However, there is always a trade off, you can always use more tables to speed things up a little bit more. Just try to find the sweet spot between speed / size optimization.

Also, there are cases where LUT sizes can be reduced if you are intelligent about it, like when you use a sine / cosine table and only store a quarter of the function for example.
My point exactly.
I have an ASD, so empathy is not natural for me. If I hurt you, I apologise.

93143
Posts: 1225
Joined: Fri Jul 04, 2014 9:31 pm

Re: Tips on saving space for your SNES homebrews.

Post by 93143 » Fri Sep 04, 2020 2:12 pm

You could do 16x16 signed multiplication using a lookup table. Just remove the signs (and multiply them separately), shift and combine the resulting 15-bit values so that they constitute bits 2-31 of a 32-bit word, and write that to the address registers of the MSU1. Read four bytes, apply the appropriate sign, and Bob's your uncle. Only problem is that it can't deal with -32768, but that's an easy edge case to handle...


EDIT: to be clear, I'm in favour of lookup tables. My own projects and plans use them extensively - for instance, I came up with an extension of tepples' sprite scaling method to SNES that turns his handful of 256-byte tables into (IIRC) 12 banks of split 16-bit values, and I think it's worth it. But it is possible to overdo it, and I thought it was amusing to posit such an abuse.

Post Reply