pouët.net

Bad Apple 64
screenshot added by algorithm on 2014-06-29 08:11:51
platform :
type :
release date : june 2014
  • 47
  • 9
  • 2
popularity : 64%
 64%
  • 0.78
alltime top: #2782
added on the 2014-06-29 08:11:51 by algorithm algorithm

popularity helper

increase the popularity of this prod by spreading this URL:

or via: facebook twitter pinterest tumblr bluesky threads

comments

This is pure 100% animation and was only created to show that it could be done... over 2000 frames packed to a single disk side on the c64.
Each frame packed to around 70 bytes and running at 12fps streaming fully from disk!
added on the 2014-06-29 08:12:10 by algorithm algorithm
AreYouAWizard.jpg
rulez added on the 2014-06-29 09:30:44 by squeakyneb squeakyneb
And to think, YouTube just added support for 60fps. ;) Is this "Bad Apple" video the beginning of a another Scene meme/cliche?

Anyway, great job! Not only did it have to fit on one side, but with the text and images at the start and end. Though if you could have waited ~4 weeks, submitting this to Nordlicht probably would have knocked their socks off. :)
rulez added on the 2014-06-29 10:04:58 by Starchaser Starchaser
OMG!! :-)
rulez added on the 2014-06-29 10:08:07 by blueghost blueghost
Good, good, let the video flow
rulez added on the 2014-06-29 10:14:45 by leGend leGend
*____________*
rulez added on the 2014-06-29 10:26:55 by sensenstahl sensenstahl
Awesome !
rulez added on the 2014-06-29 10:40:21 by Cyg_BLaBla Cyg_BLaBla
Awesome! Although I'd still like to see a cartridge version with more space....
rulez added on the 2014-06-29 10:57:57 by Harekiet Harekiet
Haha cool! I love the music to SID remake.
rulez added on the 2014-06-29 11:22:01 by Optimus Optimus
I thought that would be amazing for someone make this on amiga500. But on C64, that was incredible.
rulez added on the 2014-06-29 12:02:13 by stefa stefa
Amazing
rulez added on the 2014-06-29 12:03:04 by Buckethead Buckethead
Piggie for non-syncing audio (which is essential)
added on the 2014-06-29 12:03:45 by visy visy
love your work, even that I find this one to have too much artefacts to be 100% enjoyable (you've spoiled us already), but hey - it's a single sider!
and the SID version of the tune is awesome!!
respect!!!
rulez added on the 2014-06-29 12:25:20 by bonefish bonefish
A bit too blocky for my taste but still very enjoyable, great tune as well. Challenges are great fun and this is true demo spirit, thumbs up! :)
rulez added on the 2014-06-29 12:51:03 by StingRay StingRay
Tell us how you did it. Advanced humanity!
added on the 2014-06-29 13:16:03 by Gertrude Gertrude
Advanced=advance
added on the 2014-06-29 13:16:29 by Gertrude Gertrude
Now turn the disk and play the fucking game! :D
rulez added on the 2014-06-29 14:39:18 by Exin Exin
Awesome!
rulez added on the 2014-06-29 14:43:32 by Adok Adok
http://www.geocities.jp/submarine600/html/apple.html
/r ripping haters
added on the 2014-06-29 16:05:11 by g0blinish g0blinish
What StingRay said.
rulez added on the 2014-06-29 17:19:00 by Preacher Preacher
I was expecting a REU port, but streaming from a floppy.. yowza. The SID was cute.
rulez added on the 2014-06-29 17:50:29 by phoenix phoenix
Production and technical notes as below.

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 gfx 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.
added on the 2014-06-29 18:01:41 by algorithm algorithm
Great proof of concept! And I love technical write-ups, so an extra thumb up for that.
rulez added on the 2014-06-29 18:08:10 by Kylearan Kylearan
Quite impressive i have to say :)
rulez added on the 2014-06-29 18:21:26 by Sapphire Sapphire
Ugly as hell, but an impressive form of ugliness! You're compression master dear Mr Algorithm! bring us more! :D
I enjoyed the sid a lot!
rulez added on the 2014-06-29 18:47:07 by baah baah
Cool. Now add colors :)
rulez added on the 2014-06-29 18:47:45 by maytz maytz
I love bad apple and this is a gerat version <3 <3 <3
rulez added on the 2014-06-29 19:56:29 by nekomono nekomono
Algorithm: amazing! :) I watch again and again the original and yours (under vice). My favorite part of the animation is when the girl fall and start running around 2:55 in the video as the movement make it feel very alive.

