I've got a little side-project going that is designed to be an old NES RPG. As I've looked into it more, I have become enthralled by following the same limitations that the NES had; it has really engaged me in the project to constrain myself so.
EDIT: To be clear, I'm not talking about building an actual NES ROM; I'm talking about building a modern stand-alone game that is designed to be like an NES ROM.

Anyway, there are a couple limitations for the NES that have not been able to find information about, and I was hoping someone here might have experience with it and could help me.

The first is that I am wondering what limitations it would have in regards to the game's code. I am not actually writing this in an old language or such thing, but I would like the final to reflect the limitations of the original system. Basically, I'm not concerned about how the actual code functions per-se, but for what the final result looks like to the player. (Of course, this still entails much of the code following the original limitations.)

Off the top of my head, I'm pretty sure I can't use floats at all. Also, I would want most variables to only use bytes, or otherwise to not use values above 255. I think it would be technically possible to use higher numbers, but they would have to be used sparingly, and I do not know what those upper limits would be.

Another question I have about limits is the game size. This one I am really not sure about, and I suspect would be really hard to determine when I am hitting that limit. I have no real way to gauge how much space the code is taking up, and music, sound, map data, and more are going to be hard to figure out how much space they would use on the NES compared to how much space they are using for me. About the only thing I can concretely determine how much I have is the artwork.

Since how much space I am using is so ambiguous, I guess I'd really like some sort of primer to help me understand how the space is limited and how things eat up that space.

And while I am on the subject of NES limitations, I am wondering if someone can explain this one thing to me. When I look at the NES's color palette, the selection of the ones that are available on the system, there are ten blacks and two whites. Why is there an extra white and an extra black? And why are the E and F columns blank?

on the NES you had 2kb "working" ram, which is main memory. 2kb vram which had usually pixel data. additionally there was space for 64 sprites and some space for the color palette.

if I recall correctly the CPU could just address 16kb of memory in total, thus you had about 10kb of rom space, which was all code + game assets + sound in total.

you don't need to use an old language, you can use c or c++. a modern language is rather limiting you than empowering, as you probably need to do tons of tweaks to even get an executable which could fit on the rom.

I'd recommend you to get a simple programming environment + NES emulator and have the fun of your life ;), it's not only about using byte, you'll see what awesome things you can do when you have the full control of the hardware. something you cannot explain to ppl that have just wrote code that runs on some OS, in VB/Java/C# etc.

For example, a game cannot scroll vertically faster than 24 pixels/frame, horizontally faster than 16 pixels/frame, or diagonally faster than 8 pixels/frame on each axis. If a game uses RAM for tiles (instead of ROM), you can only update a small number of tiles each frame, which limits the amount of background animation you can do and how animated your sprites can be.

That faster than I ever intended to move, but it is good to know the actual restriction.

quote name='Anthony Serrano' timestamp='1440980411' post='5249794']
So optimally you have just enough time to transfer a single block of 256 bytes to VRAM (the most optimal transfer method is still restricted to 256 bytes period), which is 1/4 of a tile map or 16 tiles.
[/quote]

So that would mean I can completely replace all the tiles in the memory in 8 frames. (Boy, I wish modern games could do that. ;) ) I guess I should bump it up a few more frames if I'm changing the music as well or something like that, but if I want to do something like drop all of the sprites to load up a text box in their place, now I know how many frames I need to account for.

Actually, wait... I just realized something here. You just stated that 1/4 of a tile map is 16 tiles, which would mean 64 tiles. I had read that they could contain 256 tiles, which basically accounted to a 128x128 image.
Having both upper and lower case text alone takes up 96 tiles. Did you post some wrong numbers here, or am I misunderstanding what you are talking about?

Also, I just realized that what I had read stated that one set of tiles was usually used for sprites and the other for backgrounds, but it doesn't actually say that limitation is forced. Can I use the tile graphics interchangeably between the backgrounds and the sprites?

In fact, officially licensed games NEVER used column D, and you probably shouldn't use them either.

Awww, but that one has the only dark grey....

And that is how you get 48 unique non-grey colors, 2 identical whites, 4 greys (of which only 2 should be used), 9 identical blacks, and 1 blacker-than-black that shouldn't be used.

