pouët.net

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!

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.

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)

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.

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

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 :-)

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)

Hehehe. Nice to see people get angry

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

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.

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.

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