nesdev.com

It's not using it for RAM, but Big Bird's Hide and Speak stored a bunch of sound samples in CHR-ROM for extra room. It reads them into RAM during vblank to play back during the frame, it's rather insane!

It also depends on how much terrain is modified. In my game, the player typically can't destroy or modify any of the level terrain. There may be a case where there's a couple blocks the player can destroy somewhere in a level. My solution to this would likely be to create an enemy object that does nothing but sit there, looking like a block, waiting to be destroyed. Then the small amount of RAM set aside to keep track of destroyed enemies would handle the absence/presence of this block later on. I also have what I call "event code" for each level. It's basically a block of code unique to each level that does things not handled by the engine. I could have the code check for collision between a player weapon and those specific tiles (which would count as destroying the tiles), and keep track of it with just a few bytes in RAM. Then later, when the player goes back to that area, it can replace the tiles with blank ones depending on the status of those bytes. This is far less elegant, but still an option.

I'd recommend following Celius (blocks as enemies) if you have only a few things that can be broken like item boxes, or following tokumaru (destruction bitmap, at the cost of not being able to cache a sliding window around the player) if you have huge fields of breakable or collectible things like coins or the bricks of WORLD 1-2 in Super Mario Bros.

Or just trade programmer time-is-money for replication cost, as the M.C. Kids programmers ended up doing.

Yeah, if we're talking few blocks they should definitely be handled like enemies/objects. In fact, even big amounts of breakable blocks could be handled similarly: create a generic "grid of breakable blocks" object, with configurable dimensions and pointers to the RAM locations where their bitmaps are.

Ideally you'd set aside some RAM for the decompressed part of the level that follows the player, so that you can "patch" the level map using the bitmaps as you decode it, which shouldn't take much CPU time. As soon as blocks are destroyed, you update the decompressed map and the bitmaps, so that they are rendered correctly the next time they scroll into view.

So, every time a game changes mirroring so that it can scroll on a different axis, it should first align the camera to the nametable, right? If movement is grid-based, like in Final Fantasy, though, I would think every step would end aligned to the nametable.

You guys have also talked a lot about storing data in unorthadox places, in particular when dealing with destructible level terrain. It sounds like the best way to handle it really varies with the nature of the game, but I hadn't really thought about it much. When I think of destructible terrain, I think something along the lines of Rampage, but large portions of Mario 3 would classify as well. And I suppose the same things would apply to dynamic terrain, like a lot of puzzle games have.

I understand that background tiles are 8x8 but that their attributes (such as color palette) are held in 16x16 chunks. Is there anything I should know about interacting with tile attributes?

Another question that came to mind: Are there any significant legal issues that come up when dealing with NES homebrew?

No, every step would be aligned to a tile, not a nametable.

You have a grid of four nametables (two are the same). Within them is a grid of 32x30 tiles.

If you're nametable aligned (scroll at 0, 0), and move a tile to the right (8, 0), you're still tile aligned but not nametable aligned. (One column of tiles from one nametable, the other 31 columns from the other nametable.)

If you're nametable aligned, you're tile aligned, but not necessarily vice versa. (Much like a square is a rectangle, but a rectangle is not always a square. )

Edit:
Except for color "glitches" appearing on the left and right (or top and bottom) sides of the screen depending on the mirroring you use, there's not much special about it.

_________________
https://kasumi.itch.io/indivisible

If the scroll is anything but (0, 0), the screen is not perfectly aligned to a name table, meaning that there are parts of at least 2 name tables sharing the screen, meaning players will notice if the mirroring type is changed from one frame to the next.


That goes for most aspects of NES games. You'll always want to arrange your data in a way that's accessible at the rate you need, while occupying as little space as possible. This is why there are no standard solutions for NES game engines... Each game has its own requirements that must be taken into account in the design phase.


Yeah, I guess they are similar concepts, but Rampage and puzzle games have very confined levels, so it doesn't take a lot of RAM to completely represent them. SMB3 on the other hand has pretty large levels, and the programmers went with extra RAM on the cart so that they could place (and modify) the levels there. Our talk was mostly about how they probably could have achieved the exact same effect without the extra RAM.


The color palette is actually the only attribute specified in the attribute tables... =) Many other systems have tile priority and flipping in their attribute table equivalents, but on the NES it's just palette indices. I don't think there's anything else you need to know about this in order to recreate the look of NES games.


I don't think so. AFAIK, reverse engineering is not illegal, and all the development information we have was obtained that way, not from official Nintendo documents. Also, all patents related to the console expired in 2005. I think that as long as you don't use any copyrighted materials (music, graphics, characters, etc.), you're safe.

What an interesting technique for getting a four-cycle auto-incrementing memory read. That could be a valuable in a specialized NES routine or demo that needed to quickly read lots of data faster than 6 cycles/byte (X/Y increment). It can be put into the nametable/CHR RAM. I'll have to make some use of this sometime.

Okay, I get it now. Well, sort of. To tell you the truth, the nametable is still a little confusing, but I understand what you're telling me. And, looking back at my own examples, Zelda only scrolls one screen at a time. And in Metroid, the entire map is composed of screen-sized units, and mirroring only changes when one of said units is on the screen in its entirity (though not necessarily the same quadrant of the nametable?) The camera even nudges a bit first if it's out of alignment.

So let me make sure I have this straight. The nametable can be modified offscreen along one axis. If the camera is scrolling along the other axis, those tiles can't be updated until they are already onscreen. When mirroring is changed, half of the nametable (top or bottom, left or right) is copied to the other half, regardless of where the camera is pointed at the time. Is that about right?

