Best programmed NES games/Games that pushed the limits

Shiru · Post by **Shiru** » Fri Jun 29, 2012 2:56 am

Such gradients with just a few color steps could work much better with dithering, it is seen in many NES games (horizontal color lines of varying height).

Bananmos · Post by **Bananmos** » Fri Jun 29, 2012 2:17 pm

That palette trick might work fine in most emulators, but will glitch horribly on real hardware if you use any sprites at all.

The sprite CHR patterns to be displayed on the next scanline get fetched during the first half of the hblank period, and there's just not enough cycles in the second half to turn rendering off, write $2006, write $2007, then restore scrolling with $2006 and possible $2005 and finally turn rendering back on again. So you'll end up with corrupted CHR graphics for your sprites...

Denine · Post by **Denine** » Sun Jul 01, 2012 9:27 am

Shiru wrote:Such gradients with just a few color steps could work much better with dithering, it is seen in many NES games (horizontal color lines of varying height).

Can you give some titles? My code isn't prefect-I can change 1 color every 8 vertical pixels(need to restore scrolling with $2006).Maybe I can learn something from these games.

@Bananmos
If I'm not mistaken, Shiru just said that this effect is seen in many NES games, so i think it is possible even on real hardware(provided that all this games use it for another things than cutscenes with no sprites).
Also, I can remember bug with corrupted sprited, on emulator. I got around it somehow.

The sprite CHR patterns to be displayed on the next scanline get fetched during the first half of the hblank period, and there's just not enough cycles in the second half to turn rendering off, write $2006, write $2007, then restore scrolling with $2006 and possible $2005 and finally turn rendering back on again. So you'll end up with corrupted CHR graphics for your sprites...

Is there really no way around this?

Shiru · Post by **Shiru** » Sun Jul 01, 2012 9:33 am

I didn't mean that the palette update used in games, I mean that the 'dithering' used to make better gradient using just a few colors in many NES games. Something like this.

Drag · Post by **Drag** » Sun Jul 01, 2012 10:27 am

Shiru wrote:I didn't mean that the palette update used in games, I mean that the 'dithering' used to make better gradient using just a few colors in many NES games. Something like this.

If you want one that looks even crazier, try the ending from Goonies 1. (Which looks really nice on a real NES, by the way

)

Denine · Post by **Denine** » Sun Jul 01, 2012 11:21 am

I'm sorry, I didn't understand, Shiru.
Anyway, Dithering can't be used for background color, color0(the"invisible" color, at $3F00), can it?
@Drag
That looks really good!

Dwedit · Post by **Dwedit** » Sun Jul 01, 2012 11:34 am

I guess if you need a wide variety of background colors, try doing it without using color #0, but Attribute Clash would be a problem.
So backgrounds near the bottom use one set of palettes, and the sky color shares colors with that, then backgrounds near the middle of the screen use another set of colors, and the sky colors are shared with that, then different colors at the top of the screen.

Denine · Post by **Denine** » Sun Jul 01, 2012 1:15 pm

I guess so. But this would require different level designs.

And sorry about that off top. Back to games that push limits.
I actually played BattleToads(never bothered to do so before) and I'm amazed by the level where you fly on plane(Level7).
The mapper is AOROM.It has no IRQ. So how did they make this effect?
I mean those violet flames at the top of the screen.
The only way that comes to my mind is to wait for the end of status bar code, then time the code carefully so it'll wait for Hblank, change Horizontal scrolling on every scanline. But that's....insanely hard to do. For me, at least.

Shiru · Post by **Shiru** » Sun Jul 01, 2012 1:20 pm

I'm sure it is done with timed code. Since you only would need to put precalculated offsets, and you have most of frame time (at bottom part of the screen) to calculate them for the next frame, it shouldn't be too difficult.

Dwedit · Post by **Dwedit** » Sun Jul 01, 2012 1:24 pm

I think that screen just times all code from NMI. Notice how after the purple stuff is scrolled line-by-line, the rest of the screen scrolls very simply.

In the Turbo Tunnel, they use a sprite 0 hit that happens after the top part is done scrolling. Then they use a simplified screen renderer if it's playing PCM samples (game paused, etc.)

Bregalad · Post by **Bregalad** » Sun Jul 01, 2012 1:33 pm

In the Turbo Tunnel, they use a sprite 0 hit that happens after the top part is done scrolling.

I doubt it. Battletoads uses the sprite zero hit in the status bar, for the separation between the status bar and the playfield. The sound driver is called after the VBlank (which is constant timed) ends and the screen is enabled (late, after the extended VBlank). The sound driver is variable-timed, so they need the sprite zero hit in the status bar to split to the playfield accuracely.

I guess all other effects mentioned is simply timed code after this split. This reduces CPU usage for the game, of course. Apparently they managed it to be fast enough, even when most of the screen is taken by raster effects, which means the game engine is very fast and efficient. When playing a sound effect via $4011, they ignore this part apparently, which causes weird scrolling glitches when you punch enemies.

In Battletoads & DoubleDragon, they did it the other way around, the timed code continues to run, but the PCM sound effects are distorted when there is a raster effect on the screen.

Dwedit · Post by **Dwedit** » Sun Jul 01, 2012 1:40 pm

Sprite 0 in the Turbo Tunnel is at scanline 141. It's a black 1-pixel high horizontal line placed at X position 6. You can visibly see it if you look carefully at how the background disappears at that point.

In other levels, sprite 0 is indeed inside the status bar. But not the Turbo Tunnel.

Bregalad · Post by **Bregalad** » Sun Jul 01, 2012 1:58 pm

Wow, so they programmed something different for different levels !!
I must admit that's a little crazy, but after all why not ?

Also the status bar is lower (and the extended VBlank bigger) for the Snake Pit and the Cylindrical Level in the NTSC version. There is still no extended VBlank in the PAL version though.