|
DUCK.3JS.2K by Knox [web]
[nfo]
|
||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
|||||||||
|
popularity : 60% |
|||||||||
alltime top: #5246 |
|
|||||||||
added on the 2011-01-24 14:33:54 by knox  |
||||||||||
popularity helper
comments
This was supposed to be a simple compression test but I ended up squeezing it some more to have it fit in 2K. It's the same anatidae than in the original DUCK.3JS by Wurst, except it's now twice as small. There are some technical details in the NFO for those interested. Should work on all recent browsers except IE. Disclaimer: no duck was harmed during the compression process.
added on the 2011-01-24 14:36:21 by knox
Pretty neat in 2k.
nice
There it is :)
Nice.
Now fix the holes.
Now fix the holes.
Nice.
very sweet tricks ... who's next to break this record?
I like
Very nice :)
INSTANT THUMB! <3
Nice deflate friendly code and optimization of the model.
Nice one!
Online version works in latest Firefox and Opera. Offline version works in Opera, but in Firefox only some long horizontal line is displayed.
Would be good to have offline version of 2k-tris.
Would be good to have offline version of 2k-tris.
Unofficial DUCK.3JS Size compo at Revision anyone?
Is this harder or easier than dots?
.
Ha! Nice job!! A classic!
quack!
DUCK.3DS
nice duck
new worldrecords don't have to be ugly... =)
would have been a cool 256b :p jk, great work. using grayscale png file for compression is an interesting idea.
I'm feeling ducky!
for exploiting the png format and all that..
.
Skate, toxie: The PNG trick is at least 2.5 years old. Here, it's nicely used to pack the code AND the data.
However, for small prods, the PNG compression trick is not always the most efficient. i.e the code of 3D Tomb II goes from 3.1 Kb unpacked to 2.6 Kb packed as PNG vs 2.2 Kb packed in JS.
However, for small prods, the PNG compression trick is not always the most efficient. i.e the code of 3D Tomb II goes from 3.1 Kb unpacked to 2.6 Kb packed as PNG vs 2.2 Kb packed in JS.
nice ducky
p01: Was the PNG for 3D Tomb II really optimized? I did a quick test on the 3D Tomb code which went from 3271 bytes for unpacked JS to 1658 bytes for the whole PNG file. That's just slightly above 50%.
BTW: the PNG used for the Mario example contains two useless chunks. There's some text ("Software Adobe Image Ready") and a pretty big palette of about 400 bytes. That's no big deal for a large original file but it becomes -- of course -- unacceptable for a small one.
BTW: the PNG used for the Mario example contains two useless chunks. There's some text ("Software Adobe Image Ready") and a pretty big palette of about 400 bytes. That's no big deal for a large original file but it becomes -- of course -- unacceptable for a small one.
.
knox: Doh, I forgot Jacob Seidelin hadn't optimized ( using pngcrush and the likes ) those PNG :p
With my (WIP) JS packer, 3D Tomb II's code is more like 2 Kb.
With my (WIP) JS packer, 3D Tomb II's code is more like 2 Kb.
Definitely rulez.
Which tool and what settings do you use for PNG encoding/crunching?
Which tool and what settings do you use for PNG encoding/crunching?
chudik: I just wrote a quick and dirty PHP script. In order to save precious bytes, an important thing is to generate a native 8-bit grayscale PNG file (Color Type = 0 / Bit Depth = 8) with no palette information at all (i.e. no PLTE chunk). I was not able to do that with the native PHP functions, so I had to build it "manually" -- which is still quite easy.
oh ... (sniff) ... it's ... it's .... (sniffsniff) A DUCK! A FUCKING DUCK! MY ASS THIS IS COOL!
Amazing.
MagikGimp :)
ducks are always welcome!
duck!
*quack quack ^_^*
Nice. Ernie's rubber duckie?
thumbs up for duck. your polyfiller is not accurate though.
fast!
DUCK.3DS!
lists containing this prod
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 !