Bad Apple demo for SNES

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
tokumaru
Posts: 11469
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Bad Apple demo for SNES

Post by tokumaru » Tue Sep 29, 2015 7:44 am

The problem with 128x120-pixel video on the NES is that each 8x8 area (a tile) contains 16 pixels, so the possible pattern combinations are far too many (65536) to be available at all times (even with the MMC5, that can address 16384 tiles at a time). This means you either need to update CHR-RAM on the fly (which is slow as hell, so you can kiss those 30fps bye bye) or use tall pixels (8 per tile) and squeeze a 256x480-pixel area into 256x240 pixels.

Either way, another problem to solve is the lack of a back buffer. If updating patterns on the fly, a back buffer could be possible with an extra 8KB of CHR-RAM. If using the squeeze approach, 4 screen mirroring would solve the problem.

Updating patterns is more straightforward, but uploading 8KB worth of patterns takes 28 frames if you only use the regular vblank time. The other approach needs only 1920 bytes to be updated, but that would still take too long (about 7 frames, under normal circumstances).

To reach the desired 30fps, forced blanking will be necessary, cutting some of the picture at the top and bottom. In order to be able to change the picture every other frame, the resolution has to be reduced to 128x100, so the number of bytes to update becomes 1600, which can be copied in 2 extended vblanks.

Another issue is that squeezing the picture requires CPU intervention, so every 4 scanlines the CPU has to step in and change the scroll. Unfortunately this steals time that could otherwise be used for decompression. A mapper with IRQs would be necessary, because decompressing data with timed code would be insane, maybe even impossible.

Stef
Posts: 252
Joined: Mon Jul 01, 2013 11:25 am

Re: Bad Apple demo for SNES

Post by Stef » Tue Sep 29, 2015 1:48 pm

I don't know enough the NES hardware and specially the different mapper capabilities but i guess using the 8 KB CH-RAM is the most flexible solution and should be enough to store tiles for the bad apple video sequence, you always have duplicate tiles.
Also you don't need to update all tiles at each frame and using 2bpp tiles to encode 1bpp data allow tiles update to be made at 15 FPS (4 frames per update). At lest for me 64x60 is really... blocky and does not look good :-/

tepples
Posts: 21755
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Bad Apple demo for SNES

Post by tepples » Tue Sep 29, 2015 3:28 pm

tokumaru wrote:Another issue is that squeezing the picture requires CPU intervention, so every 4 scanlines the CPU has to step in and change the scroll.
Every 8. Put a 4x2 pixel pattern in both the top half of each 8x8 pixel cell, then replicate it in the bottom half. Then in the middle of each row of tiles, you fire an IRQ and skip 8 lines.

So for a 128x88 pixel letterboxed scene:

lines 0-3 (screen lines 36-38): top half of nametable row 0
IRQ -> scroll to 12
lines 12-15 (screen lines 40-43): bottom half of nametable row 1
lines 16-19 (screen lines 44-47): top half of nametable row 2
IRQ -> scroll to 28
lines 28-31 (screen lines 48-51): bottom half of nametable row 3
lines 32-35 (screen lines 52-55): top half of nametable row 4
IRQ -> scroll to 44
lines 44-47 (screen lines 56-59): bottom half of nametable row 5
[...]
lines 336-339 (screen lines 204-207): top half of nametable row 42 (that is, row 12 of the bottom nametable)
IRQ -> scroll to 348
lines 348-351 (screen lines 208-211): bottom half of nametable row 43

This gives 262-176=86 lines of blanking, and at 14 bytes per line with a straightforward unrolled copy, you can fill 86*14 = 1204 bytes, which is just shy of the 32*44 = 1408 bytes of nametable data for 128x88. But decompression of that much data on a 1.8 MHz 6502 at 30 fps might be a pain.

Another technique is to find 256 "representative" 8x8 pixel tiles and use those to represent all the different tiles in the video. This doesn't require quite as much video memory bandwidth or IRQ hackery.

User avatar
tokumaru
Posts: 11469
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Bad Apple demo for SNES