you know, I will be curious to know what can be done using a C128... the disk drive can read both sides (1328 blocs per disk). The CPU can be set to 2Mhz, but you will lose the VIC-II chip.. there is another video mode (80 columns) with higher resolution. I don't know if the charset can be re-program and if your code could be ported...

when thinking about compression, sometime we can dream big... Could the song be compress as well as the video on C128?
rulez added on the 2014-06-29 21:16:38 by F-Cycles F-Cycles
F cycles. Thanks. The next demo will have a part which has full digitized video and audio streaming from disk on stock c64. (But I will resort to panning and zooming some of the frames)
added on the 2014-06-29 21:29:49 by algorithm algorithm
seems like its the time of custom streaming video techniques for slow computers.
rulez added on the 2014-06-30 00:59:37 by wysiwtf wysiwtf
Great prod !
rulez added on the 2014-06-30 08:03:33 by stf stf
Wow!
rulez added on the 2014-06-30 10:56:16 by Cubed Cubed
Amazing!!! Great!!! :)
rulez added on the 2014-06-30 11:18:49 by Sir_Lucas Sir_Lucas
It's an achievement esp. in compression, but mebbe some more fidelity in exchange to filesize would have been more viewer friendly?
added on the 2014-06-30 11:53:41 by Marq Marq
awesome technical prod, as usual with Algorithm :D
rulez added on the 2014-06-30 17:49:04 by rez rez
I would have liked to increase the fidelity, but the challenge was to fit everything to a single side on floppy and include the whole animation at 12fps. Quality could have been increased if I had modified the first section of the encoder to perform genetic selection and hill climbing however.
added on the 2014-06-30 18:56:57 by algorithm algorithm
Algorithm: I did not expect to see this prod. coming out after releasing Eclectic, within the same month! How many prod. do you usually plan/do per year? Have any specific dates you target or you go as things goes?
added on the 2014-06-30 19:19:38 by F-Cycles F-Cycles
F-cycles. Normally the result of a few demo parts is due to experimentation. This particular demo was put together one evening on the c64 (with the encoding of the data the evening before)

I am working on another multipart demo, although there are no specific target dates. This demo just did not "feel right" to be included with the new multidisc side demo, hence released on its own
added on the 2014-06-30 19:32:42 by algorithm algorithm
Impressive
rulez added on the 2014-06-30 20:13:41 by Tjoppen Tjoppen
Looks like crap, and a fucking SID remake instead of the soundtrack? Massive thumbdown -- "Make It Smooth Or Don't Make It At All".
sucks added on the 2014-06-30 23:10:42 by Hoild Hoild
Dude, did you pay for the demo? This is a c64 running the animation from a floppy with 170k of gfx data, not a pc or amiga streaming it from a harddrive. Anyway, enough ranting from me, small minded idiots who will never in their lifetime be able to code anything decent seem to behave this way... Write all you want, Just felt that I had to say something here just once to respond. You are the only one here that had given extremely negative remarks not taking in to accounts the limitations of the c64, while everyone else has praised this.. Wow, you must be some type of amazing coder :-) Go do something else non-scene wise with your small brain :-)
added on the 2014-06-30 23:31:27 by algorithm algorithm
I'm kind of astonished that one can fit about 10secs of video into a set of 256 16x16 blocks. This is likely due to the fact that the orig video has low entropy (i.e. is quite "simple", lots of redundancy). On other videos the compression would'nt produce so nice a result.

