Questions about NES Graphics Limitations

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

User avatar
Okk
Posts: 23
Joined: Thu Dec 19, 2013 9:29 pm

Re: Questions about NES Graphics Limitations

Post by Okk »

Thanks for that link, it cleared things up. I hadn't realized so many games did that kind of thing, and I also hadn't considered smoothing the effect by sacrificing some sprites.

The link also prompted me to do a quick search of these forums for Bucky O'Hare. That game seems to have a lot of "how'd they do that?" moments. But now that I think about it, I'd guess several of them used similar techniques to the halo of light effect: small updates to the nametable, with leading sprites to smooth the transitions. That's probably how they did the bit with the giant snakes? And maybe that part where those walls close in on each other was done the same way? It almost seems like a shame that the average consumer would probably never realize what a monumental achievement some of these games represent.

I went back and looked over that article on Mirroring again, and this time I actually understood some of it. With fceux's debug tools, it really helps when I can see what's happening in action, too. So I can see now that Mario 3's artifacts are whatever's going off the other side of the screen, but I'm not sure where the color palettes in these artifacts are coming from; that still seems a little arbitrary. I also peeked at some older games, like Zelda and Metroid, to watch them switch mirroring every time you walk through a door. I'm still a little confused about what's going on in FF1, though... If a game has a memory expansion for the save file, can this extra memory be used to avoid scrolling artifacts?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Questions about NES Graphics Limitations

Post by tokumaru »

Okk wrote:That game seems to have a lot of "how'd they do that?" moments.
True.
That's probably how they did the bit with the giant snakes?
Yup. Along with CHR-ROM animations to make it look like their body is constantly moving.
And maybe that part where those walls close in on each other was done the same way?
Yeah, one of the sides is drawn with horizontally repeating patterns, so that you can move them by updating only the edge(s), and sprites are used to make the edge move smoothly. There's also some CHR-ROM switching going on to cancel out the background movement (The background pattern repeats every 8 pixels, but the moving parts move in 4-pixel increments).
It almost seems like a shame that the average consumer would probably never realize what a monumental achievement some of these games represent.
True again. I watched a review of it on YouTube where the guy said the graphics were "adequate", but nothing to write home about. That hurt me a little bit! =)
So I can see now that Mario 3's artifacts are whatever's going off the other side of the screen, but I'm not sure where the color palettes in these artifacts are coming from; that still seems a little arbitrary.
The fact that color attributes are applied to 16x16-pixel regions combined with SMB3 only having an 8-pixel wide hidden area where to do updates results in an 8-pixel wide area with the wrong attributes applied. The actual colors you'll see will depend on which colors are actually used in the tiles. I mean, tiles aren't forced to use all colors of a palette, so a tile going off the screen at the left might look green because it uses a palette that contains green and orange, while the object scrolling in from the right might use the index that's mapped to orange in that palette, in which case a green object scrolling out might result in an orange object scrolling in.

Anyway, some games try to put part of the glitch on each side of the screen to make it less prominent, others try to put it on the trailing edge of the screen (which players are less likely to be looking at), and games like Alfred Chicken and Felix the Cat go out of their way to completely hide the offending area with a column of black sprites.
If a game has a memory expansion for the save file, can this extra memory be used to avoid scrolling artifacts?
No. The NES has 2 separate addressing spaces, one for the CPU and one for the PPU. The save memory is attached to the CPU addressing space, while extra name table RAM must be attached to the PPU addressing space, so you can't use the same chip for both purposes.

The extra memory isn't the only way to get rid of scrolling artifacts. A handful of games do have glitch-free 8-way scrolling with just the stock 2KB of VRAM, because the programmers went out of their way to fix it. Like I said above, Alfred Chicken and Felix the Cat use sprites to mask the glitches. Jurassic Park uses IRQs to bankswitch black tiles at the top and bottom of the screen. Big Nose Freaks Out disables rendering early (although it has a small glitch at the bottom left corner of the screen, which is necessary for it to know WHEN to turn rendering off).
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Questions about NES Graphics Limitations

