would screen splitting give extra 13 colours for tiles?

Hi, I'm new here, so apologies if my questions at times seem basic.

I'm working on a platformer and would like to emulate the NES' graphical capabilities within the abilities of the MMC5 chip. The actual game is programmed in a modern engine, but using tiles and so on.

I was wondering that if you split the screen, or use some other technique like raster split, you would gain another set of colours for those tiles?

Something like below, where the screen is somehow split at the water line and uses the second palette there.

This is really lazy of me, but the topic "Questions about NES Graphics Limitations" has some information regarding it on page 2.

You can't "gain a new palette", but you can use split-screen to change the palette in $3Fxx to new values "mid-screen" so that you have more actual colour choices to work with from that scanline onward. However, be aware: doing this on a NES tends to be somewhat tricky/temperamental, as it's very timing-sensitive and depending on what mapper you use may cause things like a scanline of corruption and/or flicker (really depends on timing). There are commercial games which do this (I think Wizards & Warriors is one of them^[1]).

I often tell people developing games on non-NES consoles this: if you want to make a game that's "like" the NES in graphical style, go right ahead. But unless you absolutely no-questions-asked plan on making the game for the actual NES itself, there's really no reason to limit yourself to how the system behaves or how some of the mappers are implemented (ex. MMC5's graphical extensions, scanline/IRQ counter, etc.); just make the game you want and make it look like whatever style you want.

A great present-day example of this is Shovel Knight, where the graphics are "NES-like" but wouldn't work flawlessly if the game were actually designed on the NES (it would work fine on the SNES). On the other hand, the music done by Jake Kaufman/Virt and Manami MATSUME was actually composed in FamiTracker (I believe) and thus is 100% natively available on a NES (more specifically: on an actual Famicom -- the music uses Konami's VRC6 mapper, whose audio capabilities would not work on a non-modded NES). The MP3/in-game versions sound more "full" or "fat" because of post-mixing (ask Jake, he can tell you :-) ). NSF is available here (read text): http://virt.bandcamp.com/album/shovel-k ... soundtrack

^[1]: If we (the royal "we") don't already have a section on the nesdev Wiki listing off games which do this, we should make one. Having a list, similar in concept to our sprite overflow page, would be beneficial.

The NES isn't very friendly with mid-screen palette changes. Fact is you can turn rendering off mid-screen, upload a new set of palettes, reset the scroll to the proper location, and enable rendering back on (rendering would have to be disabled for more than 1 scanline depending on how many colors you need to change). There are a few problems with this approach though:

Both the background and the sprites have to be disabled so you can write to the palette, otherwise the PPU isn't actually resting and your VRAM accesses will clash with the PPU's and you'll get all sorts of corrupted graphics. The second issue is that while rendering is off and the PPU address is pointing to the palette area, the color being pointed gets rendered, which means that you'll get a rainbow-like effect in the scanlines where the updates are taking place. This effect can be made less noticeable by turning grayscale mode on, so you'll see a few grays instead of rainbows, but it's still weird. The final issue I can think of, is that disabling sprites mid-frame is a risky task. If it's not done at a precise time or when the sprites are arranged in a certain way, you might get corrupted sprites the next frame or when they are re-enabled.

In conclusion, the short answer is no, you can't get a clean split like in your mock-ups.

If the water is not moving up and down, the safest thing to do is to simply sacrifice 1 of the palettes for all the underwater stuff. If the water does move up and down, one thing to consider are the color emphasis bits: the PPU has 3 bits you can change at any time that will emphasize the red, green or blue (or combinations of those colors) in the entire palette. You could emphasize the blue for the underwater sections, but the effect is much more subtle than in your mock-ups. To make this effect more harsh, you can simultaneously turn on the grayscale mode and the blue emphasis, which is what the game Noah's Ark does. The good think about these settings is that they can be changed freely at any time without messing the the rendering process. Keep in mind that they affect all colors, even sprites.

