Cowboy Bebop FMV

While working on my contest entry I though it would be neat to do nametable animation using CHR RAM. Because I was very limited on BSS space and VBLANK time, the technique I'm using involves converting the pattern tables updates directly to assembly code and jumping there to update the pattern tables.

This obviously compresses really poorly, but it's plenty fast and better than using uncompressed data in my case.

Anyway...

Since I had that animation-to-assembly conversion program lying around, I thought it would be neat to make a full-motion video ROM with it. So after hacking away at it for awhile and writing code as shoddily as possible, I present to you the Cowboy Bebop intro in 8 MB of BNROM.

Here's a video of the video: https://www.youtube.com/watch?v=BxuMqho7wKY



I was going to add music to the ROM, but I'm not musically talented and I don't know how to convert the theme to something the NES can play. So it is silent... for now.

The only emulator I've found that can run the ROM is Nintendulator. FCEUX and Nestopia work for 1/2 of the video, but they crash after that because they can't handle BNROMS larger than 4MB. Use Nintendulator.

Legendary!

Cool.

Thanks.

Maybe one day I'll get around to compressing the video even further. Lots of optimizations could be made using split-screen scrolling, sprites, nametable updates, and taking advantage of when the video cuts to black to do more expensive updates. It wouldn't surprise me if the theoretically optimal size at the same quality was under 1MB.

I guess if you just had RAM full of LDA immediate / STA $2007 instructions and you just unpacked the immediate values into that you'd run out of RAM before you ran out of vblank, unless you had WRAM, eh?

In a real NES PAL does not work.

The screen goes gray.

How are you testing an 8MB ROM? The 2 most popular NES Flash carts only support 512KB of PRG-ROM.

Hmm. I guess that's a faster way of buffering data out of vblank, but it wouldn't help much for FMVs since there just isn't time to buffer things. All the data in the bebop rom gets written directly to PPUDATA without any extra buffers whatsoever.

I think using RAM for storing shared subroutines would be a good alternative to duplicating them across every bank though.


I only tested it on NTSC emulators. I suspect the timing would be off on PAL and screw up everything.

I'm not sure if the beginning of the video should still play, though...

Depends on which bank the reset code is in, and how the flash cart's ROM loaders happen to handle oversized ROMs.

EDIT: I mean, the reset code could be saying "bank in the last bank, execute code from there", in which case it would crash right away (unless the ROM loader happened to load the later banks over the earlier ones because of overflows, or something like that).

The OP mentioned the demo worked halfway through in emulators that only support 4MB ROM, so it's possible that Flash carts will play 1/16 of the video, but I don't know if there are other factors to consider.

Ah, I missed that part.