Post by rainwarrior »

You don't see scrolling glitches in Final Fantasy because it uses vertical mirroring. With vertical mirroring, your virtual screen is double-wide so there's no reason to have any horizontal glitches on the left or right side. There are glitches at the top or bottom, but this part of the screen is hidden on an NTSC TV. If you put FCEUX into PAL mode while playing Final Fantasy you will clearly see the glitches at the top and bottom.

Even though vertical mirroring might sound like the way to go, based on this, there are lots of valid reasons not to use it, which might not be intuitive. Think about having to do a scanline split for a status bar, for example.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Questions about NES Graphics Limitations

Post by tepples »

Crystalis uses vertical mirroring and uses a scanline IRQ to change the scroll just before the PPU is about to hit the status bar, so that rendering skips the status bar. Jurassic Park and M.C. Kids use vertical mirroring and swap a blank pattern table into the background for the top and bottom few rows.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Questions about NES Graphics Limitations

Post by rainwarrior »

Crystalis does not, it uses horizontal mirroring (and has plenty of glitches at the sides).

What Crystalis does, I believe, is put the playfield on screen 1 and the status bar and dialogs on screen 2. When walking around the screen, it uses an IRQ to split the middle of the screen (variable position) to wrap for the scrolling, and then a second IRQ to switch to the status bar at the bottom of the screen.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Questions about NES Graphics Limitations

Post by tokumaru »

rainwarrior wrote:Even though vertical mirroring might sound like the way to go, based on this, there are lots of valid reasons not to use it, which might not be intuitive. Think about having to do a scanline split for a status bar, for example.
I honestly think that vertical mirroring is the best choice for 8-way scrolling. There are several games that handled the status bar issue and can teach us a thing or two. Horizontal mirroring will only help you so far, because when your levels are more than 2 name tables high you have to jump through some hoops for the status bar anyway. vertical mirroring just looks cleaner to me, and the glitches are easier to hide.
What Crystalis does, I believe, is put the playfield on screen 1 and the status bar and dialogs on screen 2. When walking around the screen, it uses an IRQ to split the middle of the screen (variable position) to wrap for the scrolling, and then a second IRQ to switch to the status bar at the bottom of the screen.
True. It uses an IRQ to skip the second name table and force the vertical wrap of the first name table. This is basically a way of simulating 1-screen mirroring. This is not so different from what tepples described (he did get the mirroring wrong), the game is skipping an entire name table after all.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Questions about NES Graphics Limitations

Post by Bregalad »

Wow, I just read the whole thread and it's funny.^^

@The author of the thread : If you're worried this much about making your games truthful to the limitations of the NES you'll probably want to do a NES port after it's finished. It should be done in not time if you stick to the limitations.

As for the 2kb of RAM, it's not nearly as limiting as it sound. First "2kb" sounds a lot more than "2048 bytes", doesn't it ? At least I think it does ^^
You just have to think and code very carefully to be as RAM-efficient as possible.

I wrote a action-RPG engine for a project similar to the one you're showing and I still have about 512 free bytes of RAM, plus I don't use most of the stack. In fact that's not a problem because you only have to store the state of the game in RAM, everything else is in ROM. Unless you're doing some self-modifying code or on-the fly decompression (I actually do this in my engine, but it's not polished yet ^^)

Personally I can't refrain to think most games that uses 8kb SRAM without saving could have been done without it if they were coded more carefully / a bit differently.$

As long as you're asking "What are the limitations of the NES", you'll always end up discussing the limitations for various mappers/carts hardware. The limitations of the console itself are very sparse :
1) The resolution is 256x240
2) You can show arbitrary patterns of pixels of the 13 background colours, but each group of 8 has to share the same palette of 3 colours (but fine "scrolling" can be changed every line or even within the line)
3) You can display only 64 sprites of 8x8 or 8x16 of arbitrary patterns, (you can change in the middle of the screen), each sprites has only one palette of 3 colours and they can't be changed during rendering (unlike machines such as the C64 for instance)
4) You can have arbitrary sound (on a famicom by using the expansion port, and on a NES using a coprocessor and the $4011 register)