[quote=

Thanks so much for clarifying this. So basically I can change the shared colour only? (so from sky blue to white, but the other colours need to remain the same.) In theory this works and thats good enough for me.



While I agree with you, on a personal note; I've been hammering away on pixel art on and off for most of my life. I have a relatively busy schedule these days so really I have just enough time to geek out on this one. I'd like to set myself a challenge, and learn more about the NES... then I'll probably break all the rules later



That game was awesome. Also an awesomely liberal use of the word 8-bit.



This for me seemed a little strange. They started out with strict NES graphics, then changed to loosely authentic graphics, but the music stayed authentic when it could have done with the same liberties IMHO.

Thanks for the insight here. I won't be emulating on real hardware, but if this was a real graphical technique that was tried back in the day I can roll with it.



Originally I had just 13 colours with the blue (which included a white for the waves) and then on tiles that had no white (this posts) I was thinking to use a white sprite. Thanks so much for the video link, that is food for thought!

You can change all the colors, but it will take some amount of vertical distance. You might want to read through Okk's thread.

For example, if you have the right edge of the scanline empty, you could probably update a single color for the next scanline. The title screen of Taito's Indiana Jones and the Last Crusade does this.
If you disable more time (for example, one entire blank line), you can update up to 16 colors.

No, that's not what he said. Note the "$3Fxx" in his post: the "xx" can be any address, meaning any color. Like I said in my post, you can change any of the colors, but several restrictions apply, and it's not possible to get a clean split. You can't have scanline 120 use a set of colors and scanline 121 use the same set but with 3 different colors. There has to be a "break" (no background or sprites at all) of 1 or more scanlines, because changing colors takes time, even if it's just 1 color. Plus the other few other "gotchas" that I mentioned in my post (colors get rendered as they are updated, disabling sprites can glitch them later).

All instances of mid-screen palette changes in commercial games I'm aware of take place between the gameplay window and the status bar, or other similar transitions, where there's a clear break between the areas using different palettes.

Ah I see what you mean, so basically it can be done but you lose one row of tiles? That would be bad news for the graphics above. Maybe I should look at not splitting the screen.

Thanks for these links. Is this a Y or N?

I'll certainly give them a good read to see if any apply to my case.

To be fair, 2 of the palettes for the bottom of the screen are exactly the same as the ones on the top, minus color 0. I wonder if it would be possible to at least just change color 0, or if you'd get the rainbow effect from switching from blue to white? By the looks of you're picture though, it appears that the BG color is being obscured by a darker blue for a gradient color, but I still don't know if you'd be able to update in time. You could always make the darker blue gradient start higher up.

Sounds interesting! I can make this blue go up, any guesses on how many vertical tile rows up from the change would I need to change colour 0 in theory? (if the tile rows didn't use colour 0) This can be theory only, as this won't run on an actual NES or emulator.

There are all sorts of permutations of weird technical possibilities that you could pull off on the NES, but a lot of them really aren't typical. Like, if you're trying to faithfully "fake" the look of an NES game, you probably don't want to be trying special tricks that aren't really part of the NES experience.

For instance, MMC5 8x8 pixel attributes were only used in 1 game, to my knowledge (Just Breed), and it was a Japan-only RPG. It's a thing you could technically pull off on an NES, but it's not characteristic of NES games at all. Part of the reason it wasn't used is that having 8x8 pixel granularity in the world can quadruple the complexity of your map (ROM size constraints, RAM constraints, extra collision tests required, etc.) so even if you had the special MMC5 hardware for 8x8 attributes, it's a significant burden on the NES to make a world that puts it to use!

A palette change for a status bar is an advanced and atypical technique. A clean palette change during normal background rendering is elite tier. Something like this usually comes with weird design constraints, and these are things you don't really consider when you're just looking at one technical issue; you only find them when you try to build a whole game. Suddenly you find this one technical feature you implemented is dictating how you have to design your maps, etc. A lot of these techniques aren't seen much for good reason (though sometimes it's just that we have better knowledge and tools now than back then).

An emphasis change like Noah's ark is fairly easy to implement. It's not typical, but it's very doable. Your water line has to be straight, this way, though.

Anyhow, I don't really understand the point of trying to push the NES graphical capabilites to the limit without actually using an NES. It doesn't matter what was technically possible or not. Just make a nice game, and if you like the NES look, imitate the parts of it that feel good to you, and ignore the rest. If it's important to you that it be NES-faithful, for some reason, you should probably stick to normal techniques that look and feel like real NES games, not technical obscurities... but... never mind my opinion. I don't know what motivates you. If you can make a good game out of it, do whatever suits you.

Looking at the size of that map, it'd be probably better to just change the palettes as the camera moves around. It doesn't look like all palettes would be shown at once in the first place.


Wait, how do the emphasis bits work? Because that looks a tad more washed out than I expected.

Since I already went to the effort of marking it up, I'm providing an annotated version of the Indiana Jones title screen here (made because I feel like it got glossed over earlier)
As stated, advanced technique. Very difficult to use with anything going on at the same time. (The entire top two-thirds of the screen is carefully timed loops for almost-pixel-exact writes to the PPU).

What's interesting, and a tangent, is that it hadn't occured to me that we could write the first half to $2006 before we disable video.

It looks washed out because the greyscale bit is set at the same time, which turns all colors $XY (for 0≤Y≤$D) into $X0.Colors $xE and $xF are preserved so that black can stay black, even when the greyscale bit is set.

Thanks for the honest feedback. Sounds like you have had to go through this on a programming level and why one might avoid it.

The motivation for myself as designer is to get a feel for the limits (believe it or not having limits makes pixel art easier) so I can make a base. I'm quite interested in how far the NES was pushed in it's sunset years, and what the true limits are. Hopefully this will then be a defining factor in the look of the game.

Is this true? If so, the wiki is wrong:



I've always thought black turns into $00 (gray) as well when gr[a|e]yscale mode is turned on.

No, the wiki is right and lidnariq is wrong.

Yeah, that's because in grayscale mode all colors get to look like the grays in the first column of the palette, which actually has 2 whites and 2 grays. Not the best selection to represent a grayscale image (only 3 colors: white, gray, darker gray).


Never heard of this. Did you test this behavior anywhere?

I understand some people's concerns, namely Rainwarrior's where he says that emulating obscure NES tricks would be pointless if this were not to be made on the NES. Moreso since these tricks often impact game design in some cases. Though what if someone (or a team) wanted to make a prototype for an NES game using any possible technique to greatly enhance the experience in a higher, quicker to develop language? Of course, you can accomplish certain things much easier with the modern engine, without even using NES tricks.

And as for the MMC5 single tile attribute, one other game uses this also, though I'm not sure if you should really count it since it was not a proper commercial release. ROM City Rampage.

The Game Boy Color, on the other hand, allowed you to rewrite the palette whenever you wanted without needing to disable rendering or anything like that. They used it for static screens like title screens, or other games like Wacky Races pushed it to the limit for use during gameplay.

Not really important to the conversation, but can the Game Boy color have a different palette every 8x8 block, or every 16x16 like the NES? also, how many palettes does it have?

Game Boy Color has 8x8 pixel (per-tile) palette selection, like the MMC5, Super NES, or GBA. It has eight 4-color background palettes (with distinct color 0 in each) and eight 3-color sprite palettes. The palettes are RGB with 32 levels per channel, but the gamma is kind of screwy.

The Game Boy Color uses 15bit RGB (same as SNES, GBA, and might as well include Neo Geo, even if it did have a seemingly unused 16th bit) but has all tiles being 2bpp and 49 colors on screen without changing palettes mid scan line? (Talk about mixed priorities. )

Probably on the screen type, really. The Game Gear has 4 bits per component for instance (despite still only showing 31 colors), when the Mega Drive, an otherwise superior system, only had 3. Make what you want out of that. And yeah, the gamma in the GBC screen is crap, to the point that the suggestion is to ditch away half of the entire range (effectively making it 4 bits per component in practice).

Also pretty sure the Neo Geo used the 16th bit for something, although whether it was useful or not is a different issue.

The Neo Geo had the 16th bit decreased the color by a "half bit", meaning that you can have a color like R:12 G:20 B:4, (24bit color) but not something like R:12 G:24 B:4, if that makes sense. I've just looked at a bunch of colors from the graphics from Metal Slug, and none that I've noticed are not perfectly divisible by 8. The half brightness bit could be really useful for a black and white screen, but with having 4bpp 16x16 tiles, you cant really use all the colors that easily, unless you have something like a gradient going down the length of the screen. 8bpp graphics is one reason I think that the SNES can look about as good as the Neo Geo, but it leaves quite a dent in vram... (Which, obviously, isn't a problem on the Neo Geo.)

The 16th bit decreases the output to around half of all the color channels, and it is done in analog domain. I don't remember the exact circuit though, there's probably some non-linearity involved...

So I was right.


Meaning that the 16th bit is calculated after all the other bits in a different process? I guess that is why the SNES, GBC, and GBA don't have a sixteenth color bit, despite having the space to do so. Seems like quite a bit (no pun intended ) of work for one measly bit...

No, it's a quite simple circuit in analog ... Assuming the attenuation is linear, it's not even particularly redundant: of the 33k new colors, only 1/8 of them are redundant with the original 33k. I'm just not certain whether it's particularly useful.

Yeah, pretty sure that it's simpler than the DACs from the components themselves, it's just that, huh, it isn't that useful as I said. Another system that used the 16th bit was the 32X, which acted as a priority bit (it flipped the priorities of the 32X and Mega Drive layers), which was definitely a lot more useful. In the same vein, quite a bunch of image formats take the 16th bit as an 1-bit alpha mask.

Could someone point me to the specifics of this, maybe it's on the wiki? I have in mind a split with 8 sprites on a line.

It all started with this. It's a long thread, but I think there's a conclusion concerning how to avoid the glitch near the end of it.

Note that this is only when both sprites and background are disabled, which in when the PPU truly stops rendering graphics (and you can use $2006/$2007). If only one of the layers is disabled, the PPU only "masks" that layer off by not displaying its pixels, but still processes it internally.

The sprite memory is dynamic ram that needs to be refreshed frequently (by being read or written to). Basically, it's only good enough to hold its data for the length of a vblank interval (~20 scanlines). Anything more than that and the data will start to decay (random bits will change over time).

I don't know if there are other issues than that with turning sprites on mid-frame, but it's perfectly fine to turn sprites off mid-frame and leave them off for the rest of the frame as long as you restore them with an OAM DMA on the next vblank. Edit: Apparently not? I've never encountered this problem, but read what Tokumaru has to say about it.

There are. Read that thread and you'll understand.


No no, there's a glitch that happens when you interrupt the refreshing process that happens during rendering. IIRC, when rendering is turned back on, the refreshing process will resume in a bad state and overwrite some of the OAM values, after you have updated them with the DMA, effectively corrupting sprites. To avoid this, you have to turn rendering off at a specific time in the scanline (near the end of it I think), and I believe that the sprites that are in range at the time play a part on it too, but I never understood the details of this glitch.

EDIT: Here's what tepples did to avoid the sprite corruption: viewtopic.php?p=76125#p76125

Now that the PPU's actual sprite processing behavior is better understood, here's the revised advice: You have to turn off rendering between x=128 + 6 * (number of sprites in range) and x=256. Get it as close as you can to the right side [TPIR]without going over[/TPIR] and you should be fine.

Didn't we have this information already when you first noticed the glitch? Also, I don't see anything in that wiki page that suggests how to deal with this problem.


So, in addition to aiming for the end of the scanline, the less sprites in range you have the safer you are? Sounds reasonable.

Reply hazy, as I noticed the glitch in December 2008, and the page's revision history prior to 11 June 2009‎ was not saved.


I was giving the time to guarantee "n has overflowed back to zero (all 64 sprites evaluated)": 64 to clear secondary OAM, 64 to check all Y coordinates, and 6 more for each in-range sprite to copy tile number, attributes and X coordinate. This finishes by 176 when the maximum eight sprites are in range.


Correction: It's actually 128 to check all 64 sprites' Y coordinates because of the alternating reads and writes. This means it finishes by 64 + 2 * 64 + 48 = 240.

Interesting... So anything between 176 and 256 should work? That's a pretty decently sized window of time (about 26 CPU cycles). Good to know!

This information really should go somewhere in the wiki, written in a way that's clear to programmers even if they don't understand every tiny detail of the PPU's internals. Something along the lines of "if you need to disable rendering early, do it between pixels 176 and 256, otherwise you'll interfere with how sprites are evaluated and will possibly get corrupt sprites on the next frame, even if you do a sprite DMA".

Now that I think of it, the NES has a number of "gotchas" that people sometimes forget about. Things like this sprite glitch, the colors pointed by the VRAM address register being drawn when rendering is disabled, the alternate dot crawl pattern, the color that's blacker than black, the DPCM controller glitch, the audio channels clicking... Maybe we could make a page listing all of these gotchas, so that people can quickly validate their programs against it.

If you have anything to add to Errata, go ahead.

Nice! I don't even know if I ever saw this page before, but if I did, I completely forgot about it.

Some items could be worded better, and others explained a little bit further (missing suggested workarounds?), but this is pretty much what I had in mind, and it will do the job just fine.

Personally, I find the name "errata" a little misleading, because the people who publish them are usually the same people who made the mistakes in the first place, and we're obviously not Nintendo.

Thanks, tokumaru, that's the thread I was recalling. I just didn't bother using the search feature because my last search for "hblank palette update" returned nothing, but DuckDuckGo had it on the first result. Maybe I should have put "+" in front of each part. But I'm very appreciative of what we have.
I've been feeling guilty the last few days when I use an Internet search like Google: I saw on TV that just two Google searches uses enough power to boil a cup of tea.

That thread, I'm reareading it now. Two other things about it: 1) it reminded me that I can use any tile number for sprite zero, not just tile 0. 2) Is there any clarification about sprite0's solid pixel length: should it be 8px wide (mines 6) in order to be sure the hit will land. It doesn't seem logical that way. But it was asked in that thread. I shall finish reading.

I'm pretty sure sprite 0 hit will work even with only one opaque sprite pixel that overlaps one opaque background pixel, so long as it isn't at x=255, and it isn't at x=0 to 7 while the background or sprite layer is windowed off in $2001.

This thread got a bit too technical for me so I kinda backed away (sorry about that) Thanks for all the input. I've decided to stick to 13 colours for the entire tilemap, and just do one split for the HUD.



Just a thought on this but the majority of Famitracker NES tunes use the VRC6 chip and that was used in 3 games? So based on that I think it's an artists job to get the most out of what the NES could do, not what the NES is characteristic of (like with chip tunes).

You know, (I'm not really going to help with the topic, but) have you ever actually thought about making your game on the NES? (You probably already said so, but I'm just too lazy to look.) I just fail to see the point of going to the extreme that you are to try and replicate the original hardware when, obviously, you can just use the original hardware.

Well, there's what you would do with a VRC6, what you would do with unrestrained use of an NES, and what you would do in the context of an actual NES game. I've made music in all of these situations, and for me it's a very different approach on each of these.

1. The first approach is just trying to make some good music, inspired by the NES sound and somewhat related to it, but this really isn't about proving what the hardware can do. Does anyone really care what the limitations of VRC6 are? It's awfully powerful, not much of a constrained music platform, just a fun set of sounds to work with.

2. The second approach involves proving it could actually be done on the NES, but at the same time you're allowed to sacrifice all other considerations for just the music. This stuff doesn't sound like NES game music, for very good reason, but at least the constraints here are severe enough that it's a lot of fun to try and see what you can do within them. Doing this well really involves getting to know the hardware very well.

3. The third results in something that sounds authentic, and is authentic. It's running on an NES, in a game, and meeting all the other constraints that entails. Every piece of a game is sharing the resource budget of the whole, and you can't really get a feel for this without working within a complete project.


So... I mean, I am interested in all 3 of these things, but there is different motivation for each type of thing.

1 is something like Shovel Knight or Volgarr. Maybe you like 3-colour sprite palettes, and square waves, and other artifacts of the NES limitations, but you just use them as stylistic elements and make something fun using those.

2 is Demoscene, Famicompo, tech demos, etc. People who really care about what the hardware could do, and usually want to make the most out of a relatively focused scope.

3 is retro game development. You care very much that it works and fits on the console. The scope is usually too large to apply a Demoscene level of technique to every element; you have a lot of content to make for a user experience of many hours. It's a different kind of art entirely from number 2, though it shares the need to know the hardware and prove it works.


So, like... some of the answers you've got in this thread fall into the mode 2 category, as I see it. Things that are technically possible, but very advanced and not actually seen in games. If I wasn't going to build the demo, though, I'm automatically in category 1, and in category 1 it doesn't really matter if something was marginally possible on the NES or not-- I would just do it if it looked/felt good. If I was in category 3, I would have to make a serious decision about whether the technical effect was worth implementing, whether it would be better to spend your limited development time or ROM budget or other resource on something else. It's a very different mindset.

I don't know what you're looking to do, or how you'd categorize these acts, but that's how it's organized in my own headspace, and why I'm interested in each of them differently.

Thats a very astute observation, a could almost serve as an official guide.

I guess my project falls in-between 1 & 2.

I've been updating a thread for it on pixelation but here's the current state:





https://www.youtube.com/watch?v=W81cXeh_WGM

Very nice, particularly the use of color to show whether the foot or peg is in front. (I don't think I've seen a nine-frame walk-cycle before, either.) The (5) colors are a bit less NES-simple...not that you can't do it with overlapping sprites. Easily doable with 4 sprites per line, and often with 3- though some of the 4s are only "by-one-pixel" affairs. (The eye/lapel pixels are obvious ones, and similarly obviously change the image significantly in their absence, so shouldn't be "optimized" out).

The hat is so neatly self-contained (without seeming it, thanks to the bounce) I almost expect it to be removable.

Thanks for the feedback, really appreciated.

The cycle is a standard 8 frame loop. I use a tool called Pixen for animation, its a bit scrappy and crashes like crazy but I've not found a tool that can replace it in terms of workflow. Definitely a bit more relaxed when it comes to sprites per line, I like the NES look of games that use limited palettes on their sprites so will try to keep the colours low.

Hat wasn't originally removable but now I'll have to make it so! Was thinking the hat and beard are his health.

Oops. 0-based thinking strikes again. My mistake.
If he gets too un-bearded whatever he's got under the coat will become visible, though. I have no idea what manner of shirt he is wearing, if any.
(Wario Land did have a losable hat, after all.)

*cough*

This looks really good! I have to say this though: you seemed so concerned about the colors an NES would accurately be able to generate but used a resolution twice as wide as the 256 pixels of the NES? This alone already makes the game more like Shovel Knight than an actual NES title, so you probably shouldn't worry about these hardware limitations.

Eh. I'm probably going to do the same (or use 427x240) if my actual NES game ever makes it to other platforms. 256x240 is not a great resolution to scale to HD (1920x1080). Would need a border, or very horizontally scaled pixels.

If the levels are actually larger than 256x240, there's not much reason not to. Wouldn't work for a game like Battle Kid, though.

Edit: Though scaling could affect how enemies spawn across the two versions, which is something I struggle with. Get used to speed running one, enemies aren't where you expect in the other.

The picture generated by the NES (which fills the 4:3 screen) is 280x240, with 24 pixels at the side of each scanline in a border that's normally hidden in overscan. Thus the pixel aspect ratio (the width of each pixel divided by its height) is 8:7. If you want to extend this to HDTV wihle keeping the same pixel aspect ratio, you end up with about 373x240, with 352x240 of actual picture inside the border, or 44x30 tiles. If I remember correctly, this is about the same res you'd get out of a TurboGrafx-16 in "medium resolution".

The other option is to make your game for 256x160, letterboxed, and then expand a 280x180-pixel window of this to the 720p or 1080p frame. You could have it draw the status bar over the playfield on 16:9 HDTVs and out of the letterbox frame on 4:3 SDTVs.

yep the game is 427x240

according to rainwarrior's quite succulent 1 2 3 strictness chart, my game falls somewhere between 1 & 2.

I would love to add artefacts like tile palette errors when scrolling left and right but it's too taxing to reverse engineer NES shortcomings in modern game engines.

Besides the enemy spawning that you mentioned, there are also bosses and other scenes that take place in a single screen. If the resolution is bigger, you'll either have to give characters more freedom (which could completely change the dynamic of a boss fight) or invent some sort of visible barrier to keep everything locked in.