Apart from being terribly nerdy, I'd say it's the aesthetics made of plays between black and white which allow to compress it into 1bit or 2bits per pixels video, making it juuuust barely doable on systems that are not supposed to be able to play FMV.
That would be my guess as well. This generally consists of RLE encoding, and/or storing a table of all possible "tiles" (generally 4x4 pixel regions) and encoding the video that way. Decompression on the fly isn’t easy either, though simply tracking the scan line helps out.
@@geotalemobile2157 Also because of both competition between coders and platform rivalry... "Oh, if you can do that on C64, then the Atari can do it, if Sega can, then SNES can etc..."
I actually find the fluidity more impressive. Baking in or figuring out on the fly which ~25% of the nametable to overwrite every frame, since you do only get time for that many tiles, even though the final result looks like the whole screen updates. Unless it's literally being done with more CHR banks than I'd think MMC3 could index, and swapping out the whole pattern table every frame...
@@LoneKiltedNinja I don't think it is stored in the way you think... MMC3 is able to bank swap part of the CHR tables avaible to the PPU to select from. You can't change content of VRAM while the TV beam is active, limiting you to Vblank to change screen content... BUT you can change the ROM "wiring" using MMC3 banking capabilities during that period... so as the horizontal lines are displayed you can prepare the next lines using this capabilities WHILE the frame is beamed on the scren without messing with PPU internal registries.... hence Mephistus comment. Using some clever palette swap technique you can get pretty decent compression ratio I guess. Though this is kind of cheating as it uses addittionnal hardware provided by the cartridge... but so many game did so, it seems legit.
@@emmanueloverrated That was the gist of the last sentence of my comment, yes. There are 3 ways to change what is visually presented: Most "typically," you can rewrite the nametable (the tile indices/placements on the screen grid), which in my experience, if you keep to strictly sequential writes, lets you cover about 25% of the screen in a given vblank. You bring up a good second option of changing the palette, since the animation is only 2 colors, each tile could contribute to multiple frames of the animation, but that would require some quite steep planning investment (although with whole-tile 8x8 screen-pixel image-"pixels", 1 palette could independently control all 4 "pixels" in a 16x16 palletized block). Or, to Mephitus' comment and my own incredulity, you _could_ technologically, given an arbitrarily high bank count, swap out the whole CHR bank (the content of the tiles that have already been placed) BUT that would require a ridiculous number of CHR banks. Even if you gave yourself unlimited ROM, the MMC3 bank data register is only 1 byte, so you can only index 256 different source locations, and each of those, short of diving back into the architecture, I _think_ can only swap out a quarter or half of the available tiles. And the entire CHR bank is only about a quarter the size of the screen, so... pure CHR swap, even doing it 4 times each frame to update every tile on the screen... 256 source locations ~= 64 full CHR banks ~= 16 full-frames of data accessible, unless you put a mapper on your mapper to programmatically change what is at those source locations over time. Moreover, it sounds like real hardware MMC3 implementations only wire 6 address lines, which would knock the count down to 4 full frames. So at some level, I'm pretty sure nametable rewrite needs to be involved, and that's slow and chunky and would require both considerable planning and, at this fluidity, coverage by other mechanisms.
@@LoneKiltedNinja Very interresting answer. In fact, I just revised MMC3 mapper, and I didn't remember you could not swap smaller than 25% of the tiles with MMC3. Thus, it's impossible to store all the frames uncompressed here... MMC3 can only addresses 512k. Thus, the compression must involve several combined tricks, it can't be only one method. For the planning, it's possible to write a compression tool that try to find for each frame the right combination between the different approaches by bruteforcing. Compressing using such tool would be pretty CPU intensive... Some ideas, to clear the screen to black, you can set the active banks to an empty bank while preparing the next frames. For regular frames you can proceed to diffential changes by updating the nametable. Palette changes can be used to update more than 4 tiles at once, but like you said this is limited. Though, when a sudden change require more than 25% of the tiles, you can consume a bank to help you getting a rapid update.
Really? You ought to watch some more then... You can start with this on the (admittedly technically far superior) Sega Master System: th-cam.com/video/eLRtjkkBto0/w-d-xo.html
I’d say the Commodore 64 beats out Sega for sound quality. Sure, that Sega playback has a voice (how?), it’s audio is also muddy with static. Try: th-cam.com/video/fu7rRYkWsyk/w-d-xo.html
This is an extraordinary technical feat. Having coded myself on the NES including a program that displays a rotating icosahedron, I cannot figure out how on earth this was done. The frame rate is amazing and there are no compression artifacts, in fact I cannot see a single tile. How was this even achieved? Even considering some simple Run Length Encoding together with palette effects it seems to good to be true, but perhaps it can be done somehow. Would be interesting to see the source code.
I would asume that its the background layer that they are using, since giant sprites like these would probably be impossible and even if it did happen, serious flickering would take place
Same as other consoles it's not powerful enough to really do real-time bitmaps so it's just making a pseudobitmap from background tiles and updating palettes
Why they did NOT used the pcm channel for streaming digital sound, whether in 1bit dpcm or 4bit adpcm, it should be possible, 7bit pcm is in combination with this sadly impossible since it eat 99% of the cpu power.
PCM sampling was supported on the NES, it took a lot of cart storage and possibly CPU time, so it was usually only used for sound effects and speech, but could be the whole soundtrack like in Super Angry Birds Chinese ROM (th-cam.com/video/rNMymbt1Wf8/w-d-xo.html)
Why are you surprised? The Master System's graphical capabilities absolutely destroyed the NES. Compare the two versions of this, and then check out the beautiful Master System 3D version.
@@markchambers3833 thats true, ive been a little hard on the master system for a while , mainly because of how primitive the sound hardware is , but when it comes to graphics its way better , likes the r type port for example
@@kiwibro6454 It's a pity the FM sound chip didn't make it to the west, when you love your master system you come to love your tinny beeps and bleeps though. FM chip improves the sound for non-afficianados. Weird thing about the FM chip is that the sound for loads of the games is coded for it, even some European exclusives that were never going to be able to run the code. Unless of course the system was modded, but no-one really did that back then. I was playing MS r-type yesterday, it's an amazing game. Sound's really good on it too, even on my basic MS2. It's a real shame that Nintendo stitched so many game developers into exclusive deals. They'd never get away with that dubious practice today. Master System owners (in Europe at least) got a great library of games - graphically some of the later ones are stunning for an 8 bit machine (Asterix, the Disney games, etc.). But we missed out on some great ports - Megaman, Castlevania, etc. We did okay though. :)
@@markchambers3833 ikr, i had no idea why they never built in the fm sound onto masters systems outside of japan, if anything the fm makes the master system feel alot more, advanced if anything , my question is, how come the sonic games on master system never got fm support?
when i saw this, the music was surprisingly good. i expected either a half-decent transcription or the original audio crushed into 1-bit dpcm, but the music here is great
I remember buying an everdrive and this came with the SD card inside, very impressive for NES
This title screen sequence looks familiar, but I forgot the game..
@@RealUnify touhou?
when censorship in japan goes maximum
U haven't seen the VCS version yet, right?
how about get some bitches instead
LMAO
@@bullworths_strongest Bruh
@@bullworths_strongest ?
00:51
You can still see the smirk holy shocnxxghs
ik, most don’t even show a pixel so it was crazy to see that
I've seen this on Atari 2600, C64, Impulse Tracker... why is this sooo popular among demosceners?
Because it's black and white?
Also Touhou, maine reason is Touhou
Apart from being terribly nerdy, I'd say it's the aesthetics made of plays between black and white which allow to compress it into 1bit or 2bits per pixels video, making it juuuust barely doable on systems that are not supposed to be able to play FMV.
That would be my guess as well. This generally consists of RLE encoding, and/or storing a table of all possible "tiles" (generally 4x4 pixel regions) and encoding the video that way. Decompression on the fly isn’t easy either, though simply tracking the scan line helps out.
@@geotalemobile2157
Also because of both competition between coders and platform rivalry... "Oh, if you can do that on C64, then the Atari can do it, if Sega can, then SNES can etc..."
why do i feel like the programming behind this is bank-switching hell...
Mephitus Incognito The most awesome thing is that this is done on your everyday MMC3 mapper...
I actually find the fluidity more impressive. Baking in or figuring out on the fly which ~25% of the nametable to overwrite every frame, since you do only get time for that many tiles, even though the final result looks like the whole screen updates. Unless it's literally being done with more CHR banks than I'd think MMC3 could index, and swapping out the whole pattern table every frame...
@@LoneKiltedNinja I don't think it is stored in the way you think... MMC3 is able to bank swap part of the CHR tables avaible to the PPU to select from. You can't change content of VRAM while the TV beam is active, limiting you to Vblank to change screen content... BUT you can change the ROM "wiring" using MMC3 banking capabilities during that period... so as the horizontal lines are displayed you can prepare the next lines using this capabilities WHILE the frame is beamed on the scren without messing with PPU internal registries.... hence Mephistus comment. Using some clever palette swap technique you can get pretty decent compression ratio I guess.
Though this is kind of cheating as it uses addittionnal hardware provided by the cartridge... but so many game did so, it seems legit.
@@emmanueloverrated That was the gist of the last sentence of my comment, yes. There are 3 ways to change what is visually presented: Most "typically," you can rewrite the nametable (the tile indices/placements on the screen grid), which in my experience, if you keep to strictly sequential writes, lets you cover about 25% of the screen in a given vblank. You bring up a good second option of changing the palette, since the animation is only 2 colors, each tile could contribute to multiple frames of the animation, but that would require some quite steep planning investment (although with whole-tile 8x8 screen-pixel image-"pixels", 1 palette could independently control all 4 "pixels" in a 16x16 palletized block). Or, to Mephitus' comment and my own incredulity, you _could_ technologically, given an arbitrarily high bank count, swap out the whole CHR bank (the content of the tiles that have already been placed) BUT that would require a ridiculous number of CHR banks. Even if you gave yourself unlimited ROM, the MMC3 bank data register is only 1 byte, so you can only index 256 different source locations, and each of those, short of diving back into the architecture, I _think_ can only swap out a quarter or half of the available tiles. And the entire CHR bank is only about a quarter the size of the screen, so... pure CHR swap, even doing it 4 times each frame to update every tile on the screen... 256 source locations ~= 64 full CHR banks ~= 16 full-frames of data accessible, unless you put a mapper on your mapper to programmatically change what is at those source locations over time. Moreover, it sounds like real hardware MMC3 implementations only wire 6 address lines, which would knock the count down to 4 full frames. So at some level, I'm pretty sure nametable rewrite needs to be involved, and that's slow and chunky and would require both considerable planning and, at this fluidity, coverage by other mechanisms.
@@LoneKiltedNinja Very interresting answer. In fact, I just revised MMC3 mapper, and I didn't remember you could not swap smaller than 25% of the tiles with MMC3. Thus, it's impossible to store all the frames uncompressed here... MMC3 can only addresses 512k.
Thus, the compression must involve several combined tricks, it can't be only one method. For the planning, it's possible to write a compression tool that try to find for each frame the right combination between the different approaches by bruteforcing. Compressing using such tool would be pretty CPU intensive...
Some ideas, to clear the screen to black, you can set the active banks to an empty bank while preparing the next frames. For regular frames you can proceed to diffential changes by updating the nametable. Palette changes can be used to update more than 4 tiles at once, but like you said this is limited. Though, when a sudden change require more than 25% of the tiles, you can consume a bank to help you getting a rapid update.
If i seen this as a kid as one of game intros i would have heart attack.
you ate a bad apple
@bruh lol yeah
Touhou 4 intro😂😂
Out of all of the 8-bit renditions of this song I’ve heard, (and trust me, I’ve heard quite a few,) this is by far the best, so nice job!
Really? You ought to watch some more then... You can start with this on the (admittedly technically far superior) Sega Master System:
th-cam.com/video/eLRtjkkBto0/w-d-xo.html
I’d say the Commodore 64 beats out Sega for sound quality.
Sure, that Sega playback has a voice (how?), it’s audio is also muddy with static.
Try: th-cam.com/video/fu7rRYkWsyk/w-d-xo.html
For me it was a wise move to use one of the square channels as the bass. Kinda like in Kirby's Adventure.
Sega Master System versions (B&W and colored) are much better.
@@Relkond , Sega Master has the FM audio chip and it's quality is comparable to Sega Genesis audio.
What's cool about this rom is you can change the color pallete and pixel type.
This is an extraordinary technical feat. Having coded myself on the NES including a program that displays a rotating icosahedron, I cannot figure out how on earth this was done. The frame rate is amazing and there are no compression artifacts, in fact I cannot see a single tile. How was this even achieved? Even considering some simple Run Length Encoding together with palette effects it seems to good to be true, but perhaps it can be done somehow. Would be interesting to see the source code.
th-cam.com/video/rDWE952gaTM/w-d-xo.html
This is very good! And as someone who does NES/Famicom music works in FamiTracker the song rendition is impressive too!
Famitracker is cool
@@Genirc based
2 background sprites
One is fully black
And one is fully white
Thats how it works (I think so
So I'm guessing one is in the foreground, and parts of it go transparent to show the other sprite?
16 "2×2" sprites
What on earth are "background sprites"? 😂
@@amogus7 could be, the pixels here look small compared to 8x8 sprites
No sprite flickering?! Hmmm.... How did they pull that off?
because.. they aren't using sprites
I would asume that its the background layer that they are using, since giant sprites like these would probably be impossible and even if it did happen, serious flickering would take place
Same as other consoles it's not powerful enough to really do real-time bitmaps so it's just making a pseudobitmap from background tiles and updating palettes
this was the 3rd retro remake of bad apple i saw and it actually is on key instead of the tiny notes 5.1 million key or a sad key
This was made 10yrs ago-
Even earlier. This rom is from 2009
No gray, only black and white.
0:13 That _clap_ sound when the hand catches the apple is very nice!
Bad Apple was when every 6502 system was destroyed by their respective Z80 competitors...
Press select twice for better detail
Still has better sound quality than Norwegian Black metal
Is it just me, or do the drums in the first 12 seconds sound like the opening of Orgy's cover of "Blue Monday"?
This is epic.
Rise 8 year old comment
@@matsu4010 now 10 lol
Why they did NOT used the pcm channel for streaming digital sound, whether in 1bit dpcm or 4bit adpcm, it should be possible, 7bit pcm is in combination with this sadly impossible since it eat 99% of the cpu power.
because the framerate would be really low bc of almost all the cycles being used on the sample?
and tbh having that authentic 2a03 synth cover of the song is nicer I think
Whoever made this deserves a million dollars...
@ R W 2. Really, - This is Unprised, in any time (!!!). BfK. ☑❗❗❗☝
@@bergerfonkoenig6997 you said it man
Super Touhou Bros
PCM sampling was supported on the NES, it took a lot of cart storage and possibly CPU time, so it was usually only used for sound effects and speech, but could be the whole soundtrack like in Super Angry Birds Chinese ROM (th-cam.com/video/rNMymbt1Wf8/w-d-xo.html)
Japan does sometimes censor girls in videos tho
The nes doesn’t have that low of an fps
The nes is 60 fps but this runs at like 24
It’s just there emulator run it on a new one and it runs fine
92k views godayum and 92 subs
If you squint your eyes it looks like 16-bit for some reason.
This is so cool.
thanks miku , very cool
do you remember commenting this?
Are you still out there 10 years later
This better then what I imagined it would sound like
is that the freakin’ hummer flute?
Jesus Christ!
Cool32216 Satoru Iwata*
I've seen in Windows 93
this is even used in a YTPMV!
whereeee
Link please
Nostalgic chiptum.
2:10
3:28
man i love seeing what people can do with limited hardware
Жиза
15 fps?
Either way 15, 30 or 60, it is impressive
@@santiagovalentine8294 it's definitely not 24, 30 or 60 fps. So it must be 15.
@@zekiz774 or even twelve, I think twelve is the minimum to simulate movement, or it uses less and only uses the key frames to simulate more frames
@@santiagovalentine8294 yes, but it looks more like 15.
excelent
is that the vrc6
Recomendations:yes
i love old years
Im suprised the master system version is better looking
Why are you surprised? The Master System's graphical capabilities absolutely destroyed the NES. Compare the two versions of this, and then check out the beautiful Master System 3D version.
@@markchambers3833 thats true, ive been a little hard on the master system for a while , mainly because of how primitive the sound hardware is , but when it comes to graphics its way better , likes the r type port for example
@@kiwibro6454 It's a pity the FM sound chip didn't make it to the west, when you love your master system you come to love your tinny beeps and bleeps though. FM chip improves the sound for non-afficianados.
Weird thing about the FM chip is that the sound for loads of the games is coded for it, even some European exclusives that were never going to be able to run the code. Unless of course the system was modded, but no-one really did that back then.
I was playing MS r-type yesterday, it's an amazing game. Sound's really good on it too, even on my basic MS2. It's a real shame that Nintendo stitched so many game developers into exclusive deals. They'd never get away with that dubious practice today. Master System owners (in Europe at least) got a great library of games - graphically some of the later ones are stunning for an 8 bit machine (Asterix, the Disney games, etc.). But we missed out on some great ports - Megaman, Castlevania, etc. We did okay though. :)
@@markchambers3833 ikr, i had no idea why they never built in the fm sound onto masters systems outside of japan, if anything the fm makes the master system feel alot more, advanced if anything , my question is, how come the sonic games on master system never got fm support?
@@kiwibro6454 Think it was to keep costs down, it is a pity though.
when i saw this, the music was surprisingly good. i expected either a half-decent transcription or the original audio crushed into 1-bit dpcm, but the music here is great
3DSのnesエミュレータに入れて見てます。
😎😎😎😎😎😎😎😎😎😎😎😎😎😎😎😎😎😎😎😎
So good!
Why not they used DPCM channel to play back audio. They have tons of memory banks.
i'd assume storage constraints
Well done!
Is nes
Quite the sight this may be
*damn, lets grab our gba and play these*
☯︎3:28-2:19👁
16 bits.
Here we go again...
Fixed link: web.archive.org/web/20100206030142/www.geocities.jp/littlimi/bad_apple_2.htm Annoying that the site redirects to the home page.
Updated description, thanks
Oyashiro you welcome. Thank god the archive save the day.
Bad Apple (Censorship)
Great made (!!!). P.S.: "NES".., - is it the "SEGA"...??? Or something else (???). BfK. 👍🆗💯⭐🎬⭐🎮⭐🎮⭐🎶⭐😘🆒😃