Skip to content

Best Practice: SNES Game Design Guidelines

You are here:
Estimated reading time: 11 min

Best Practice: SNES Game Design Guidelines

(through the eyes of a programmer)

SNES is a really neat platform. Compared to its little brother (NES) it’s even more compelling. 

However, the odd nature of the hardware makes designing and programming games a challenge. This guide is not the most comprehensive one but rather it tries to emphasize the particular SNES-related best practices and techniques.

It’s also written by a programmer to save you the headache from those guys like me coming back to you telling why this-and-that can’t be done.

VRAM

This should be familiar if you know NES a bit: any graphics-related data is stored at a special area called VRAM. This is short for “Video RAM”. It’s often separate in early game consoles – then again it is separate in later consoles too with the introduction of GPU-s. 

There are a number of advantages and disadvantages to this design. What’s important regarding the SNES is the same as for the NES: it only can be accessed when rendering is switched off.

You may ask how is this a flexible design at all. Well, for starters it isn’t, but just like the NES the SNES is also able to access its VRAM during a vblank period. This is the time between a PPU frame finish and frame begin.

The SNES also has some neat toys like DMA channels to make it work even better. More about DMA-s a bit later.

“This is all you have for sprites. Some games (like the one above) is happy with it”If anyone asks the VRAM size on SNES is 64K. While this sounds good, it contains *ALL* the possible graphics data including tile data, tile map, sprites. We’ll get back to it a bit later.

“This is all you have for sprites. Some games (like the one above) is happy with it”

Advices:

  • VRAM is flexible but limited. It however can accommodate all of your BG needs.
  • It is only accessible when PPU is turned off (no display) or during vblank. 
  • DMA and CPU both can write to VRAM.

Background graphics

The SNES has a number of graphic modes to choose from. It is summarized in many documents. Just to reiterate:

MODE   # of BGs    Max Colors/Tile                 Palettes                Colors Total

0               4                    4                                    32 (8 per BG)        128 (32 per BG*4 BGs)

1                3                   BG1/BG2:16 BG3:4    8                               BG1/BG2:128 BG3:32

2                2                  16                                    8                               128

3               2                   BG1:256 BG2:16          BG1:1 BG2:8          BG1:256 BG2:128

4               2                   BG1:256 BG2:4            BG1:1 BG2:8          BG1:256 BG2:32

5               2                   BG1:16 BG2:4               8                               BG1:128 BG2:32

(Interlaced mode)

6              1                     16                                   8                                128 (Interlaced mode)

7              1                     256                                1                                  256

BG stands for background. Just think of it as a semi-independent layer of graphics. We’ll get back to the semi-independent part a bit later.

Yes, it’s still tile-based graphics. That means pixels are still packed into tiles even when you request a 256 color mode or even the popular (or dreaded) mode 7.

It effectively means if the BG has to be manipulated, it’s still two bytes per tile which is quick. Also scrolling and even transparency is handled by hardware, the programmer doesn’t have to do much with it.

However, what has to be considered is that BG-s share the one and only CGRAM. This color ram area has 256 entries and not all modes can use all of them. For example: mode 1 has three BG-s and they all share the same 128 entries. Did I say 128? Yes, since the sprites use the other 128 entries. 

The “palettes” column here means how many sub-palettes a BG can use. The CGRAM has 16 sub-palettes which each is made of 16 entries – that’s how it is 256 entries in total.

Also the CGRAM is shared, there is only one of it. No matter how much BG-s you have you can’t have multiple CGRAM-s – not without special tricks but more on that later.

There are a generous amount of tiles. Not only these can be mirrored but the tile id is stored on 10 bits. That’s 1024 of them. Also (except 256 color modes) a tile can have up to 16 colors, effectively pointing to one of the sub-palettes in CGRAM. You’ll also hear the number “896” all the time and you may wonder how many tiles you can have then: 1024 or 896?

The explanation is simply: you can have 1024 but only 896 is visible since the NTSC SNES screen is 32×28 tiles which is: 896.

 An important detail here that you may use as many VRAM for BG-s as you want (of the 64K) just think of the sprites before you do that.

“The baby here is definitely not a sprite, but you are! (and flat)”

Advice:

  • The most typical mode is Mode 1. This has a good balance of BG-s and features.
  • BG-s don’t have rendering or scrolling overhead. However the more data you need to move onto them the more DMA or CPU time you will need.
  • Do ask if tricks can be done with BG-s instead of sprites if there is a doubt. Often it can help a lot.

