|
| |
Credits :
Download :
Look for downloads on external sites:
Pokefinder.org
User Comment
Submitted by BiGFooT on 7 February 2015
Sorry, but i'm still not impressed.
Let's see a real use case. At the doynamite topic (Doynamite 1.x) you can found a pretty good comparison table by ChristopherJam.
In this particular calculation I used file #6 with a pretty much optimized depacker of your algorithm (or at least I think it should work). Here is the result: http://bigfootinformatika.hu/x/opted.lst
The cycle counting was a bit lazy and mostly permissive (as I splitted the pointer table and didn't care page boundaries and rest). There's room for further optimization (2 cycles / byte without cpx and dex) but that requires reversed reference table.
So with this the result was 43 frame and 229 rasterlines. With the mentioned optimalization you can go down to around 39 frames.
Compared to the packer/depacker what I use it's 1.35x slower (32 frame and 97 rasterline).
Compared to LZWVL the result is worser as LZWVL is much faster (25 frame) but the resulting stream is a bit bigger.
We should compare to file #5 if you want but i'm sure you can't beat the same 39 frame by LZWVL and my packed/depacker as it's filesize is bigger.
Look around next time Sokrates, there's no such thing as 0 decompression time. Of course decompression should be fast but you need to do it better to beat others tools.
And yes, I appreciate your idea (really!) but I don't like if someone state something what's not valid. |
User Comment
Submitted by Sokrates on 5 February 2015
> so afterall some delta must be in
>there hence '0' decompression time ?
No. No delta compression. That would consume time :-)
>btw why did you think a very low fps
>animation player can demonstrate fast
>decompression ? make it 50fps or smth :)
Good point. No, not anymore :-) I just liked the idea to have a short movie... |
User Comment
Submitted by Oswald on 5 February 2015
| so afterall some delta must be in there hence '0' decompression time ? btw why did you think a very low fps animation player can demonstrate fast decompression ? make it 50fps or smth :) |
User Comment
Submitted by Sokrates on 5 February 2015
I see now that this demo was probably not the best way to introduce
the new compression method. The interesting part is yery well hidden
between less interesting parts. I'll try to sort things out with
some pseudo code. The demo looks like this:
a) ALZ64. Output: uncompressed code+data
nextImageLoop:
b) New compression method. Output: RLE compressed data
c) Run-length compression. Output: uncompressed image
d) Show immage on screen
Goto nextImageLoop
To:
a) ALZ64 was not developed by me, so it is out of scope.
This is NOT the interesting part of the demo!
c) Standard RLE. I made the slightly ironic comment about RLE
and rocket science to point out that this is nothing special,
nothing new.
This is NOT the interesting part of the demo!
d) Draw image pixel by pixel. This is slow and not optimized.
This is NOT the interesting part of the demo!
So your focus of the demo should be on:
b) This new compression method.
This IS the interesting part of the demo!
This new compression method is not the best in terms of
compression ratio. But it is the best in uncompression time.
For a normal use case it takes zero (!) time to uncompress
an data array. For very special cases it's even faster, but
that's another story :-)
If you need a good compression ratio and the used decompression
is fast enough for your use case: stick to the existing methods.
If you need some extra kilo bytes during the runtime of your
game or demo effect: consider this one.
@BiGFooT: so by just focus on the part: would you consider
zero uncompression time "ubercool"?
I hope this helps to clarify things. |
User Comment
Submitted by BiGFooT on 4 February 2015
Oh well... Sorry mate, but it's neither rocket science nor good stuff from my point of view.
First of all: this packing only good for 1bpp images so it's pretty limited.
Also, the packing could be better. I was able to achieve a bit better compression without too much effort with the same "RLE technique" and "my" self-written compression method and it's fits with exomizer too. See here: http://bigfootinformatika.hu/x/steamer_exo.prg
Of course, your pixel routine could be better too, your code isn't optimized, etc. Anyway, there's faster (de)packing algorithms available in the wild which also used for depacking animation with 12.5fps and not 4.
Sokrates, I don't want to blame you don't misunderstood me, just what you think is "ubercool" is a big disappointment for me. |
User Comment
Submitted by Dr.j on 4 February 2015
| very good efforts on this one |
User Comment
Submitted by Sokrates on 3 February 2015
Au contraire Oswald: The Run-length encoding you mentioned IS rocket science.
For the construction of rockets old techniques are prefered which have
proofed their reliability. RLE is such an technique :-)
The demo is slow because RLE is used for drawing 4000 pixels one by one.
The new compression method is used to uncompress the data for the RLE part
- see point 2) in production notes.
THIS method is the fast one. In best case this method needs zero (!) cycles
to uncompress the data. That's what I claim to be best im market :-) In this
demo I went for a higher compression ratio resulting in 21,6 cycles average
for each uncompressed byte (this is close to the worst case time consumption
for this method which is 25,34 cycles per byte). Maybe some cycles can
still be saved by optimizing the code.
Drawback: the new method can only be applied for read-only arrays. |
User Comment
Submitted by Oswald on 3 February 2015
| 1 frame is 500 bytes of data, on average 137 bytes when the only data is the outlines doesnt sound like rocket science. depack speed.. several frames / new frame, doesnt seem speedy either. probably no delta is better here, because with it we're talking of 2 outlines in 1 frame instead of 1. |
User Comment
Submitted by BYB on 3 February 2015
User Comment
Submitted by Sokrates on 3 February 2015
| Yes his is a technical demonstration of a new compression method and not a normal demo. For this use case it took a couple of days calculation time to get the best result. |
User Comment
Submitted by PAL on 3 February 2015
| I guess this is on a tech plane where i am not? right? I see the anims and it is there but that do not give me anything like a thrill or something but I know in my heart that it was probably hard to create on the limited hardware we have,,, so thumbs up for the work you have done! |
User Comment
Submitted by The Phantom on 2 February 2015
2 minutes is right, wow. I was about to close Vice when the introduction screen came on.
For not having music, it's tolerable. Looks great in "warp" mode...
Have to give credit though.. This is all C/G, right? Can't imagine how time consuming this was... Would like to know though ;) |
User Comment
Submitted by Sokrates on 2 February 2015
Inspired by Algorithm's fantastic demo <a href="http://csdb.dk/release/?id=131628">Bad Apple 64</a>
here is my one-file version of Bad Apple!!.
Please be very, VERY patient - it takes about 2 minutes until the demo starts
(is this a new record? :-).
See production notes for details. |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
