yeah the janky sprites looked like low-poly models from the thumbnail. I was hoping someone actually did that and re-animated the whole thing in those models. That would be impressive.
This is honestly about what I expected for a c64. Bit disappointed that there arn’t voices, but that would have probably been the straw to break the single-disk limit. (Yes, C64 audio can do voices with at least landline quality - it can also render different parts of the screen in different display modes if you know the correct voodoo to invoke - really an impressive machine for it’s era). _Might_ be possible to get better image quality too, but there are clear trade-offs (machine code vs basic, display modes requiring more bytes, etc)
Well, it's distorted as heck, but considering you had all of 70 bytes to play with per frame (so, like, 560 bits, equivalent of 28x20 raw pixels), I think we can let that slide. And it's still remarkably smooth, and recognisable throughout. Pretty goddamn astonishing. Just needs that last little twiddle to make the video actually match up with the audio ;) particularly the bit where the band appears is way off.
@@religiousindustrialaliens yeah, at normal speed it's way too fast comparing to the original, then at 0.75x speed it's a little bit too slow, so i guess adjusting it to 0.85x or so would make it sync up (at least comparing this video to the original video) now listening the original and this one side by side made me notice that the audio is also a bit faster than the original one, so well, a lot of fine tuning would be necessary lol
SlidingSilver the 64 in the Nintendo 64 refers to its 64 bit processor (something new to gaming consoles so that's why they pushed it) The 64 in the Commodore 64 refers to the 64KB of RAM it has (quite a lot for the time)
Ok brief write-up as below. I have omitted the more technical details such as clustering, genetic mutation and hill climbing, but the below should give a rough idea of what was involved in the production of this demo. The original untouched video had over 6000 unique frames running at 30fps The first step was to decimate these frames to around 2200 frames (This would result in the video having the same length if played back at 10fps) According to rough calculations, I decided to encode each set of 128 frames separately. Each chunk of 128 frames would consist of individual graphic definitions and tile lookups together with the frame-packed data. Each set of 128 frames were fed through my tile quantizer (2x2) 16x16 pixels which would generate 256 (optimum tiles in 16x16 pixels) As the whole sequence of frames is reduced to 256 16x16 tiles, there are only 1024 8x8 unique graphic occurrences in this data. This data is then fed through the 8x8 genetic/hill climbing vq encoder which results in the whole set of 128 frames only requiring 256 tiles. There is still the issue that each frame uses 1k in size. Luckily as this data was previously quantized using the 16x16 variant, the entire 128k of frame lookups can be reduced to 32k as there are only 256 unique 2x2 tiles in the frame definitions. The 2x2 lookups are extracted from the frame data (this takes up 1k) and the 128k (128 frames) converted to 32k with no loss in quality. The next stage is delta packing, I am using a bit delta variant. First frame is uncompressed 240 bytes. The next frames store only the differences. the indication on whether or not a 2x2 block has changed or not is determined by the 30 byte bit-buffer that skips or reads a lookup value. On average this 32k of data for this animation sequence gets packed to around 12k Semi uncompressed data that is used for each 128 frames is the following 2x2 tile lookup (1k) codebook (2k) compressedframes(approx 12k) Finally this entire chunk is lz packed resulting in the whole 128 bytes being packed to around 10k The decoder uses two main buffers. While playing back the 128 frames from one buffer, it loads the next set into the other buffer Decoder is running at 12frames per second (I could have optimized the decoder more - by also de-interleaving the 2x2 lookups for major speedup) but it worked fine as it is. Yes, quality does leave a lot to be desired, but I dont think much can be done in 60-70 bytes per frame (Although using vector plotting and filling would work for smooth simple area's (but eat on the frame rate) Objective was to include the sequence from beginning to end on a single disk side. And this has been achieved
It’s simply magnificent; although I know I’m talking nonsense, since they are two completely different systems, in an NES hack I’m involved with, we use a simple palette trick extensively to store twice as many graphics in the same space. Depending on the palettes displayed on the screen, a different image is shown: th-cam.com/video/y8R5u11iA1g/w-d-xo.html
When watching it, first thought "Yep, VQ, and a honking big computer. Something a 90ies scener wouldn't have had". But facing the task, i still wouldn't be sure whether it would look any good at all, and well, it's OK. But the quality leaves something to be desired. I have some terrible ideas on the subject that probably won't work, but perhaps good for experience brownies.
It is. The entire music video was programmed for the Commodore 64, and since the computer couldn't handle MP3 files (being from the 80's), the programmers converted the song onto the Commodore's sound chip, SID.
I have started on Amiga actually :-) Look for the demo Amigalicious on Pouet. There is a youtube video of this somewhere, but destroyed via the frame skipping (which the decoder somewhat relies on alternate pixel fields to recreate the video
The audio and video seem slightly too fast, particularly the video is much too fast, creating an awful desync. I'm sure you can add a dt limiter or SOMETHING to keep the whole thing on-track (not speeding) and adjust frame timings to ensure the audio plays in the right time in-sync with the video. Good job though
honest question. Would a hardware-C64 be able to play this? E.g. can it read from disk fast enough, can it write to ram fast enough, can it execute the code in realtime?
Yes, all running on a stock c64 and disk drive. If you have a real c64, you can download the disk image and transfer to real floppy, (or alternatively run it in an emulator) The depack and player code in this particular demo is not optimized but can still manage over 12fps video full screen and stream and depack from standard floppy. Link to disk images here. csdb.dk/release/?id=131628
thealgorithm thanks for answering. I don't have a hardware c64. The reason I asked was that emulators are not bound by the same limits as hardware is. The 1mhz cpu can easily be run at much higher frequency in software. In addition, the disk drive was pretty slow, at only 300 bytes/sec stock.
***** By default the c64 emulators have exactly the same restrictions as the real hardware (although its possible to warp speed or increase sid chip amount etc) All demo's (Well by myself) on c64 run on stock hardware with no expansion. The speed of the 1541 by default using kernal rom routines is around 400 bytes per second yes, but can theoretically load up to 50 times the speed using no expansion or additions. Usually the speedup by default (IRQ loaders etc is around 10x)
thealgorithm ah okay, that makes sense. Theoretically the disc drive is fast enough, in practice it'd have be to be determined, though your demo is likely to work on the c64 for real. So how are you generating this video? Is this like 8088 Corruption where you're forcing the text-only mode to output video-like stuff?
***** It does work on a real unexpanded c64 with floppy drive. Have tested it myself before releasing. This is how I am generating the video. (although this method is now outdated now :-)) The original untouched video had over 6000 unique frames running at 30fps The first step was to decimate these frames to around 2200 frames (This would result in the video having the same length if played back at 10fps) According to rough calculations, I decided to encode each set of 128 frames separately. Each chunk of 128 frames would consist of individual graphic definitions and tile lookups together with the frame-packed data. Each set of 128 frames were fed through my tile quantizer (2x2) 16x16 pixels which would generate 256 (optimum tiles in 16x16 pixels) As the whole sequence of frames is reduced to 256 16x16 tiles, there are only 1024 8x8 unique graphic occurrences in this data. This data is then fed through the 8x8 genetic/hill climbing vq encoder which results in the whole set of 128 frames only requiring 256 tiles. There is still the issue that each frame uses 1k in size. Luckily as this data was previously quantized using the 16x16 variant, the entire 128k of frame lookups can be reduced to 32k as there are only 256 unique 2x2 tiles in the frame definitions. The 2x2 lookups are extracted from the frame data (this takes up 1k) and the 128k (128 frames) converted to 32k with no loss in quality. The next stage is delta packing, I am using a bit delta variant. First frame is uncompressed 240 bytes. The next frames store only the differences. the indication on whether or not a 2x2 block has changed or not is determined by the 30 byte bit-buffer that skips or reads a lookup value. On average this 32k of data for this animation sequence gets packed to around 12k Semi uncompressed data that is used for each 128 frames is the following 2x2 tile lookup (1k) codebook (2k) compressedframes(approx 12k) Finally this entire chunk is lz packed resulting in the whole 128 bytes being packed to around 10k The decoder uses two main buffers. While playing back the 128 frames from one buffer, it loads the next set into the other buffer Decoder is running at 12frames per second (I could have optimized the decoder more - by also de-interleaving the 2x2 lookups for major speedup) but it worked fine as it is. Yes, quality does leave a lot to be desired, but I dont think much can be done in 60-70 bytes per frame (Although using vector plotting and filling would work for smooth simple area's (but eat on the frame rate) Objective was to include the sequence from beginning to end on a single disk side. And this has been achieved
That time when Z80 systems leave 6502 systems eating dust. Even the ZX-Spectrum is better than this... Not to mention the Amstrad CPC, SMS and the best version on MSX2. :)
![[TH] 2024 PMWC x EWC Group Stage Day 3 | PUBG MOBILE WORLD CUP x ESPORTS WORLD CUP](http://i.ytimg.com/vi/VnOqutfqWqU/mqdefault.jpg)
"Bad Apple 64"
Oh, hey, it's Bad Apple running on the Nintendo 64! Maybe it's even in 480p...?
*Commodore 64*
"... oh my god."
я теж подумав, що це лунає N64
That's me
yeah the janky sprites looked like low-poly models from the thumbnail. I was hoping someone actually did that and re-animated the whole thing in those models. That would be impressive.
damn
I literally had the exact same thought process when clicking this video lol
Imagine demonstrating this during C64 launch on CES 1982... ;-)
People would be like: "YO ARE YOU SEEING THIS RIGHT NOW?" And "THIS IS SO RAD!!!"
People would be pissing their pants
@@nintendhoe_693 I don't think so…
th-cam.com/video/Ko9ZA50X71s/w-d-xo.html
@@nintendhoe_693 People would be shitting thier pants
This is honestly about what I expected for a c64. Bit disappointed that there arn’t voices, but that would have probably been the straw to break the single-disk limit. (Yes, C64 audio can do voices with at least landline quality - it can also render different parts of the screen in different display modes if you know the correct voodoo to invoke - really an impressive machine for it’s era). _Might_ be possible to get better image quality too, but there are clear trade-offs (machine code vs basic, display modes requiring more bytes, etc)
Well, it's distorted as heck, but considering you had all of 70 bytes to play with per frame (so, like, 560 bits, equivalent of 28x20 raw pixels), I think we can let that slide. And it's still remarkably smooth, and recognisable throughout. Pretty goddamn astonishing.
Just needs that last little twiddle to make the video actually match up with the audio ;) particularly the bit where the band appears is way off.
here even weaker computer only had 124 threads (piksel) at its disposal th-cam.com/video/zh8MiNzKkiA/w-d-xo.html
@愛してるよ!私は毛皮です。 lol the song is fine, the video is just way too fast
@@anonymousanonymous8216 yeah, memory issues on an old computer. impressive nonetheless and simply a problem you can fix with editing.
@@religiousindustrialaliens yeah, at normal speed it's way too fast comparing to the original, then at 0.75x speed it's a little bit too slow, so i guess adjusting it to 0.85x or so would make it sync up (at least comparing this video to the original video)
now listening the original and this one side by side made me notice that the audio is also a bit faster than the original one, so well, a lot of fine tuning would be necessary lol
kinda wish the music lined up but this is still super impressive
Dude i was going crazy since the music was out of sync
@@capnbug
s
a
m
e
I thought this was for the Nintendo 64, and not the C64...
I guess it's a coincidence that they both have the number 64 in them...
SlidingSilver the 64 in the Nintendo 64 refers to its 64 bit processor (something new to gaming consoles so that's why they pushed it)
The 64 in the Commodore 64 refers to the 64KB of RAM it has (quite a lot for the time)
We have come so far.
Same
Ok brief write-up as below. I have omitted the more technical details such as clustering, genetic mutation and hill climbing, but the below should give a rough idea of what was involved in the production of this demo.
The original untouched video had over 6000 unique frames running at 30fps
The first step was to decimate these frames to around 2200 frames (This would result in the video having the same length if played back at 10fps)
According to rough calculations, I decided to encode each set of 128 frames separately.
Each chunk of 128 frames would consist of individual graphic definitions and tile lookups together with the frame-packed data.
Each set of 128 frames were fed through my tile quantizer (2x2) 16x16 pixels which would generate 256 (optimum tiles in 16x16 pixels)
As the whole sequence of frames is reduced to 256 16x16 tiles, there are only 1024 8x8 unique graphic occurrences in this data.
This data is then fed through the 8x8 genetic/hill climbing vq encoder which results in the whole set of 128 frames only requiring 256 tiles.
There is still the issue that each frame uses 1k in size. Luckily as this data was previously quantized using the 16x16 variant, the entire 128k of frame lookups can be reduced to 32k as there are only 256 unique 2x2 tiles in the frame definitions.
The 2x2 lookups are extracted from the frame data (this takes up 1k) and the 128k (128 frames) converted to 32k with no loss in quality.
The next stage is delta packing, I am using a bit delta variant. First frame is uncompressed 240 bytes. The next frames store only the differences. the indication on whether or not a 2x2 block has changed or not is determined by the 30 byte bit-buffer that skips or reads a lookup value.
On average this 32k of data for this animation sequence gets packed to around 12k
Semi uncompressed data that is used for each 128 frames is the following
2x2 tile lookup (1k)
codebook (2k)
compressedframes(approx 12k)
Finally this entire chunk is lz packed resulting in the whole 128 bytes being packed to around 10k
The decoder uses two main buffers.
While playing back the 128 frames from one buffer, it loads the next set into the other buffer
Decoder is running at 12frames per second (I could have optimized the decoder more - by also de-interleaving the 2x2 lookups for major speedup) but it worked fine as it is.
Yes, quality does leave a lot to be desired, but I dont think much can be done in 60-70 bytes per frame (Although using vector plotting and filling would work for smooth simple area's (but eat on the frame rate)
Objective was to include the sequence from beginning to end on a single disk side. And this has been achieved
Who was the skeptic, and what have they said about it? :) Excellent work!
Darin Arrick Perhaps a daemon sitting on his shoulder whispering in his ear? =)
Ahaaa. The sceptic was indeed made up :-)
It’s simply magnificent; although I know I’m talking nonsense, since they are two completely different systems, in an NES hack I’m involved with, we use a simple palette trick extensively to store twice as many graphics in the same space. Depending on the palettes displayed on the screen, a different image is shown: th-cam.com/video/y8R5u11iA1g/w-d-xo.html
From the title, was expecting Nintendo 64, very much not disappointed to find this was on a C64 from the early 80s.
My god I freaking LOVE the sound chip on the C64!
SID 8580 is mmush better than stock 6581
video and audio are *very* off-sync, but good job as a whole
the video is playing too fast
Commodore 64, ok, no Nintendo 64 yet, I will now port since I just got the dev kit running
I always knew you were badass with a C64 Algo, but you never cease to surprise us.
This music video always makes me cry no matter the form
Mad props to you this is incredible
I thought it was N64 but this is amazing too
Most impressive!
When watching it, first thought "Yep, VQ, and a honking big computer. Something a 90ies scener wouldn't have had". But facing the task, i still wouldn't be sure whether it would look any good at all, and well, it's OK.
But the quality leaves something to be desired. I have some terrible ideas on the subject that probably won't work, but perhaps good for experience brownies.
Impressive, very impressive indeed.
Impressive!
Would love to read on how that was achieved!
The comment right above yours lol
Here you go! (Screencaps) drive.google.com/drive/folders/1fbykuE0FmDAxuqZwJWkn44SeD8FePmHe
Great demo!!!
And that on the C64 ^_^
That's impressive!
That is quite un-sane! I second the requests for a write up. =)
When I saw the title I assumed it was about the Nintendo 64
"does it make noise?"
"Yes."
"Does it have a screen?"
"Yes."
"Can I record it?"
"Yes."
**Bad apple ensues**
>Does it have a screen
Someone recorded Bad Apple in stop motion _on apples._ More like as long as it has at least two states.
Trust me the algorithm will bless this video sooner or later.
Woah 4K quality
boy I would love to hear how you have compressed this in another video
Write up as below by Naveed Khugiani (myself) but I had logged in under my non-scene handle name :-)
No no no. I rather think that when something can be done, then you say it can
:-)
On my first watch I assumed it was done in text mode but on a second watch I am thoughly confused
What the hell. Good job!
nice
failed but success
This sounds like a 8-bit cover for bad apple
It is. The entire music video was programmed for the Commodore 64, and since the computer couldn't handle MP3 files (being from the 80's), the programmers converted the song onto the Commodore's sound chip, SID.
Of course the n64 could run bad apple, oh that's not the 64 we were talking about
0.75x for the speed of the actual song
woah
Comming from the Atari scene , the C64 has better sound but worse gfx for Bad Apple demo. Greetings from SOD/DCW! from old Atari 8bit demoscene.
Audio is out-of-sync with video.
Alex C IKR someone has to fix this
Music get behind eventually
real
Look like torn paper art
If you can do it in 170k on C64, who knows what you can do on a standard A500 in 880k!
I have started on Amiga actually :-) Look for the demo Amigalicious on Pouet. There is a youtube video of this somewhere, but destroyed via the frame skipping (which the decoder somewhat relies on alternate pixel fields to recreate the video
didnt they run this on an pc 808 from 1981? lol
The audio and video seem slightly too fast, particularly the video is much too fast, creating an awful desync. I'm sure you can add a dt limiter or SOMETHING to keep the whole thing on-track (not speeding) and adjust frame timings to ensure the audio plays in the right time in-sync with the video. Good job though
As always 144p is mandatory
Music is not in synch, but it's still impressive!
honest question. Would a hardware-C64 be able to play this? E.g. can it read from disk fast enough, can it write to ram fast enough, can it execute the code in realtime?
Yes, all running on a stock c64 and disk drive. If you have a real c64, you can download the disk image and transfer to real floppy, (or alternatively run it in an emulator) The depack and player code in this particular demo is not optimized but can still manage over 12fps video full screen and stream and depack from standard floppy. Link to disk images here. csdb.dk/release/?id=131628
thealgorithm thanks for answering. I don't have a hardware c64. The reason I asked was that emulators are not bound by the same limits as hardware is. The 1mhz cpu can easily be run at much higher frequency in software. In addition, the disk drive was pretty slow, at only 300 bytes/sec stock.
***** By default the c64 emulators have exactly the same restrictions as the real hardware (although its possible to warp speed or increase sid chip amount etc)
All demo's (Well by myself) on c64 run on stock hardware with no expansion.
The speed of the 1541 by default using kernal rom routines is around 400 bytes per second yes, but can theoretically load up to 50 times the speed using no expansion or additions. Usually the speedup by default (IRQ loaders etc is around 10x)
thealgorithm ah okay, that makes sense. Theoretically the disc drive is fast enough, in practice it'd have be to be determined, though your demo is likely to work on the c64 for real.
So how are you generating this video? Is this like 8088 Corruption where you're forcing the text-only mode to output video-like stuff?
***** It does work on a real unexpanded c64 with floppy drive. Have tested it myself before releasing.
This is how I am generating the video. (although this method is now outdated now :-))
The original untouched video had over 6000 unique frames running at 30fps
The first step was to decimate these frames to around 2200 frames (This would result in the video having the same length if played back at 10fps)
According to rough calculations, I decided to encode each set of 128 frames separately.
Each chunk of 128 frames would consist of individual graphic definitions and tile lookups together with the frame-packed data.
Each set of 128 frames were fed through my tile quantizer (2x2) 16x16 pixels which would generate 256 (optimum tiles in 16x16 pixels)
As the whole sequence of frames is reduced to 256 16x16 tiles, there are only 1024 8x8 unique graphic occurrences in this data.
This data is then fed through the 8x8 genetic/hill climbing vq encoder which results in the whole set of 128 frames only requiring 256 tiles.
There is still the issue that each frame uses 1k in size. Luckily as this data was previously quantized using the 16x16 variant, the entire 128k of frame lookups can be reduced to 32k as there are only 256 unique 2x2 tiles in the frame definitions.
The 2x2 lookups are extracted from the frame data (this takes up 1k) and the 128k (128 frames) converted to 32k with no loss in quality.
The next stage is delta packing, I am using a bit delta variant. First frame is uncompressed 240 bytes. The next frames store only the differences. the indication on whether or not a 2x2 block has changed or not is determined by the 30 byte bit-buffer that skips or reads a lookup value.
On average this 32k of data for this animation sequence gets packed to around 12k
Semi uncompressed data that is used for each 128 frames is the following
2x2 tile lookup (1k)
codebook (2k)
compressedframes(approx 12k)
Finally this entire chunk is lz packed resulting in the whole 128 bytes being packed to around 10k
The decoder uses two main buffers.
While playing back the 128 frames from one buffer, it loads the next set into the other buffer
Decoder is running at 12frames per second (I could have optimized the decoder more - by also de-interleaving the 2x2 lookups for major speedup) but it worked fine as it is.
Yes, quality does leave a lot to be desired, but I dont think much can be done in 60-70 bytes per frame (Although using vector plotting and filling would work for smooth simple area's (but eat on the frame rate)
Objective was to include the sequence from beginning to end on a single disk side. And this has been achieved
The music being out of sync was a great touch!
The video (but not the sound - or not as much as the sound) should be slower
にほんじーーーん
The fact it was too fast
Oh wait, it's commodore 64, not nintendo 64!
Um, It looks glitchy and way faster then the song
0:46 c mon realy
Audio out of sync
sound don't sync
I liked the Atari 8 bit with it's interlaced solution better.
This is very cool but also incredibly off-putting how not dinner the song is to the video.
IMHO ZX Spectrum cover is way better, both sound and video.
Классно но z80 все таки круче
That time when Z80 systems leave 6502 systems eating dust. Even the ZX-Spectrum is better than this... Not to mention the Amstrad CPC, SMS and the best version on MSX2. :)
Not to mention the gameboy! But the big issue here is surely the storage limitation .
music too fast
video too faster
This could’ve been better tbh.
Written any good C64 demos lately?