Mode 7

This is a really cool mode. It only has 256 tiles and a single BG which has a tilemap of 128×128 entries. It’s documented as “having full matrix transformation abilities”. While this sounds nice it means: rotation and zooming/shrinking.

Often there are games that imitate 3D environment and claimed to be made with mode 7. Well while it is correct, it’s not only mode 7: they use another toy called HDMA. 

“Rotation and zooming at the same time – and also some HDMA”

Also if there is a game which has multiple BG-s with mode 7 those are cheaters: either a separate sprite layer is used or a mode switch happens mid-frame using the same toy: HDMA.

“Rotation and zooming at the same time – and also some HDMA”

  • Remember, you don’t have multiple BG-s in Mode 7. You still have sprites though.
  • It’s not only zooming or rotating. It can be both.
  • While it’s nice to have matrix transformations remember the precision is limited. Getting too close or too far will end up with artifacts.
  • The rotation or zoom has no overhead but calculating sprites putting onto the right spots and right angles do – if you want that sort of thing.

Sprites

Since we talk about sprites, let’s mention what sprites the SNES has. Unlike the NES it can display more sprites with more color. The sprites can have 16 colors each – you guessed it – by using a sub-palette from CGRAM. They also come in various sizes. That’s right, it’s not totally necessary to assemble metasprites like on NES – although there’s nothing stopping you to do so.

While it sounds more flexible, it’s not all nice and good. The sprites can have two of the pre-determined sizes on screen at the same time:

8×8  and 16×16
8×8   and 32×32
8×8   and 64×64
16×16 and 32×32
16×16 and 64×64
32×32 and 64×64

Well it’s not that bad, isn’t it? Since there is 64K VRAM we can have a lot of sprites! Except we can’t. Sprites can use up to 16K of the VRAM only. This is divided into two 16×16 tile area, one for each sprite size. Not so much, considering it means only two(!) 64×64 sprites.

This is where creativity helps. The SNES DMA engine is fast enough to rewrite sprites during a vblank! This means even if sprite VRAM is small, you can have as many frames for a sprite as you want! Well, the ROM space still limits you but that’s much larger than 16K.

The important detail here that you can’t refresh all the sprites in the VRAM during a single frame but do you really want to? That means 60fps animations which is rare on the SNES. Animations usually happen at 30 or even 15,10 fps and that’s totally possible. The refresh can happen during multiple frames – or just when it needs to be!

Some may think it’s no good since it ends up in a jerky movement or similar but ugly looking artifact. Fortunately the sprites still can be moved on the screen at 60fps it’s the animation that happens to be slower only – which usually is anyway.

But how much is “a lot of sprites?” There are technical limitations and it’s not as straightforward as it sounds:

  • The maximum number of sprites is 128. There is no way to address more. It has to do with OAM size but it’s not important in this document.
  • The maximum sprites per line is 32. If more sprites would fall into the same scanline the first one is skipped. This is regardless of the sprite sizes.
  • The maximum 8×8 sprite tile per line is 34. Again regardless of what sprite size is used if this fills up the first tiles will be skipped and not rendered.
  • The last limit is maximum 256 sprite pixels(!) per scanline.

There you have it. It’s not easy to keep in mind so the best advice is: use sprites with care. If flicker happens and it’s unbearable look up these limitations: you may be hitting one of these.

Another thing that seems to be obvious (but it isn’t) is: which sprite covers which? There is a priority control in sprites but that’s not relative to other sprites. The only way to make it sure to sort the sprites in Z-order. That basically means the programmer has to know which sprite to display first (to be the foremost) then the rest.

“Sprite priority was never been more obvious just take care of sprite limits too!”

Advice:

  • Sprite mirroring on both x/y axis is for free but anything else isn’t.
  • Sprite scaling, rotation costs extra. You can always have them pre-calculated though.
  • Sprite sizes are not absolute: you can make up a bigger sprite of smaller ones or use a bigger sprite partially.
  • No more than 16 colors per sprite, sorry. If you need more that’s multiple sprites overlapping each other.

Scrolling

Even if this could be a chapter on its own there are only a few things that’s special on the SNES. All backgrounds can be independently scrolled. The nametable (tile map as some may call it) is either 32×32, 32×64, 64×32 or 64×64. No need for mappers and scrolling tricks. Almost any kind of scroll is possible. That’s all there is to it.

Did I mention the BG-s can be transparent? A BG with transparent elements can be scrolled over another BG using as a fake sprite, a huge boss character or similar. 

