Use of color + Feasibility of NES Retro City Rampage

Well, "pretty but mostly monochrome" sorta does describe Kirby's Adventure's graphics. It looks good, no question about that, but you can easily see the attribute boundaries.


Not really a surprise, considering it has been prototyped on the NES by someone well aware of all the limitations.


MMC5's extended attribute mode only works for a single name table (which is 256x240 pixels, exactly like the screen), so there's never an off-screen area where tiles can be updated when the screen scrolls, meaning the updates have to happen in plain sight. The good news is that since palettes can be applied to 8x8 pixel areas now, the built-in PPU ability to mask off the leftmost 8 pixels of the screen provides you with an area where horizontal scrolling updates can be hidden, just like in the SEGA Master System. There are also ways to mask off a bit of the top and the bottom of the screen so you can hide vertical scrolling glitches, specially if you have scanline IRQs at your disposal. With a little effort, you can have perfectly clean 8-way scrolling in MMC5's extended attribute mode.

I'm happy to have found someone that shares my sentiments about Kirby's Adventure, I like you.

Aside from his own ROM beta, would it be possible to recreate RCR to some extent on the NES? I know for example you can't have hundreds of objects moving around, as the NES is limited in display, and the NES doesn't do 16:9 video. I also know that some things might be tricky (like that "Toasty" guy that shows up when some mook dies in an explosive car crash or that underwater level with the warping background), and the scanline limit would put a dent in the presentation, or at least in certain situations. It's a shame since I really like the art direction and color use, a shame that very few commercial NES games looked that nice despite the console being well equipped for that.

Oh, if I had the patience and will power.