I was also taking a look at the way Mega Man 5 handles animated tiles the other day. In particular, in Gravity Man's stage. They don't seem to be grouped together like Mario 3 does (maybe I'm wrong, but perhaps they could have been more efficient with this?) and they also aren't consistant with the way the animations function. Thus, a game could have different kinds of animated objects, different triggers, maybe a different number of frames, so long as they're careful about which objects are onscreen at the same time, right? Strangely enough, Mega Man 5 was NOT very careful about this, and one of the blinking arrows in Gravity Man's stage has its animation tied to the horizontal movement of the camera.

Nothing is "copied" when mirroring is changed. The existing data in the nametables is rearranged. For example, if I put a big A in one nametable and a big B in the other, I'll get this pattern (which in theory repeats indefinitely) in vertical mirroring:

But if I tell the mapper to switch to horizontal mirroring, the pattern instantly changes:

Rad Racer relies on making this instant change halfway down the screen at the boundary between sky (whose scrolling wraps horizontally, for which it uses horizontal mirroring) and road (whose scrolling doesn't wrap horizontally, for which it uses vertical mirroring). But for a normal scrolling game, seamless mirroring changes work only when the scrolling is screen-aligned. For example, if the screen is centered over the first letter on the first row or the second letter on the second row, changing the mirroring won't change the display.

Adding one gate to the cart PCB produces a mirroring mode that allows screen-aligned direction changes without any mapper writes, as the game can just tell the PPU to switch from one B to another.


An OR gate provides L-shaped mirroring. At least one Famicom game is known to use L-shaped mirroring.


An XOR gate provides diagonal mirroring.

A lot of this might be easier if you provide screenshots.

I think you got the terminology wrong. Each name table (which you appear to be calling "quadrant") is 256x240 pixels, and there are 4 of them (although there's only enough memory for 2, hence why mirroring exists). The resulting 512x480 area is simply called "the background".


Yes, it's just harder to manage and will probably need more tiles in the end, but it's definitely possible.


I will have to check the game later.

The way Mega Man 5 does it is efficient, at least to some extent. None other stages has animated tiles in this fashion (they are animated with palettes), and Gravity Man in the only stage with this effect. The game uses 2kb (128 tiles) switching banks for BG, and 1kb for sprites. It relies heavily on the 1kb on the sprites, as this allowed them to cheat and reduce the pattern table space Mega Man takes as opposed to other games in the series, so this allows more varied enemies on the screen at one single time.

Since they had this system no matter what, doing the CHR-ROM animation in gravity man's stage would eat them several 2kb banks. Since those banks are "eaten" anyway, it doesn't cost anything to add non-animated tiles in them as well.

Also Mega Man 5 uses 256kb of CHR-ROM which is very large, very few games uses this much (and many who does stores PRG data in it).



I'm curious, what do you have in mind when mentioning this ?
To be honest, vertical, horizontal and single screen are the most useful. You can do almost anything with them.
Also, even on mappers with switchable mirroring, many game only uses one all the time. Or they use one for the title screen and another for gameplay, or something in the like.
Very few games actually switch mirroring while scrolling. In fact I think Zelda and Metroid are probably the only ones I can think of.

Okay... I think I might have it now. If only two of the nametables are kept in memory for a typical game though, and the other two are mirrored, it might be easier for me to conceptualize it if I just forget the other two nametables exist, and think of the two in use as wrapping around on the other axis. While it might not be technically accurate, wouldn't it amount to the same thing in practice?

(In either case, I need to make a decision in the way I lay out my maps: I either need to limit myself in the way I place barriers at certain borders so that the player can only cross them when the camera is aligned to one "screen" of the map, or I can have free eight-direction scrolling with more freedom in my map design and a more open feel to the game. In the latter case I'd like to try to simulate the scrolling artifacts this would entail. That could be fun.)

Note that the blinking arrows, if I'm not mistaken use both flipbook animation and palette animation at the same time. The arrows in question are at the end of a segment with a flipbook parallax effect in the background.

I have another question: Is there any kind of universal rule to how much of a sprite has to be onscreen before it becomes active?

An aside: I've been working on graphics for the game, and I've noticed that my 8-bit pixel art isn't quite up to snuff, in particular when dealing with backgrounds (I'm used to working in vectors.) I think I've managed to capture the aesthetic of some early era titles, but when compared to later games, it doesn't hold up. Maybe I should take a cue from later Mega Man titles and work with more monochrome objects. I'm open to tips and suggestions.

That's a useful model for mirroring behavior.


A sprite can be partially off the right side or bottom of the screen, but the top left corner of the sprite has to be on the screen in order for any of the sprite to be visible. This means the sprite can't be partially off the left side or the top of the screen, though there is a window register to replace the left 8 pixels of the whole screen with color 0. For example, the wider left border seen in Super Mario Bros. 3 is this window in action. And again, NTSC TVs tend to hide the top few lines of the screen.


Some objects in Super Mario Bros. 3 and Kirby's Adventure are fairly monochrome as well. The palettes typically have a dark outline color, a middle-brightness clothes color, and a light skin color that may double as a highlight color.

Sprites are simply displayed at the location specified. The location specifies the top left corner of the 8x8 tile and has ranges: X [0,255] and Y [1,256]. If part of the sprite happens to be offscreen, it is simply offscreen (there is no wrapping).

Since there's no [-7,-1] range for X, this means if you want to scroll a sprite on from the left it will just pop on fully formed at position 0. You can, however, toggle a rendering flag to hide the 8 leftmost sprite pixels if you want to show partial sprites on the left side. This is best used with the related flag that hides the 8 leftmost background pixels as well.