Yacht Club did a really good post-mortem on how they established an NES feel for Shovel Knight. It's available on gamasutra: http://www.gamasutra.com/blogs/DavidDAngelo/20140625/219383/Breaking_the_NES_for_Shovel_Knight.php

It might not be completely what you're looking for since it seems like you want to follow the NES restrictions more closely, but it could still provide you some inspiration.

If you want to, you can even chage what each tile set is used for mid-frame.

I... don't follow what you mean by that. Since there is no arbitrary restriction about whether an individual tile is used for a sprite or for a background, then "what a [whole] tileset is used for" is an arbitrary construct; I use it for whatever I want it to be. Like you said with Zelda II, one tileset was part sprites and part background.
And I looked at Smash TV, the title screen is just a static image. There are only four palettes used and they all fit into 16x16 blocks. That whole image is just drawn as a background, is it not? I don't see any indication that sprites are used, let alone that something is changed mid-frame.

And if the system is in 8x16 sprite mode, any given sprite can use tiles from either tile set.

BTW, what restrictions does a game have for changing between 8x8 and 8x16 modes? Permanent for the whole game? Any time the screen in blank? Each frame? mid-frame?

And what other restrictions does 8x16 mode bring? Since it can effectively double the number of sprites on the screen, it sounds like the ideal method to use; the only disadvantages I can see is that if you want characters that are an odd-number tall you will run into more problems with scanline flickering, and if you want to use multiple palettes in a single character/object you will have limits for how the whole object will be colored.

-----

I don't quite follow everything you are saying about the difference between RAM tiles and ROM tiles. Do you have link to another page that explains it, maybe with pictures?

I'm kinda guessing here, are you saying that the ROM method requires an entire tileset of 256 tiles to be set absolutely, so like, if I want a particular tile I must load an entire collection of 256 tiles that it is in; wheras with the RAM method I could have a complete tileset, but if in this one level I want just one tile to be different, I can change that one tile?

If that's the case, what is the realistic limit on how many tiles can be swapped out each frame? Wouldn't it be possible to animate a background, even if it was just a couple blocks worth of animation? (Although I suspect changing player animations might be a better use of those tiles, depending upon the game.)

Also, is this set by the hardware and thus can only use one method per cartridge, or would it be possible to swap methods in the middle of a game, even if it took a few frames? (Not counting what someone could theoretically do with a new chip today.) It would be neat to do something like have the overworld use a bunch of animated tiles, and then change modes when you go into a battle so I could have variety in enemy combinations.

EDIT: I just realized I may be making a false assumption about the nature of tilesets, so I should confirm. When I was once dabbling with some ROM editors for Super Mario World and Zelda LTTP (both on the Super NES) I noticed that the way graphics were loaded seemed to basically be that whole pre-dictated collections of tiles were loaded at any given time. They were basically like one whole image of tiles, and while there were multiple ones that could be loaded, they were constrained to exactly the tiles in that whole collection. Each one of those collections is a tileset, as I understand it. So if a tileset had all the sprites for two enemies, A and B, and another tileset had sprites for two other enemies, C and D, if all the other tilesets I had loaded were accounted for so that I could only load one more tileset, that room would have to have either enemies A&B, or C&D, but I couldn't have A&C, because they were on different tilesets and I could not load part of one tileset and part of another.

I would assume that is a restriction that exists on the NES as well, so I can't just load up any combination of 512 tiles I want; I have to arrange them in specific set combinations of 256, and I load the two pre-arranged tilesets I want for any given screen.
Except if I use the RAM method, then I can change out any individual tile, in any combination I need at the moment. (Limited by how fast I can load them, of course.)
To that end, are there limits for what order a tile in in the tileset? If I make a particular tile, and it is number 16 in the tileset, if I have another tileset loaded, but want that one tile, does that one tile still have to be number 16, or could I load it into number 86 if I preferred?