Don't get me wrong, I still think it's one of the greatest games in the NES library (I'm a sucker for cutesy platformers), but it's not the masterpiece sometimes people make it to be... There are some technical issues (scrolling glitches, slowdowns) that could maybe have been worked around, and the graphics are cute, but not groundbreaking.


Not in a single screen. The biggest bottleneck is CPU time, because each object has its own AI, movements, collisions and graphics (usually sprites, but not always), that need to be processed every frame. The solution is to process only the objects that are on-screen, while completely ignoring (or updating considerably less frequently) the ones that are off-screen.


Sorry, I'm not very familiar with the game so I can't comment on that.


I'll have to disagree with you on that... The graphics are nice, but they aren't exactly groundbreaking either. To me those graphics look pretty straightforward, any moderately experienced artist could pull them off. Nearly everything is drawn with black/dark outlines, which is cheaper to do (cartoon characters are that way because that's easier/faster to draw and animate), palettes are mostly monochrome, depth isn't conveyed particularly well...

BTW, I believe a split is in order!

The two instances I mentioned being "tricky" are early in the game, you can see them within a few minutes of YouTube gameplay. The Toasty looks like a larger sprite that's well above the 8 tile limit, unless you render it using a hybrid between background tiles and sprites for the edges. The underwater level (which appears as a downsized homage to the TMNT water level) has most background objects "warping", which can be done in software (like the "wobbling screen" from Casino Kid), but likely not to the same extent.

As for the graphics, I think it's creative use of the NES' rather poor palette and a good selection of "universal" palettes. Not saying it's the best, but I think it looks good.

Not necessarily. A lot of objects can be made with AI on some frames and dead reckoning on other frames. That's how I sped up Thwaite, by processing some objects at 30/25 fps and others at 10 fps. Mega Man series does much the same thing, I believe. In fact, that's how I plan to speed up my current project, a port of Cookie Clicker to the NES, despite the NES's weakness at adding and multiplying large numbers, by processing some parts at only 1 fps.

Split done. I'll let tokumaru choose the new subject because last time I got it wrong.

I think RCR might be tricky to get accurate even on a per-color level. It seems to use a true yellow, which wasn't possible on the NES, unless my eyes deceive me.

Here is a map made by BriPro himself as part of a contest. I think this map is quite big, possibly even too big to fit on the MMC5 without either compression techniques or a special submapper to allow greater storage. BriPro also mentioned that the joke signs had to be cut out from the NES due to memory retraints. Would it be possible to combine MMC5 with CHR-RAM, so that you can load up the billboards at a given interval and then swap it out as you see fit?

Map: http://www.retrocityrampage.com/map/city.png

Contest (and other miscellaneous rooms): http://www.retrocityrampage.com/worldmap.php

The MMC5 was the biggest, most complex mapper ever released for the NES. It supported up to 1MB of each of PRG or CHR.

Anyway, we don't really need to speculate; BriPro posted a "making of" video.

He mentions the following reasons for having to cut things down:
* Even though the MMC5 supports 1MB of CHR, the 8x8 attribute mode supports it as four pages of 16384 tiles at a time. RCR needed closer to "30000 tiles", but he shaved it down to 8000. (I'm not certain why 8000; he should have been able to target 512KiB of CHR, with half for backgrounds and half for sprites)
* Sprite library size (banked in four groups of 64, so no arbitrary mixing-and-matching), both for cars and people
* Simultaneous sprite limitations (only 8 on a scanline)

I wonder what changes he made to the NES color palette. Is yellow the only extra color, or is the whole palette different?

The mod files come with a palette reference, and a few colors look different from the normal NES palette:

I might have read it wrong, but doesn't MMC5 allow you to double the sprite CHR if you're using 8*16 sprite mode? That way you have twice the sprites, and you separate those sprites into special groups. From what I read, the smallest number of sprites you can bankswitch would be 32 tiles, this is with MMC3. So that means you have 8 64 tile groups, so maybe relegate 6 of them for vehicles, one for pedestrians, and one for other effects. Again, that is assuming my understanding is right. If we could split up those groups further, into single 16 tile rows for different pedestrians, for example, that would be ideal. Hell, the game that influenced this game, GTA3, suffers intensely from RAM issues, which explains why every car on the road is like the one you're currently driving.



It might be how he structured the demo ROM, but flicker is already somewhat rare on the game. Combine that with the 64 sprite limit, and chances are the action will have to be cut down just enough so that flicker won't occur under normal circumstances.

It's true that you can use this mode of the MMC5 to get eight 64-tile banks of 8x16 sprites, but then you're more likely to exceed the 8 sprites on a scanline limit.
1024 bytes in a bank is 64x16, and there are 16 bytes per tile. No mappers (that we know of) have banks smaller than 1KiB... Since an 8x16 sprite is two tiles, maybe that's where 32 came from?

There are things you can do to make it less visible, or perhaps substantially less visible, so long as no more than 12 sprites are in the same row. But since the cars are often 3 sprites wide...
ISTR the video mentioned he removed all the background animations, though.

I meant to say 64 tiles, not 32. For some reason I suspected that the CHR banks held 128 tiles as opposed to 256. And I heard that MMC3 can switch out, at the very least, one quarter of the CHR. The MMC1 had to switch out entire pages, which didn't seem very efficient at all. Keep in mind that this is what I -think- I interpreted, so I'm very likely wrong.

Flicker seems like it would be the biggest issue yet, though NES games are often noted for being very flicker heavy, with very few games avoiding flicker entirely.

Yeah, two 2 KB slices and four 1 KB slices. I don't know whether games more often used the two banks of 128 tiles at a time for background and the four banks of 64 tiles for sprites, or vice versa...
Well, it really depends on how you're structuring things. It'll often end up more modal: "This bank is the one we use when we're on the map; this one's for combat; this one's for the menu"
The limitation of 64 maximum pixels of sprite (out of 256) on any given scanline is fairly crippling. Very few games had actors that were narrow enough to just be a single sprite (other than sparks, stars, and projectiles), so you're basically limited to four two-sprite-wide actors in any given section of the screen, if you're going to entirely avoid flickering.

You're right, many NES games had to be very carefully designed so that they looked good and avoided flicker as much as possible. Ninja Gaiden uses reasonably sized sprites, but flicker isn't all to common. This works due to clever game design. On a similar note, while hated by many, Ninja Gaiden 3 can push an obscene number of objects onscreen (like that one stage when you're trying to go inside a plane, I think stage 5-1), AND has a pretty effective flickering algorithm. Doesn't mean the scanline limit is ignored, but it can be prevented it seems.

Thankfully RCR already has small graphics, and the cars aren't too bad. I don't think there will ever be an instance where there will be more than three cars lined up horizontally, though the pedestrians and random objects (such as the parking meters, which appear to be sprites) might be a bigger issue. And ideally, you might want to set drawing limits (Gradius does this to some extent) to further combat flicker. For example, I think the largest vehicle in the game would be the Tank, so you could set a limit to show a maximum of two tanks as well as three police cars. I'm certain you could outrun the Tanks (and by extension force them off-screen), but the cop cars will still be able to catch up to you.