Anyway this is a real achievement. Congrats to the coder! Thumb Up.
rulez added on the 2014-07-01 00:42:09 by __sam__ __sam__
hum 256 16x16 is not exact. Please read
==> "10secs of video could be defined using at most 256 different 16x16 patterns" is more accurage
added on the 2014-07-01 00:49:02 by __sam__ __sam__
Its actually slightly more different. there are 128000 cells in 128 frames (320x200) this is condensed to 256 8x8 cells, but furthermore to achieve even higher compression, there is a predefined 1k table lookup that has combinations of these 8x8 cells to form a large 16x16 pixel block (hence no total freedom on which cells can occur at any point on the screen (apart from the clustered 16x16 pixel cells) This gives an additional 4:1 compression rate on the lookup display (to 240 bytes - instead of 1000 bytes) - After delta (due to the extreme simplicity of the video data) this normally packs each frame to around 60-70 bytes or so (in combination with lz encode)
added on the 2014-07-01 00:53:29 by algorithm algorithm
Who the fucks care about how good u can compress this shit when it looks like shit.
sucks added on the 2014-07-01 01:13:34 by Zplex Zplex
attitude!
rulez added on the 2014-07-01 01:18:14 by gentleman gentleman
Hehehe. Nice to see people get angry
added on the 2014-07-01 01:18:56 by algorithm algorithm
Angry people are probably jealous. :D

How long did it take to compress the whole 2200 frames ?
added on the 2014-07-01 08:30:00 by __sam__ __sam__
Nice proof of concept! There's also a megadrive version, but this is 8 MB and not 170 KB: http://www.youtube.com/watch?v=2vPe452cegU
rulez added on the 2014-07-01 12:34:09 by Kabuto Kabuto
This time with clickable link: http://www.youtube.com/watch?v=2vPe452cegU
added on the 2014-07-01 12:34:37 by Kabuto Kabuto
Algorithm: I read the comments and I do feel also bad for some of them related to your works. Well, if you look to any kind of productions on social media (youtube, ...), there is always a ~10% which is doing a big thumb down. So, it`s a good sign when you have a couple of people giving bad critics, that's mean your production get higher viewers! ;) It`s better to have 100 comments, 10 000 views and 10% thumb down then 100% thumb up, but only 50 views. ;)

if I was still involve on gp2x... I will like try to make a bad apple version on it.. ;) but will probably be 200kb just the executable before I add the data.. as I never work to shrink down the executable/music lib...
added on the 2014-07-01 16:27:42 by F-Cycles F-Cycles
Sam, the actual encoding was a multiple stage process with the first process taking the longest (due to using a very early 16x16 tile encoder). Overall took a few hours for all frames (although 90% of this was saving individual bitmaps generated from the encoder.. i know i know, too lazy to code multiple stream saving, but not lazy to save thousands of frames :-)

F-cycles. I know, I should have just left it as it is, besides ignoring these type of creatures is better, but felt I should at least say something once and not say it again after I am all for drama :-) bring it on :-)

Kabuto, yes, i saw the megadrive version very very nice and not many artifacts, but what may be ok for megadrive 8mb would be disastrous on stock c64 (would require nearly 20 c64 disks double sided) :-) and could not keep up with the data rate. Reu would be an option, but i am against non-stock hardware
added on the 2014-07-01 17:05:12 by algorithm algorithm
Thanks for the explanation. Only a few hours spend in pre-processing. I'd thought it would require days (GPU used maybe ?).

Is the genetic selection strategy for finding the optimum tiles better than other clustering methods ? I'm thinking about k-medians or k-means clustering for bit vectors: the tiles being considered as a binary vector. Does it produces better results? Is it faster? or is it simply easier to code?
added on the 2014-07-01 17:44:05 by __sam__ __sam__
I have experimented in many clustering methods and ultimately released one of my tools (CSAM Super) that uses the genetic / hill climbing methods

Example of some of its functions here..

https://www.youtube.com/watch?v=-jSUS4nBaqE

The main core of the encoder is in assembler and uses 4 cores utilising "lazy error updates" which increase the encoding speed greatly without GPU.

Unfortunately the 16x16 tile method is encoded using traditional LBG (and pruning codebook selection) hence quality in the first encode step is a lot worse than it should have been. I would have estimated twice the quality increase if I had got around to recoding this to use my new method of clustering.

Based on tests, the genetic/hill climbing method does result in higher quality than ELBG (Enhanced LBG) and even more so when utilising the weighting options to target regions of interest.