If you don't bother modifying the console slightly, limitation 2) don't even apply anymore as you could put the PPU in slave mode to show arbitrary 13 colour graphics without the 8-pixel tiles thing at all.

So in theory you could make an ASIC that does texture 3D rendering with lots of VRAM on a cart, and have part of it which "downgrades" the rendered image to suit the limitations of the NES before "tricking" it into rendering the image, along with virtually boundless sound, and it'd still be a valid NES cartridge.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Questions about NES Graphics Limitations

Post by tepples »

Bregalad wrote:Personally I can't refrain to think most games that uses 8kb SRAM without saving could have been done without it if they were coded more carefully / a bit differently.
Yeah, like not being allowed to scroll backwards (SMB1) or by having destruction of terrain be reversed when the terrain scrolls back on (Vice Project Doom). When your game allows the player to destroy terrain, it must somehow remember what has been destroyed. How this destruction is stored in RAM along with the rest of the game state may impose restrictions on level geometry if the game is not using extra RAM. For example, in one system, each column of the map has one bit for destruction, but then only one thing in each column of the map can be destroyed.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Questions about NES Graphics Limitations

Post by tokumaru »

Bregalad wrote:Personally I can't refrain to think most games that uses 8kb SRAM without saving could have been done without it if they were coded more carefully / a bit differently.$
I agree with you on this one.
tepples wrote:Yeah, like not being allowed to scroll backwards (SMB1) or by having destruction of terrain be reversed when the terrain scrolls back on (Vice Project Doom).
I'm pretty sure Bregalad meant that games could have been programmed differently and still play the same, without such sacrifices.
When your game allows the player to destroy terrain, it must somehow remember what has been destroyed. How this destruction is stored in RAM along with the rest of the game state may impose restrictions on level geometry if the game is not using extra RAM.
This again? OK, it may impose restrictions in a few cases, but I agree with Bregalad that in a lot of cases it wouldn't. Think about it: the benefit of using 8192 bytes of extra RAM is that you can place levels there and and modify them as you want. Uncompressed levels typically use 1 byte per metatile (which is often the smallest unit that can be destroyed), so you could have up to 34.133 uncompressed game screens (possibly more if screens are smaller than 256x240). If instead of using extra RAM you used 1 bit of regular RAM to represent the state of each one of those 8192 metatiles, you'd need only 1024 bytes. That's half the stock memory of the NES, and maybe it would be possible to have the rest of the game use the remaining 1KB (The ColecoVision for example had to survive with that amount).

But that's for 34 screens! Most games don't have levels this large, and even if they did I doubt that all of them would be heavily modifiable. I can't think of a single game that works like that. You could have a much smaller number of bitmaps and link them to the screens/areas that actually need them. With 512 bytes you could still describe the existence of metatiles in 17 screens(!), leaving 1.5KB free for the rest of the game state. Wouldn't you say that covers most of the NES games you can think of that have destructible terrain?

It's just harder to code, because it's not as straightforward as modifying bytes in a 2D array. Instead you have to do some address conversions, handle some indirection, perform bitwise operations and patch data for collision and drawing purposes, but it's definitely doable by any competent programmer.

What this solution wouldn't cover are games that need arbitrary metatile replacing, like completely restructuring of the levels (if there are few possible states you can definitely store them in ROM though) but that's hardly a common thing in games, at least in such a global way that would cause you to go out of RAM.
User avatar
Okk
Posts: 23
Joined: Thu Dec 19, 2013 9:29 pm

Re: Questions about NES Graphics Limitations

Post by Okk »