Post by tokumaru » Tue Sep 29, 2015 5:32 pm

tepples wrote:Every 8. Put a 4x2 pixel pattern in both the top half of each 8x8 pixel cell, then replicate it in the bottom half. Then in the middle of each row of tiles, you fire an IRQ and skip 8 lines.
Good idea!
Another technique is to find 256 "representative" 8x8 pixel tiles and use those to represent all the different tiles in the video. This doesn't require quite as much video memory bandwidth or IRQ hackery.
Would it look good though? 256 tiles for the entire video might result in a lot of compression artifacts.

To improve this a little bit, you could have an alternate set on the other name table, so each frame of animation could select the set that better represents it.

tepples
Posts: 21755
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Bad Apple demo for SNES

Post by tepples » Tue Sep 29, 2015 8:06 pm

tokumaru wrote:
Another technique is to find 256 "representative" 8x8 pixel tiles and use those to represent all the different tiles in the video. This doesn't require quite as much video memory bandwidth or IRQ hackery.
Would it look good though? 256 tiles for the entire video might result in a lot of compression artifacts.
It's called vector quantization, and I imagine it'd still be a lot less noticeable than the artifact of reducing it to effing 64x60. But the biggest problem is still the 512K PRG ROM limit on both popular NES flash solutions.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Bad Apple demo for SNES

Post by Drew Sebastino » Tue Sep 29, 2015 9:09 pm

tokumaru wrote:The problem with 128x120-pixel video on the NES is that each 8x8 area (a tile) contains 16 pixels, so the possible pattern combinations are far too many (65536) to be available at all times (even with the MMC5, that can address 16384 tiles at a time).
Maybe I'm just being stupid right now, but with vertical and horizontal flipping, shouldn't this just about decrease the amount of tiles needed by 3/4s? If that's the case, the MMC5 would fit perfectly in that 65536 divided by 4 is 16384.

...Wait a minute. If you flip a solid black or white tile, it isn't going to make a difference. Never mind... (I don't know how much any of you would want to use the MMC5 anyway.)

User avatar
tokumaru
Posts: 11469
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Bad Apple demo for SNES

Post by tokumaru » Tue Sep 29, 2015 9:23 pm

tepples wrote:It's called vector quantization
I know, but typically there's a new set of blocks every few frames... keeping the same set all the way through is what worries me. You could try to load a new set to the alternate pattern table progressively though, and have a keyframe every several frames. Or update a couple of tiles (that are not being used by the current image) every frame, in preparation for future images.

On the other hand, the Bad Apple video is the best candidate for something like this, since it's mostly filled white shapes over a black background (or vice-versa), so all you really have is edges.
But the biggest problem is still the 512K PRG ROM limit on both popular NES flash solutions.
Maybe break it up into several 512KB ROMs?
Espozo wrote:Maybe I'm just being stupid right now, but with vertical and horizontal flipping...
Besides the fact that flipping in each axis doesn't reduce the unique tile count by half, like you observed, the NES doesn't do background tile flipping natively, and neither does the MMC5.

tepples
Posts: 21755
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Bad Apple demo for SNES

Post by tepples » Wed Sep 30, 2015 8:08 am

MMC5 ExGrafix allows switching each tile's colors among four palettes, two of which could be set to black and white and white and black. This doubles possible tiles, as a single tile can be used for edges on both sides. Besides, you don't need all 65536 tiles; you just need the ones that are used in the picture.

User avatar
tokumaru
Posts: 11469
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Bad Apple demo for SNES

Post by tokumaru » Wed Sep 30, 2015 12:28 pm

tepples wrote:MMC5 ExGrafix allows switching each tile's colors among four palettes, two of which could be set to black and white and white and black. This doubles possible tiles, as a single tile can be used for edges on both sides.
Another great idea. In fact, the second pattern doesn't even have to be the inversion of the first, since you can have 2 completely unrelated 1bpp images in a single 2bpp tile by using the following palettes:

Palette 0:
%00: black
%01: black
%10: white
%11: white