And as for loading an entire tileset using the ROM method, could I create an arbitrary combination that uses data from another tileset? Meaning like, I have some text tiles I always want loaded, but the rest of the tiles are for a forest area in one tileset, and for a desert area in another tileset. But both sets have the text tiles. Are those text graphics repeated twice on the ROM, like having two copies of one file, or do the tilesets point to the graphics, so the text graphics only exist once on the ROM, and both tilesets load the same text graphics? If the latter, are there restriction on how many tilesets I can create? Would I be wasting resources to have to have tow tilesets that are nearly identical save for two or three tiles?

Or am I mistaken in what tilesets are and how they work?

(end edit)

I can see how MM2 is doing palette animation; that is pretty clever. One color for permanent background, one for permanent red, and then two colors that switch between red and black, thus providing a two-frame monochrome animation.
But I can see a number of distinct changes in the mist tiles in Faxanadu that cannot be accounted for by palette animation. They look like they are animating by scrolling the tile, but that would require eight colors to have it look like it is scrolling with a palette swap. Plus they appear in front of the player. You can't palette-swap the transparency, can you? Transparent is always transparent.

Tinting the screen would just mean changing all 25 colors at once, wouldn't it? I mean, it's not like it's a secondary feature that shifts the 64 color options to a different tint, right?

And, as for that final section where you give the exact numbers... That's cool, but I don't know how to translate those stats into examples I understand. Is the X KB of tile ROM/RAM like, how much tile data can fit onto the cartridge itself? Because the only other interpretation I can think of is that refers to how much data is loaded and thus can be displayed in any given frame, as opposed to the 2x256 tiles that I was told is what it can handle. (And how many tiles is a 1KB page?)
I have no idea what the values for CPU RAM/ROM can do in real terms; I never studying programming languages that old. And f*** me trying to get my duct-taped-quality C# to fit into 256 K. (What kind of languages did they program these games in anyway? Were they actually written in assembly?)

I just realized I may be making a false assumption about the nature of tilesets, so I should confirm. [...]

In approximate order...

* Yes, because you have a mapper that can virtually map a few 1KB pages of ROM to the tileset/sprite memory areas, you can have several parts to your tileset, but you are fixed in what each part contains. If your tilesets have visual overlap, they'll have duplication.

* If you're using RAM for tilesets, you get a span of RAM that you get to manage and populate yourself. And although you have a DMA-like block copy mechanism, you only have 2100-odd clock cycles to repopulate that RAM in if you want to completely change it up.

* I think once you choose ROM, mapped ROM, or RAM for a particular section of the address space, that decision is baked. No mappers that will let you page your choice of ROM or RAM to a particular address later.

* One of the benefits of RAM tile memory is that you can change it between vblanks. So you can have parallax-like scrolling effects by overwriting a particular tile with other tiles from ROM, animating a map tile by replacing the tile graphic it uses.

* On the NES, tiles are always behind all sprites, and are always 4-colour opaque (one colour of which is always black is shared among the entire tilemap). Sprites are rasterized in order on a given scanline, and IIRC always have colour zero transparent (no 4-colour opaque sprites).

And how many tiles is a 1KB page?

4 values = 2 bits per pixel, 8x8 pixels, 2*8*8 yields 128 bits per tile, 128/8 yields 16 bytes per tile; 1024 bytes allows 64 tiles.

Yes, they were usually written in raw assembly; IIRC, that stayed true well into the PS1/N64 era. Don't try to fit your C# code into a size constraint. If you're not programming in assembly, don't force yourself to meet the ROM size limitations of the day. Even if this (

EDIT: Forgot about the universal background colour, and stripped out those obtrusive video embeds, I only wanted to make links.

On the NES, tiles are always behind all sprites, and are always 4-colour opaque (one colour of which is always black)

Also, I find it hard to believe that one color had to always be black. What I've read is that one color has to be the same on all palettes, (and this color is often black because that is an easy one to work with.) But it really is a "background color," the color that is rendered when there is no color set by anything else.

For example, observe this in Zelda II:

The universal background color here is sky blue. Note the text box; it is particularly key. Its palette is white, red, blue, and the background color, which in this scene is sky-blue. But in this scene below, it is black.


As you play the game, you can bring up the magic list in any given scene and notice that the background color for the menu always changes to the background color of the level you are in. When you cast a spell, the background color flashes to white.