tokumaru wrote:There's also some CHR-ROM switching going on to cancel out the background movement (The background pattern repeats every 8 pixels, but the moving parts move in 4-pixel increments).
A lot of these fancier games must devote a considerable portion of their space just to animating backgrounds. In games that use CHR switching to simulate paralax scrolling, how many frames is usually needed for a good effect? It seems that CHR-ROM switching isn't as popular for sprite animations...
rainwarrior wrote:If you put FCEUX into PAL mode while playing Final Fantasy you will clearly see the glitches at the top and bottom.
There they are, I see them now. They seem to be the correct colors, at least on the one map that I checked.

Here's a thought, though. Games like Zelda and Metroid might switch mirroring every time you go into a new area. In a game like Final Fantasy or Dragon Warrior, where the screen scrolls in four directions but only on one axis at a time, why not switch mirroring every time the player changes directions? In a turn-based RPG, latency isn't really a big concern. In fact, the controls in Dragon Warrior already handle as if the game has just woken up after a big surgery.
Bregalad wrote:@The author of the thread : If you're worried this much about making your games truthful to the limitations of the NES you'll probably want to do a NES port after it's finished. It should be done in not time if you stick to the limitations.
The more I learn in this thread, the more serious consideration I put towards that possibility. Of course, I'd have to learn how to develop for the NES first....
Bregalad wrote:As for the 2kb of RAM, it's not nearly as limiting as it sound. First "2kb" sounds a lot more than "2048 bytes", doesn't it ? At least I think it does ^^
You just have to think and code very carefully to be as RAM-efficient as possible.
That's a good point, and I was already considering that some earlier in the thread. But if my game has a save function, shouldn't I assume a RAM expansion is already present?
Bregalad wrote:So in theory you could make an ASIC that does texture 3D rendering with lots of VRAM on a cart, and have part of it which "downgrades" the rendered image to suit the limitations of the NES before "tricking" it into rendering the image, along with virtually boundless sound, and it'd still be a valid NES cartridge.
Well that... that is something. I know I tend to favor software-only solutions, but it is still fascinating that an NES cartridge can have hardware upgrades built right into it. That's something you can't do with contemporary games.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Questions about NES Graphics Limitations

Post by tokumaru »

Okk wrote:A lot of these fancier games must devote a considerable portion of their space just to animating backgrounds.
Well, they often have the animated stuff share the same CHR chunks, so it ends up not being that much, at the expense of having less than 256 tiles for drawing backgrounds.
In games that use CHR switching to simulate paralax scrolling, how many frames is usually needed for a good effect?
Parallax? You need one frame for each pixel position. If the repeating pattern is 16 pixels wide, you need 16 frame. 32 pixels wide, 32 frames. Since parallax backgrounds move slower than the foreground, you really must be able to move them pixel by pixel, otherwise it'll look jumpy.
It seems that CHR-ROM switching isn't as popular for sprite animations...
Later games with larger characters many times had a few CHR chunks dedicated to the main player, and would switch depending on what the character was doing. This was also popular in games where the main character has different "states" (small Mario vs. big Mario in SMB3, walking Kirby vs. flying Kirby vs. Kirby using different attacks, characters who change clothes, and so on).
In a game like Final Fantasy or Dragon Warrior, where the screen scrolls in four directions but only on one axis at a time, why not switch mirroring every time the player changes directions?
Dragon Warrior's mapper doesn't even have mirroring control, but the reason reason games that do have it won't do it is because the screen would get messed up if the scroll wasn't perfectly aligned to one of the name tables. See, if the name tables are arranged horizontally, and the character is walking right crossing the border between the 2 name tables and you suddenly put the screens on top of each other, the screen will look pretty broken. You can't take two pieces whose drawings are meant to fit side by side and put them vertically. The scroll would have to be perfectly aligned to one of the pictures for this change not to be visible.

