algorithm information 167 glöps
- general:
- level: user
- personal:
- first name: Naveed
- last name: Khugiani
- demo Commodore 64 Frodigi 7 by Algotech
- @tonyrocks. Interesting. Can you let me know whether you have a PAL or NTSC C64?
@Tjoppen. A lot of sacrifices were required to get it to actually run on a c64. Bear in mind that it is mixing 6 channels digitally with seperate amplitude and frequency per channel many thousands of times per second on a <1mhz c64. Most of the artifacts you can hear are due to the shortcuts in mixing and adjusting amplitude as well as minimizing ram requirements by using lower resolution for amplitudes to allow it to run in realtime and not an artefact of the encoder itself (Although indeed, there is still a lot of room for improvement).
Would be interested in hearing some codec2 audio examples at (1.6kbs) Music, not speech. Can only seem to find speech only examples at 2.4kbs or so. - isokadded on the 2017-01-09 23:29:42
- demo Commodore 64 Algo Dreams by Algotech
- for details about the parts, read the note on disk 1, side1. If running this on an emulator such as vice, make sure you select resid 8580. Using fastsid will not work and digitized audio will be degraded significantly.
- isokadded on the 2016-11-13 22:24:10
- game Amstrad CPC Imperial Mahjong by Arkos [web] & Les Sucres en Morceaux [web]
- Oh, and congrats on the neat mode! :-)
- rulezadded on the 2016-10-18 23:27:23
- game Amstrad CPC Imperial Mahjong by Arkos [web] & Les Sucres en Morceaux [web]
- the one above used less tolerent luma difference boundaries which generated more flicker. Flicker could have been reduced further by propogating pixels in each field although to freely do this would require same color definitions per field. The method above alternates lines which reduces flicker but not to a satisfactory amount.
- isokadded on the 2016-10-18 23:27:01
- game Amstrad CPC Imperial Mahjong by Arkos [web] & Les Sucres en Morceaux [web]
- Works very well. congratulations on this. I did something similar in the concept of having alternating hires and multicolor per line on the c64 some time ago, but utilised color interlacing so that multicolor blocks would mix in together with the hires blocks. first frame would have hires,mcol,hires.. and second one would be mcol,hires,mcol... each line.
Mixed screengrab below
- isokadded on the 2016-10-17 21:39:32
- demo Amiga OCS/ECS 9 Fingers by Spaceballs [web]
- What Hannibal said. At the time of production, Lonestarr had created a vector tracer working with more than just a single shade. Worked well and i believe he sold the technology/encoder for quite a lot of money at the time.
- rulezadded on the 2016-09-26 20:00:02
- demotool musicdisk ZX Spectrum fluidcore by Irrlicht Project [web]
- Very nice and innovative. Something similar has been done before by Tim follin in some of the early games https://www.youtube.com/watch?v=Vy0umg4ZuUY
The fluidcore one is obviously far more impressive. - rulezadded on the 2016-03-05 11:45:44
- demo Commodore 64 50 bytes of Sylvia by Algotech
- If you read the description that I had posted previously here, its not just VQ. It is combined with a tile cluster former that gives the dramatic size reduction.
(packs a 1k VQ frame into 60 bytes) followed by delta packing which results in approx. 30 bytes per frame. Combined with the gfx data spread out across frames, this gives the 50 bytes per frame.
Without using the above two methods and just placing a 8x8 size image (Just over 60 bytes) to fit the screen it would look utter-crapx100 instead of crap :-)
Ofcourse with some additional post processing, the quality using even the same source packed data could have been improved (but I wanted fast frame update and the loader to keep up with the frames) - isokadded on the 2016-02-12 22:53:42
- demo Commodore 64 50 bytes of Sylvia by Algotech
- For the curious, here are some production notes..
The video is encoded in 256 frame chunks
each chunk has its own codebook, multiple block lookups and frame-data
In order to minimize error during the first pass, A DCT transform is used which performs more efficient clustering and merging to a single character set.
Without the DCT, ideally would require many more charsets to achieve the same visual quality after quantization. Data is merged, parts of it are merged and replaced to minimize error via hill climbing methods
This data is then fed through a multiple block clustering encoder which reduces the size of each frame by a factor of 16 (from 1k down to 60 bytes).
Fuzzy matching is used in order to perform more efficient matches.
This then results in a 4k table consisting of 256 tile lookups (each taking 16 bytes of data) to block plot 4x4 chars for each lookup
Delta packing is used between each frame via 8 byte bit-table which skips or plots the tile cluster. This further reduces the size down to on average 30 bytes or so.
Including the 4k lookup tables and 2k codebook spread across the 256 frames, this gives the average total of each frame as 50 bytes.
The c64 side of the decoder is far trivial in comparison to the encoder.
Unrolled delta de-packer is used which can de-pack a frame of data from the packed source using around 10 raster-lines to around 135 or so dependent on frame difference.
Unsurprisingly the decode output is rather blocky in nature at this low file-size. I opted to use a noise overlay in order to reduce this. (This of course gives a fuzzy severely out of tune TV look, but I felt it also gave it more of a original feel to the demo)
Sprites are pointed to the packed data and changed and multiplexed over the whole screen via nmi interrupt. This also updates d016 registers multiple times at semi-random points in the image to distort it
The packed 256 frame data is loaded from disk while the previous 256 are played back, resulting in a continuous stream of 2048 frames.
There was still ample space left on the disk, (enough for another 600 frames or so) or more if using 40 tracks and no intro
The demo is more a demonstration of the encoder rather than the decoder and merit should be given to what it achieves at that low file size (rather than the output quality) :-)
On a more powerful machine, some more sophisticated de-blocking can be used to improve the output quality a lot. I was considering using bitmap mode for the c64 decoder and de-blocking in software, but that would have caused quite a hit to the frame-rate or/and loader being able to keep up with the constant unique frames..
For those not liking the noise, set d015 to $0 if using vice monitor for example (while main demo part is running) - isokadded on the 2016-02-02 17:54:45
- demo Commodore 64 Sampleblaster by Algotech
- The SSDPCM-MP was previously introduced in one of my Amiga demo's here
http://www.pouet.net/prod.php?which=65976
It is exactly the same method (only at a lower sampling rate)
Optimal dual step sizes are chosen for a given small chunk area of samples and these are quantised together with the bit patterns. They are recreated by addition and subtraction using the chosen step sizes.
As there are different step sizes for each given chunk, The audio is recreated rather accurately.
In order to process all this data in realtime on a C64, i have used codetables to optimally decode bitpatterns directly which gives a considerable speedup.
The animation is also 200 frames using VQ and then converted to 2x2 tiles for further packrate and then tile definitions delta encoded. All this has to be done in reverse (and in 16fps in this demo)
All the above using 90% cpu time is too much, hence had to be optimised to overall use far less (60-70% or so on average) in order to allow the loader to be able to have time to load the data.
In regards to sequence based loading. There are four slots and the program will load the relevant packed sample to one of these slots while decoding a sequence from another. This is continued with the data being loaded into the relevant slots and played back. - isokadded on the 2015-12-23 11:56:27
account created on the 2011-01-25 21:59:22