Furthermore unlike the traditional LBG/ELBG cluster blocks are not snapped and clustered in fixed area's, they can traverse using single pixels or 4x4, 8x4 chunks in the source merging into specific area's of the 8x8 block codevectors.
added on the 2014-07-01 21:30:05 by algorithm algorithm
Great compression! Love it.
rulez added on the 2014-07-01 21:33:44 by ilmenit ilmenit
nice work.
rulez added on the 2014-07-01 21:40:58 by iks iks
"CSAM Super" looks great. I should have known: everything that contains SAM in its name works great :) I will give it a try. Is it specifically tuned for the C64? or is it possible to customize it for other machines ?
added on the 2014-07-01 22:55:45 by __sam__ __sam__
It is specifically for the c64 when using the conversion and compression sections in the encoder, however there is the option to save the codebook or converted frame sequences as bitmap streams before it is converted to c64 format)

You can then create a simple program that reads and stores different 8x8 char data in the bitmap streams and then remap into Lookup data.

Some types of customizations are possible (such as reducing codevector amount) e.g I believe atari800 has a tile limit of 128. Unfortunately at this stage, the encoder only operates on images that are 320x200 in size as well as using 8x8 pixels (rather than 2x2,4x4 etc) Although the encoder does map over small chunks (e.g 4x4) to specific areas of the 8x8 codevectors to reduce error when required.
added on the 2014-07-01 23:10:58 by algorithm algorithm
Actually to come to think of it, You can save the codebook as bitmap, then use the "convert studio" option, select any mode and then save raw LUT. The codebook saving can be ignored (and you can use the original codebook that was saved in the main gui instead)

However selecting the compression studio module does remap and optimize blocks, hence do not use this option as the codebook order and LUT's wont match the original saved codebook
added on the 2014-07-01 23:13:20 by algorithm algorithm
Not bad. :)
added on the 2014-07-05 16:58:11 by AntDude AntDude
o_O Impressive!
rulez added on the 2014-07-06 23:44:55 by mke mke
Bad Apple confirmed for standardized crazy-ass video encoding / decoding test clip.
rulez added on the 2014-07-11 10:12:25 by Trilkk Trilkk
Too blocky/many artifacts for me to really be able to enjoy it. Appreciate the effort and hard work though!
added on the 2014-07-13 00:08:39 by Daniel Daniel
Very impressive!
rulez added on the 2014-07-16 17:36:04 by neptun neptun
I can't really say i like the video being "covered" here very much, but technically, this is extremely impressive!
rulez added on the 2014-07-16 19:03:05 by Paranoid Paranoid
I didn't mind the artifacts much, I actually found them to add their own "style" to the visuals. Very impressive, good sir!
rulez added on the 2014-07-23 19:58:31 by dojoe dojoe
Oh, and extra BB Image for the writeup!
added on the 2014-07-23 19:59:32 by dojoe dojoe
Liked the video back when it was a meme, the remake just loses too much when the sync is gone and you can't really see what's happening. I mean it looks *really* bad, which is of course due to the extreme compression that won you the bet.
added on the 2014-07-25 23:01:50 by Photon Photon
Gaahh, super!
rulez added on the 2014-07-28 22:07:04 by Emod Emod
Generally I'm not especially impressed by the Bad Apple.
But playing it from a floppy on real hardware changes everything.
Algorithm has provided another coding-masterpiece production.
Music sounds very pleasant and not much different from original. And introduction gives very positive mood.
rulez added on the 2014-09-28 20:24:32 by zbyndek zbyndek
Kool!
rulez added on the 2014-11-22 01:01:34 by lennart lennart
WoW, you did it. A great way to use the driving disk properly without hesitation or bugs. Excellent. I like this better than soundrecordings.
rulez added on the 2014-12-08 11:08:02 by w00t! w00t!
Impressive! Thanks for the writeup.
Soundtrack sounds nice to me, definitely the best SID version that I've heard so far.
rulez added on the 2015-02-14 22:33:06 by PotcFdk PotcFdk
What? I didn't thumb this yet? The Soundtrack alone is enough for thumbing this one up
rulez added on the 2015-02-14 22:54:20 by Triace Triace
:)
rulez added on the 2017-03-25 19:41:52 by Frequent Frequent
quite an achievement
rulez added on the 2017-04-02 17:23:51 by v3nom v3nom
It's a pity the animation is so horribly scarred by the compression used, but hats off to the challenge.
rulez added on the 2017-04-02 18:44:53 by Zavie Zavie

submit changes

if this prod is a fake, some info is false or the download link is broken,

do not post about it in the comments, it will get lost.

instead, click here !

[previous edits]

add a comment