Bad Apple for the Nintendo DS

Well, it was about time. It seemed like there was no real Bad Apple rom for the Nintendo DS yet, so I decided to make one.



It runs at 60fps and with 48 kHz stereo audio. I'm using a simple video codec I created just for this video. It simply encodes each frame into a character bg for the ds, merging tiles that are the same into one. Each frame is then LZ77 compressed to reduce the size of the remaining data by about 50%.

Download here if you wanna try for yourself: https://mega.nz/#!dgkmhSiL!5jLs7cIPuYO9R2oXaP8gGepAl9KeAEQ4heBsMl19Lsc

The source of both the player and the encoder can be found here: https://mega.nz/#!xhNQlRqZ!Iez6e-diTYIKyIrjLfXZD2fWJrps0_TPAMWxADaPmak

Update Japanese version here: https://mega.nz/#!tx9gVLQJ!rUCiZhHBDKX4ZB2x07BnlgQAqcUjb26EnnzZcpsF1Bs
 
Last edited by Gericom,
I wonder what causes that issue. Maybe the auto just gives up and causes the issue?
Slot 2 set to auto ends up setting the GBA slot to PassME for homebrew, and the libnds code detects that and then uses the GBA slot for reading. There's only 32MB of addressable space on the GBA slot, and any reads past that just return 0xFF(causing the freeze after roughly a minute).
 
Last edited by windwakr,
So you're using tiles, huh? I can see why it works so smoothly then. Unfortunately it wouldn't be very useful for full colour video, but just black and white backgrounds work extremely well since there's only so many tiles you can make with just two colours. Nicely done, really - I worked on something similar back in the day, first for my "I'm feeling lucky" KFC for DS homebrew and then later when I tried it with full-blown rasters, but then the 3DS came along and sort of made the DS obsolete. I got away without compression, but I can see how much smoother and smaller you were able to make yours just by adding that.
 
I'll see what I can do for you xD

--------------------- MERGED ---------------------------


Yes, of course I could have done that, but I would not have been able to reach 60fps most likely and it's a tradition with this video that a custom video codec is used.

so its kind of like how the first doom is always the very first thing to be ported to a new device?
 
This is really cool stuff and puts my Bad Apple on an Xk3y remote to shame. I really do love seeing this pop up on all sorts of devices.
 
  • Like
Reactions: daxtsu
I can't get this to work for some reason... I tried running it on my DS Lite with my R4 and I just get a white screen.

Same here, happens with my actual DS Lite too
Does it happen with both versions? I ran it on my r4 with wood and it worked fine. And it also worked on the is-nitro (albeit a little altered cause the is-nitro has no flashcard of course)
 
A good few years ago, I was challenged to fit the whole bad apple video onto a single 170k floppy to run on a stock c64 machine. Quality sucks, but has over 2000 frames or so packed into 170k of disk space streaming from floppy disk.
 
  • Like
Reactions: VinsCool
A good few years ago, I was challenged to fit the whole bad apple video onto a single 170k floppy to run on a stock c64 machine. Quality sucks, but has over 2000 frames or so packed into 170k of disk space streaming from floppy disk.

Haha, nice! How does that work?
 
Haha, nice! How does that work?

The encoder is specifically created to take into account the c64's limitations. In particular, the decode needs to be very fast and use minimal cpu cycles (for the loader to be able to stream from floppy at the same time). More cpu usage for the decoder means less load speed which will cause issues. Chunks of 256 frames are encoded to 8x8 characters via vector quantisation (With some additional improvements) and then these are cluster tile merged which result in a frame of data using 240 bytes (that point to lookup tables that fetch the 8x8 characters). These are then delta packed and then lz packed. The loader loads and decompresses to the delta packed form while the previous sequence of 256 frames are showing and then continue from the semi-depacked frames, plotting them at approximately 12.5fps. This thankfully leaves ample CPU time for the loader to load the next set of packed data from disk while it is depacking the frames onto the screen.
 

Site & Scene News

Popular threads in this forum