DMA

We talked a lot already about DMA and I promised to get back at it. So here it is.

DMA stands for Direct Memory Access. It happens at various stages of screen rendering or sound playback. The key point to remember that it’s happening without the intervention of the CPU. 

The SNES has a dedicated DMA engine. It’s much faster than the CPU and it has 8 channels. It basically means that it can do 8 transfers at the same time but then the speed drops down to 8th.

The generic DMA is used to copy data into VRAM for example during a vblank. This is how the sprite limit barrier can be lifted for example. It can be used for BG-s too but it gets better:

It’s also capable to do HDMA which means to repeat one (or two) things at the beginning of *each* scanline. H stands for “Horizontal” here. It’s very flexible. 

Think of color bars on the screen, logos or background lines moved independently, rainbow colored sprites. Also those perspective effects are made with mode 7 and HDMA: the zooming factor is changed at each scanline, resulting in a perspective look.

The key here is “each scanline”. What the snes can do the whole screen at time it can do at each scanline.

Behind the scenes the HDMA changes one or two register values per scanline so it can’t change too much things but often that makes a huge difference already.

“Those colors are not drawn but made with HDMA.”
  • Remember, only one or two variables can be changed per scanline – but there are a lot of variables.
  • If one scanline is not enough, can it be done in more than one? Possibly yes.
  • Sometimes an idea sounds good but may look bad. It’s not a magic bullet and sometimes less is more.

Priorities

This could be important since with the SNES a lot of transparency effects are going on and various layers are used with a lot of sprites etc…..

There is a determined order how the rendering is applied. This can be manipulated with the priorities. The order is the following:

p (Priority) 0             1
Drawn first  BG4, o=0     BG4, o=0
  (Behind)  BG3, o=0     BG3, o=0
          Sprites with OAM priority 0 (%00)
          BG4, o=1      BG4, o=1
          BG3, o=1      OAM pri. 1
          OAM pri. 1    BG2, o=0
          BG2, o=0      BG1, o=0
          BG1, o=0      BG2, o=1
          Sprites with OAM priority 2 (%10)
          BG2, o=1      BG1, o=1
Drawn last   BG1, o=1     OAM pri. 3
  (in front) OAM pri. 3    BG3, o=1

This is very dry and technical. Point is, the order BG-s and sprites are rendered can be changed. What’s important that it is changeable:

  • Per sprite
  • Per tile(!)

Yes. You can have a BG partially in front of and behind another layer – and we’re still talking about the same BG.

CPU (aka. Raw Power)

The SNES has a very odd one. It’s a WDC 65816 clone. This is somewhat a successor of the 6502 core the NES had. In compatibility mode you can do pretty much anything you did on the NES. Yes you have BCD support as well.

When in native mode, it behaves as if it was a 16-bit CPU but with a lot of 8-bit legacy.

That pretty much means the programmer has to know precisely what addressing mode, instructions it uses since there is NO switch between 8 and 16 bit operation. More exactly there is a switch but it’s not forcing anything. Ask your programmer when there’s doubt about code correctness whether he/she mixed it up or not.

It can however address up to 16MB (yes, megabytes) of memory since it can use 24-bit addressing too – of course it’s not as happy as it seems. Since all of the three registers (unfortunately there is no more) can be 16-bit there’s one extra register which stores the BANK to be addressed. Yes, memory is not that freely accessible. Each bank is made up of 64K memory and the 65816 calls the addressing in a bank an OFFSET.

Anyway, apart from this the important part that it can do more under the same time since it can handle 16-bit and it’s running faster than the NES: 3.58MHz. It’s about……….<—–> this much. Yes it is faster, the hardware has better capabilities but: your mileage may vary.

  • This CPU has no multiplication or division, the programmer will try to rely on pre-calculated tables or other tricks – BUT the SNES PPU can do both multiply and divide. 
  • It’s still a relatively slow “6502 goofball” as some people call it. Don’t expect too much like from the SEGA Genesis 7MHz 68000 which is a true 32-bit CPU.

High and Low of Cartridges

The SNES generally has two types of cartridges: LoROM and HiROM. You can read all about it on Wikipedia or in any of the SNES Dev wikis. While it is important to know for the programmer which one he deals with, it’s less important for game design: both can address up to 4MB.

Since today’s cartridges use state-of-the-art technology they’re pretty much the same in terms of capacity and speed. They just emulate either LoROM or HiROM.

Was this article helpful?
Dislike 0
Views: 14
Back To Top