bad apple for PCE

[Bonknuts]

Hi all .
A guy called stef, has made a technical demo on genesis/md, based on badapple video ..

This demo run in 320*224 with 4 gray shades and with a frame rate of 30 fps ..

You can test the 8 mb rom here :  https://dl.dropbox.com/u/93332624/dev/megadrive/demo/BadApple.bin
emulator : http://umk3.hacking-cult.org/2.11hack.zip

You can see, the original video here :

Someone can do the same on PCE ??
Personaly, i don't have skills to make the same, or equivalent .

This demo is really impressive ..

 I chatted with Stef a little bit on this. While I don't care particularly about Bad Apple per se, I love the challenge that it presents. I mean, it's within the real of do-ability for quite a bit of systems (including the 8bit lesser systems) - but it's about getting the most you can out of the system to display the best version. Coming up with unique compression schemes to get it to fit in the required space is fun (IMO).

 Anyway, I looked into this last year. I started writing a compression system for 3 color version for the PCE. PCE can be put into 2bpp tile/tilemap mode, which is 4 shades/colors but 3 colors/shades compresses better. I was doing a 256x192x30fps version.

 This:

I got compressed down to $327 bytes. It can be compressed further, but I didn't finish the unique compression for this type of images.

 I had originally planned it for the SF2 extended mapper (8.5 megabytes), which mednafen emulates. But I also wanted to do a 2.5megabyte version as well (original SF2 mapper).

 PCE has some advantages:
 -Planar format for tiles means simple compression schemes are faster to decode.
 -Planar format can be selected for 2bpp display, reducing the amount of bandwidth the cpu needs to write to vram (i.e. no padding needed, so no express overhead)
 -you can write to vram during active display
 -you can also do a 1bpp version too without padding to 2bpp. Since the VDC has a latch on the MSB of the vram data port, you can just write to the MSB and ignore the LSB (you need to write zero here once and that's it). Instance bandwidth cut in half.

 Some things about huvideo; Gulliverboy runs at 10fps, but that's at 4bpp tiles. If you set the vdc to 2bpp mode, for the same bandwidth to the VDC *and* from the CDROM - you can instantly do 20fps for 2bpp. And 40fps for 1bpp. The space required for the palette map and the palette data itself inside the huvideo frame can be allocated for more tile data - thus increasing the resolution as well. So a 1bpp version at 30fps could totally be possible at a decent resolution (higher than Gulliverboy).

[touko]

ahahah, great, i have followed your discusion with stef on sega-16 forum, but i thought you were not interested anymore to demonstrate that pce can do the same .

I'm glad to see that yes  
I think that Huvideo were probably impressive in 90's but i think also that it could be improved .

Do you think that genesis vram bandwidth is very superior to pce one

[Black Tiger]

I'd love to see any kind of fmv rom that is more than a few seconds. This would be particularly cool, since it gives the impression that a regular video does, even though it can be pushed to such high quality for the hardware. I wasn't very interested in the Genesis version until I finally got around to running the rom. Hopefully the Turbo Everdrive would run it correctly.

[ccovell]

Then watch 9 Fingers (2 floppy disks), 242 (1 floppy disk) and State of the Art (A little overrated) on the Amiga! 

[Bonknuts]

Do you think that genesis vram bandwidth is very superior to pce one

 If you're strictly referring to vblank vram bandwidth, then yeah - Genesis has the edge. Mostly because the VDP in the genesis has a fast DMA channel that can read from the local processor bus (during inactive parts of the display). But in terms of bandwidth over a whole frame while the display is active, PCE wins here (though at the cost of more cpu resource) since it has near full bandwidth of the cpu to write to vram (cpu will never even saturate the VDC. Not fast enough). It's a shame really, cause the VDC in the PCE is faster than the VDP in the Genesis. For inactive areas the VDC bandwidth is ~684 per scanline (in low res mode, it's higher in the higher dot clock modes) VS Genesis 166bytes per scanline in low res mode. PCE should have had a proper DMA device in the system.

[touko]

Ok, thanks for explanation ..

But this is for RAM to VRAM, true
For for VRAM to VRAM, it's not the case, pce VDC wins in this case ?? (but i admit that's not very usefull) ..
If i understand correctly, Genesis DMA is more faster than 6280 blocs transfert ..
But it seems that 68000 is also faster than 6280 in blocs transfert, and by far ..