pouët.net

algorithm information 172 glöps

• general:
• level: user
• personal:
• first name: Naveed
• last name: Khugiani

• demo Commodore 64 Bad Apple 64
• 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
• isokadded on the 2014-06-30 19:32:42
• demo Commodore 64 Bad Apple 64
• 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.
• isokadded on the 2014-06-30 18:56:57
• demo Commodore 64 Bad Apple 64
• 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)
• isokadded on the 2014-06-29 21:29:49
• demo Commodore 64 Bad Apple 64
• 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.
• isokadded on the 2014-06-29 18:01:41
• demo Commodore 64 Bad Apple 64
• 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!
• isokadded on the 2014-06-29 08:12:10
• demo Commodore 64 Eclectic by Onslaught [web]
• Next demo is in the works now... 3 minutes of full digitized audio/video with full seamless streaming. And Sandra again... (Different track however)
• isokadded on the 2014-06-21 01:29:53
• demo Commodore 64 Eclectic by Onslaught [web]
• Ok, here is the youtube video that I have promised.
  
  Youtube does not support 50hz hence the motion will be more jerky on this video, however I have used motion blending to somewhat recreate the interlaced representation of how it would look on a c64 and medium phosphor crt (crudely)
  
  https://www.youtube.com/watch?v=yW5v93P-gBw&feature=youtu.be
• isokadded on the 2014-06-10 21:32:00
• demo Commodore 64 Eclectic by Onslaught [web]
• @F-cycles. The framerate of the youtube capture that i posted was recorded via camtasia recorder on my desktop pc from a stream where a lot of frames were dropping. Additionally the youtube conversion probably would cause even more issues.
  
  Most of the parts make use of full 50fps update (whether this is due to interlacing or update of screen contents every frame)
  
  I have seen a few youtube encodes which look horrible as they miss every other frame (this destroys the image completely in the intro, titlepic, 3d animation, yflip, kraftwerk part, turndisk, flower pic...
  
  You can always download the Vice Emulator (v2.4 recommended) and run the demo from there (although again, for optimum viewing on emulator, the display needs to be at 50hz (and even then there will be stutter) and pal emulation activated.
  
  As for the tune on side 1. My fault, i could have lengthened the song to make it less repetetive but time constraints... (excuses excuses :-) )
  
  Youtube encode to follow today (will look better for interlaced parts, but again, framerate will be chopped due to youtube not supporting 50fps)
• isokadded on the 2014-06-10 14:22:01
• demo Commodore 64 Eclectic by Onslaught [web]
• Thanks all for the comments.
  
  It really needs to be viewed on a real c64 to benefit. This is due to many of the parts operating in color/pixel interlaced mode. Youtube breaks this up somewhat.
  
  I do have a youtube encode where i am performing temporal frame merging which gives a more 'authentic' experience which will be uploaded at some time this week.
  
  The live version is ok for a brief preview and atmosphere of the party however it seems that it has sync issues when sideborder modes are used (notice the glitch when the pictures in the title page and composite mode are fadedout) as well as the twist circle sequence which has the annoying red strip on the left.
  
  Regarding boobs.. Only one part (the intro) has a quick glimpse - which is mainly too exposed in brightness to even see
  
  My parts of the demo was rushed quite a fair bit (Blame laziness as well as coding pc encoders for this) 5% coding on c64, 80% laziness/work/reallife and 15% pc encoding.
  
  I would have done things a lot differently now looking at the parts. The end digi part is streaming but not 'proper' streaming as in audio video chunks interleaved and loaded from disk. The audio and other gfx data is loaded as and when needed with the main animation part compressed in memory already.
  
  The kraftwerk part is a demonstration of a decoding process that can generate decent quality, but can be improved immensely by only a few additional bits of data per chunk (via backwards traversal as well as amplitude update)
  
  The other parts such as the Y flipping pictures and distorters/tunnel are real time but the latter two also make heavy use of precalculated data (strips of varying data) or offsets into frame which are calculated per frame and decoded per frame.
  
  The Sideborder gfx modes allow approximately 70 colors at 184x200 resolution with minimal flicker. The latter flower picture has had the encoder tweaked to look 'better' on composite display taking into account the chroma spikes.
  
  The end digi part also utilises filter/d418 method this unfortunately means that quality will vary on different c64's (even with the same sid model) Autodetection of sid at the beginning attempts to ensure that there will not be too much of a dramatic reduction in quality.
  
  Sonics tune is indeed a masterpiece, but 8580 only to benefit from the quality.
  
  Watch out for something quite special next time..:-)
• isokadded on the 2014-06-09 17:24:44
• demo Commodore 64 FRODIGI - Free Running Oscillator Digi
• Thanks all for the comments.
  
  The encoder specifically encodes each chunk for 50fps update (A sample at 44100hz would be equivelant to around 883 bytes.
  
  As the oscillators are free running, the decoder may start waveforms from an unknown point per frame (While the encoder internally trys to find best sliding matches for each channel internally). This can be somewhat rectified if taking into account cycle exact writing in the decode and configuring the encoder to take this into account as well as saving the last state of the waveform position
  
  This error is recognisable even more when there are more updates per frame unfortunately.
  
  You would have noticed that there are less low frequencies on the audio. This is deliberate, as the error audibility is more on low frequency waveforms. Higher frequency data overlaps more occasionally with the other channels to reduce the error somewhat.
  
  A brief technical insight into the routine as follows
  
  An index into the predefined frequencies and waveforms for the three channels and a master volume are randomly selected initially
  
  the "wavemerger" performs the calculations required and this is compared with the source audio chunk. In essence, this finds the error based on the three waveforms, frequencies and optimal offsets
  
  A multishot-hill climbing method is used to reduce the error and to find a more optimal match. approximately 10,000 iterations are used and frequency data saved. the process is repeated for each shot, and the best final result is used.
  
  This selection of data is passed onto the next generation where further tweaks are made
  
  Without changing the encoder, improvement in quality can be made by using more note-tables. I chose to use notetables in order to provide the necessary compression as this uses 31 bits per frame (9bitsx3 channels+master volume for chunk)
  
  By utilising for example 4096 note tables, it would increase quality rather more and use 40 bits only per frame.
• isokadded on the 2014-05-28 13:09:51