You can try it yourself in FCEUX, where you have radio buttons to change the mirroring. Make sure the scroll isn't aligned to a name table and change the mirroring type. That's what would happen.
In a turn-based RPG, latency isn't really a big concern. In fact, the controls in Dragon Warrior already handle as if the game has just woken up after a big surgery.
If if you took delayed the movement in order to have time to update a lot of tiles, the areas the need to change are not offscreen, so you really can't do it without the player seeing what you're doing.
But if my game has a save function, shouldn't I assume a RAM expansion is already present?
Yeah, unless you decide to try some of the experimental FlashROM saves people have been considering for new homebrew games. Theoretically, it would be possible to save to the same FlashROM chip that contains the game program, so the cost for this is much lower than the alternative. Besides price, it has the advantage of being safer than battery saves (which are easily corruptible) and lasting longer (as much or even longer than the game itself) without any kind of maintenance.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Questions about NES Graphics Limitations

Post by Bregalad »

In a turn-based RPG, latency isn't really a big concern. In fact, the controls in Dragon Warrior already handle as if the game has just woken up after a big surgery.
In fact as far I remember, your character starts to walk only if the frame counter contains a multiple of 16 (four low bits are '0'). I don't remember why they added such a mechanism, but there probably was a (lame) reason. If you're lucky and are already on a multiple of 16, your character walks right away, but if you're not then you have to wait 15 frames before it starts to move. Yes this is lame and annoying.
Dragon Warrior's mapper doesn't even have mirroring control
You probably meant "Dragon Quest" here. It doesn't have mirroring control, nor does it have extra RAM nor saves. It all works with the internal 2kb of RAM and passwords. Also a major part of the 2kb of RAM is used to store program code which is read from CHR-ROM, and decoded into RAM, in order to have the game fit 32kb of PRG ROM. This is pretty impressive.

Talking about this, if 2kb of RAM REALLY isn't enough, you can of course use VRAM (either nametable or pattern tables, if CHR-RAM is present on the board), to store game state. The major inconvenient is that you can only read/write data to/from VRAM during VBlank, so this is a major issue. I've never seen any game nor demo doing this.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Questions about NES Graphics Limitations

Post by tepples »

tokumaru wrote:This again?
Someone brand new hasn't seen the previous topics on this.
tokumaru wrote:That's half the stock memory of the NES, and maybe it would be possible to have the rest of the game use the remaining 1KB (The ColecoVision for example had to survive with that amount).
The ColecoVision could also borrow VRAM to store game state more easily than the NES because the TMS9918 VDP had a second address register for access by the CPU during draw (no sharing loopy_v/t) and was able to stall the CPU until a time slot became available.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Questions about NES Graphics Limitations

Post by tokumaru »

Bregalad wrote:You probably meant "Dragon Quest" here.
Oh you're right. But Dragon Warrior is the US version of Dragon Quest though, right? So if the original didn't have mirroring control they'd hardly make use of it in the translated version even if they upgraded the mapper.
Also a major part of the 2kb of RAM is used to store program code which is read from CHR-ROM, and decoded into RAM, in order to have the game fit 32kb of PRG ROM.
At this point things start to get pretty hacky. I understand why they'd do this back then, but now that we don't have to bother about ROM sizes much I'd much rather use more PRG-ROM than deal with a complicated scheme like this.
Talking about this, if 2kb of RAM REALLY isn't enough, you can of course use VRAM (either nametable or pattern tables, if CHR-RAM is present on the board), to store game state.
That's a very good idea. If you think about it, the NES has 4KB of internal RAM when you account for the built-in VRAM. If you use CHR-RAM, that's a total of 12KB or RAM, which is not so bad. Using name table RAM can be hard depending on the type of scrolling you use, but giving up on some tiles is not a big deal at all.
The major inconvenient is that you can only read/write data to/from VRAM during VBlank, so this is a major issue. I've never seen any game nor demo doing this.
You'd definitely want to use it for data that doesn't need constant access, like data from areas not being played at the moment.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Questions about NES Graphics Limitations

Post by tokumaru »

tepples wrote:Someone brand new hasn't seen the previous topics on this.
But you're still claiming that sacrifices are necessary, which I disagree. =) I tried to post a better response this time, suggesting alternative ways to implement block breaking madness in just 2KB of RAM.
Post Reply