Palette 1:
%00: black
%01: white
%10: black
%11: white
Besides, you don't need all 65536 tiles; you just need the ones that are used in the picture.
Yeah, even though there are 65536 possibilities, that doesn't mean the video uses them all.

I downloaded the original video, scaled it to the proposed resolution (128x88), converted it to B&W and exported all the frames, with the intent of writing a script to count how many of the 65536 possible patterns are actually used, but then I got lazy.

I also wanted to try quantizing the patterns down to 256 to have an idea of what that would look like, but this would be quite a lot of trouble.

User avatar
tokumaru
Posts: 11469
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Bad Apple demo for SNES

Post by tokumaru » Wed Sep 30, 2015 1:22 pm

I just wrote the script to count the patterns. If I did everything correctly, there are only 7,203 4x4-pixel patterns throughout the entire video. Considerably less than what the MMC5 can handle, so there's absolutely no need for palette tricks and whatnot. Next I want to sort the patterns by frequency and see if there's any chance of reducing that count to 256.

EDIT: I checked the frequencies of the patterns, and full black and full white are obviously at the top of the list, with 2,272,867 and 1,873,331 uses, respectively. The next entry in the list is used "only" 10,000 times. The 256th entry is used 156 times, and all entries after it are used a total of 53,557 times, so that's the amount of errors you'd have if you used only the first 256 patterns. At 6,566 frames, each with 704 blocks (6,566 * 704 = 4,622,464), 53,557 is only about 1,16% of the total, so it might actually be acceptable. Some errors might not even be easily noticeable if a similar enough substitute pattern can be found among the first 256.

BTW, sorry for hijacking this to talk about the NES, but I got carried away when the NES was mentioned. Split?

User avatar
tokumaru
Posts: 11469
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Bad Apple demo for SNES

Post by tokumaru » Wed Sep 30, 2015 3:25 pm

Well, I couldn't resist and I reduced the pattern count down to 256. Each pattern past 256 got mapped to one of the 256 most frequent ones (the one with least different pixels). I must say that the result is surprisingly good:
apple-256-tiles.gif
apple-256-tiles.gif (1.83 MiB) Viewed 7850 times
You can see some stray pixels here and there near the edges, but it hardly makes any difference, the overall effect is still very fluid.

nocash
Posts: 1092
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Bad Apple demo for SNES

Post by nocash » Wed Sep 30, 2015 7:10 pm

psycopathicteen wrote:EDIT: Screw it, it's close enough.
http://www.filehosting.org/file/details ... 0Apple.zip
Isn't that a spam site? Before permitting downloading, it wants me to enter my email address, and to agree to receive advertisings from third party companies.
Last edited by nocash on Thu Oct 01, 2015 7:27 am, edited 1 time in total.

lidnariq
Posts: 8791
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Bad Apple demo for SNES

Post by lidnariq » Wed Sep 30, 2015 7:25 pm

It's scant comfort, but at least they don't blacklist the temporary email providers I've found.

Stef
Posts: 252
Joined: Mon Jul 01, 2013 11:25 am

Re: Bad Apple demo for SNES

Post by Stef » Thu Oct 01, 2015 12:47 am

tokumaru wrote:Well, I couldn't resist and I reduced the pattern count down to 256. Each pattern past 256 got mapped to one of the 256 most frequent ones (the one with least different pixels). I must say that the result is surprisingly good:

You can see some stray pixels here and there near the edges, but it hardly makes any difference, the overall effect is still very fluid.
Honestly that already looks much better than the low resolution version even if we have a lossy compression here (but not much).

User avatar
tokumaru
Posts: 11469
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Bad Apple demo for SNES

Post by tokumaru » Thu Oct 01, 2015 3:38 pm

Stef wrote:Honestly that already looks much better than the low resolution version even if we have a lossy compression here (but not much).
I think it's great we don't even need any special effects for this, just a little extra blanking time (that easily fits in the letterbox area) and the rest of the time can be used for decompressing.

I even tried it with smaller tile sets just for fun, like only 32 for the whole video, and it still looked surprisingly decent. The still images were way blockier, but the smooth motion made up for that.

Post Reply