Best programmed NES games/Games that pushed the limits

[mikejmoffitt]

Even "Back to the Future" changes the palette for the status bar, and that is not a good game at all.

Isn't this a very easy operation? Couldn't hypothetically even SMB be modified to have one palette for the status bar, then on sprite 0 hit update the palette in addition to the scrolling?

[tepples]

I'm guessing it's hard to squeeze the palette update into horizontal blanking without causing rainbow artifacts.

[Dwedit]

The rainbow artifacts can be inside the overscan area. Visible on the AVGN's review of Back to the Future.

[psycopathicteen]

Is the vram management in Battletoads similar to the vram management in DKC, where there can be up to 14 objects (excluding bananas), and objects are limited to 32 8x8 blocks (except for bosses).

[Dwedit]

VRAM management in Battletoads is very simple. VRAM is decoded once for all possible sprites at the beginning of the level. Except for the main character's graphics, 32 tiles are reserved for that (16 tiles for each player). And the animated tiles too, they are also changed during run time.

[tepples]

One 4 KiB CHR RAM page is enough for two copies of the tiles for all 64 sprites, even in 8x16 mode. In one NTSC vblank, you can update eight tiles plus one nametable row, nametable column, or whole palette. So if you aren't changing all sprites to new frames of animation at once, you don't even need complicated VRAM management; you can just continuously load in new animation frames.

[psycopathicteen]

Dwedit and tepples are giving me seemingly contradictory information.

[rainwarrior]

Battletoads builds its CHR upload code in RAM so it can upload a little faster (doesn't have to increment a pointer, etc.). They also ran out of vblank time for two levels (the snake level, and the revolution), so they leave rendering off for a bit of the top of the screen (and push down the status bar) to accommodate.

[tepples]

Dwedit and tepples are giving me seemingly contradictory information.

Dwedit explained the design chosen for Battletoads. I explained another design that other games might use, which I gather is similar to what a lot of fourth-gen and GBA games used.

[Drag]

Do you mean something like this?

Maybe (I'm not familiar with the assembler commands in that code). Duff's device is basically a combination of using an unrolled loop and a regular loop, used to copy memory from one location to another. In Startropics II, there's an unrolled loop of 8 LDA/STA's, so the game uploads stuff to the PPU 8 bytes at a time using this unrolled loop (fast). Afterwards, the remainder (for when the string length isn't divisible by 8 ) is uploaded using a regular loop (slower).

Can it do it without visual glitches? That would be really interesting!

It basically uses A, X, and Y to quickly cram bytes into the palette right at hblank, and then it uses a cycle timed loop to get to the next hblank, to do it again. It still has to turn off rendering, but not for long.

[Dwedit]

Or just use an indirect jump into the duff's device loop.

[Drag]

That works too.

[rainwarrior]

Duff's Device is just the trick of how to do it in C in a concise way.

Unrolled loops are just unrolled loops. If you're writing in assembly there's no such thing as Duff's Device.

[tokumaru]

I'm not familiar with the assembler commands in that code

That code is meant to run on Michal Kowalski's 6502 simulator. I always use it to test new ideas.

Duff's device is basically a combination of using an unrolled loop and a regular loop, used to copy memory from one location to another. In Startropics II, there's an unrolled loop of 8 LDA/STA's, so the game uploads stuff to the PPU 8 bytes at a time using this unrolled loop (fast). Afterwards, the remainder (for when the string length isn't divisible by 8 ) is uploaded using a regular loop (slower).

I see... Yeah, not exactly what my code does, which is completely unrolling the copy loop and using a jump table to land on the appropriate part of it to copy the desired amount of bytes.

It basically uses A, X, and Y to quickly cram bytes into the palette right at hblank, and then it uses a cycle timed loop to get to the next hblank, to do it again. It still has to turn off rendering, but not for long.

I guess that the ~28 cycles of HBlank are indeed enough to update all 4 entries of a palette when rendering is disabled, and in the end the VRAM address will point to color 0 of the next palette, so there are no visible glitches (well, except maybe for the overscan area). It would take 8 scanlines to update all the colors though, but I guess that's acceptable in some cases.

[Denine]

That reminded me.
Long time ago I started a MMC5 game project(which will not be finished soon, it progresses slowly) which use IRQ interrupt to change BG color.
I don't know if this "trick" is known(probably is) and if any games use this(again, probably yes). But this enables me to change one color of pallete with no glitches. In MMC5 project, I use it as sort of gradient.

I know, effect is poor, but it's because of NES's color number.

I tested this extensively and works perfectly with any emulator. I have no means to check it with real hardware, though.

Anyway, I think this could be done tih sprite0, but you can have only one hit per frame.

I just thought it might be worth mentioning, as a contrast to turning rendering off.