pouët.net

@RareWtFailWhale: been there, done that. Doesn't pay off for 1k since you're not allowed to use external data.

How about if you store the PNG as a base64-encoded data: URL (or directly as a binary string, if you can trust the encoding not to get screwed), write it to canvas and read it back? :-)

I've tried it (the png compression), but good size optimized code doesn't compress good as gif or png (or zip or rar or whatever, since it is very entropic), and then if you have to base64 encode it, it occupies 1/3rd more. That without the png loading and png to string and execution code... so it is not worth at all. Well... maybe for a very concrete case of code... but for the most of the cases it doesn't look worthy.

For me the PNG thing was new. I just thought it was fitting in here.
Maybe it's of some use in ~4k if you can write a size-optimized loader...

@gasman: base64 makes is 1.33 times as large. The decoding script is ~200 bytes. I might make sense for larger things, like 64k's, but for the js1k it's useless.

A rotating 3D computer with 3D text saying "1K" on the monitor (1017 bytes):
http://luis.net/projects/1k/3d/

Originally planned to be a dataURI base64 encoded compressed SVG(z) in 690 bytes, unfortunately attempts to integrate it into the JS1k template failed:

• I tried base64 encoding the GZIPed SVG, but dataURI does not support content-encoding so thats a bust. (only works in Opera)
  


• I tried putting the SVG inside a getURL via flash actionscript (for it's flash compression), but security permissions do not allow getURL to dataURI from another dataURI, unless I dynamically embed it with allowAccess attributes, but there goes my bytes.

Here is early an prototype of a 700 byte SWF file containing the SVG
http://luis.net/projects/1k/3d/computer.swf

The 3D Model (2K wavefront OBJ quads)

hi there!

here's mine, http://js1k.com/demo/557 : retro demo style ;-)
we now only miss a good & tiny mod player in html5 (don't now if it will be possible, ...) & js/canvas will be really interesting for portable demos!

I'd love to see a "second reality js/canvas" remix :-)

Luis, it is cool, but I'm absolutely sure you can squeeze at least 150 bytes from it. With these, you could probably make the rendering flat instead of wireframe, and, it would look much more interesting -- at least for me.

I've been following this thread in awe. Too bad i can't contribute :)
Keep it up - great work!

http://jsspeccy.zxdemo.org/jsmodplayer/

Relies on a currently-Mozilla-only API or a Flash fallback, though.

btw gasman, fyi, i've had great trouble getting that one to work. only after many reloads and random clicks, i got it to play music in opera. no luck at all in chrome and firefox. any clue why?

hey gasman it looks promising!
however right now the requirements seem really high...
do you think that html5 audio api will provide what you need or will you have to rely on specific browsers api (like with firefox currently) ?

Still working/fighting/juggling between life, work and a second entry. I'm 200 bytes over the limit after compression. Need to make the code more packer friendly and cut down a few things ... or try something else :p

Luis: Neat. You should submit it.
yoyofr: Neat entry. But Pleaaaaase, no Second Reality JS.

btw, if some are interested, here's a slightly update & "twisted" version of my js entry http://yoyofr.blogspot.com/2010/08/javascript-canvas-fun.html. Source code visible in the page source.

Hmm, not sure. I would put up a test page for the underlying audio library to establish whether the problem in is there or in my code, but the Evoke partynet is a bit too wobbly right now to troubleshoot anything relating to reliable page loading... :-/

yoyofr: My impression is that the Mozilla API is going to be (or possibly already has been) submitted for inclusion in HTML5.

+1 about Mozilla submitting their Audio Data API for standardization. See the W3C Audio Incubator Group

yaaaaay \o/

My new 1KJS entry! :)

http://js1k.com/demo/704

Raymarching with distance fields stuff :)

Fast on Chrome and Opera.
Very slow on Firefox, eval() optimization problem?
To run fast on Firefox change eval(X) at the end of the script to document.write("<script>",X,"<\/script>")

After optimizing the code to decrease the usage of garbage collection, the speed gain on Firefox was huge, on Chrome was already fast without this optimization, but all this speed gain on Firefox was lost after using eval() for compression :(

The first version, was fixed frame rate using dynamic resolution change, but no space left in 1K to put that, so fixed resolution.

Nice.

Cool! Runs fast on safari too.

paulofalcao, it rules!

paulofalcao: works great! ;) <3

Pretty cool indeed!

nice