In December I bought a chromebook. I really love it. It’s quick and simple. However, it does have some stuff to get used to. One of the things is, it’s hard to develop websites with it. During a hackathon at Hyves (where I work) I really wanted to use my chromebook.

So I started looking for a web based editor. There are a couple and cloud9 looks really good. The only problem I have with it is that it doesn’t have an ‘offline’ version (eg. for developing on your local network). Nor can you work privately without paying them.

So I found an older project of Johan Ekenberg under GNU license. It covered the absolute basics. So I decided to take it.

First I started to (dirty) fix all PHP5 related issues, then I removed some features and the old table layout.
Then I added a file list, syntax highlighting (CodeMirror) and made the layout bigger, more usable. Right now I have a pretty stable version which is free to download under the GNU GPL license.

I’ve finally had some time to work on a project that renders fractals by repeatedly applying transformations to regular polygons. The code’s not in any state to release (and, sadly, probably will never be), but I did manage to get the kind of output I was hoping for. So, I’ve uploadeda sample to my Deviant Art page. The code is written in JavaScript and renders to the 2d canvas. This sample was rendered in Chrome in a few seconds.

storing all sprites in a string by encoding each pixel in a sprite in 2 bits and storing 6 bits in each character. Each 2 bit chunk can have one of these values: 0=CR/lF (end of line/start of next line in sprite), 1=transparent (do not draw but move to next pixel), 2 = color 1, 3 = color 2. The colors are chosen from a palette, which is a string containing a number of RGB colors encoded in 3 hex chars (‘fff’=white, ’000′=black, ‘f00′=red, etc…). Each sprite has an associated palette based on the number of the sprite. Most sprites use one of two palettes: a one color palette (‘fff’) for the background stars) or a two color palette (’999000′) for the cat’s face, paws and tail. A few other palettes are used for the poptart.

storing all sprite maps (meaning which sprites to draw where for each frame) in an array of 6 strings, one for each frame, by encoding each position and sprite number in 3 bits. The background stars are not included; their vertical position is based on their number, by multiplying the number of each star by a certain value. Their horizontal position is based on time, by multiplying the time by a certain value modulus the width of the image and adding a “random” value using the value of a different character from the sprites string for each star.

drawing squares instead of sprites to fill larger regions, as sprites need a lot more bytes to store when they get bigger then code to draw a single square does.

using one function for two purposes: to draw a specific sprite at a specific location using a specific palette on the canvas, or to draw a square at a specific location, with specific dimensions and a specific color on the canvas. The function will draw a sprite if there are only 4 arguments provided and a square if there are 5.

using a bit of math to offset multiple sprites based on which frame is being drawn and adding sprites to the sprite. This is done to have the individual sprite maps for each frame contain the same information as much as possible, which makes them easier to compress.

I assumed it would be easy to code this one in 1K, but it turned out that it was pretty hard to minimize my code.

I started with a large file that draw only the (animated) cat. This wasn’t optimized in any way: it used one big sprite for each frame, with each pixel being stored as byte containing a value 0-8, representing an index into a palette.

I then cut the cat into smaller individual sprites that I could reuse between frames (eg. the face is always the same, just at a different location). I stored a sprite mapping, meaning which sprite to draw where for each frame. I stored all this information in a string using values between 0-36 encoded using ‘[char] = [value].toString(36)” and read using “[value] = parseInt([char], 36)”.

I chose to give each sprite only two colors + transparent (3 values), so I can store each pixel in 2 bits (4 values) and use the unused value to signal ‘end of line’ and using ‘end of line’ twice for ‘end of sprite’. This meant I could store the entire sprite as 2 bit values. I encoded 3 of these 2 bit values per byte using “[char] = String.fromCharCode([values]+offset)” and red them using “[values] = [char].charCodeAt(0)-offset”.

I stored the values in the sprite maps as 3 bit values and encoded 2 of these 3 bit values per byte as well.

I wrote code that choses an ‘offset’ to use in encoding sprites/sprite maps that caused the resulting string to contain as many of the same bytes as the code, which allows better compression.

At this point I was down to ~1.2K compressed. By reusing code for two purposes (eg. the ‘f’ function) and rearranging/rewriting code to have it contain as many repeated strings as possible to allow better compression, I as able to get it down to ~1.01K.

Finally, I optimized my png compressor code to work together with the poptart cat code; eg. do not use ‘eval’ to run the decompressed code, which then uses setTimeout to start the animation, but use ‘setTimeout’ directly. This allowed me to squeeze everything into 1K.

Because manually editing 2/3 bit values stored in 8 bit characters + offset is impractical, and because some of the values where calculated rather than hand-picked. I wrote my development code to generate the final code and data automatically. This means I have a somewhat documented, readable version of the test container HTML and the actual JavaScript code. The test container will load the code, which will show the animation slowed down to 1 frame per second and output the final code below the animation. The final code is what I pumped through my to-be-released JsSfx png compressor.

Afterwards, I realized that there are a few ways in which I could have improved on the code by doing a few things differently:

Save data as unicode strings; this allows storing not 6 bits per byte, but (effectively) 16 per 2 bytes. This could reduce the size of the data by about 128 bytes, but would use more bytes to store the non-unicode characters outside of the strings.

Save each entry for each sprite map in a separate string, meaning store the x coordinates in one string, the y coordinates in another and the sprite number in a third. This should result in data that can be compressed better.

Use scaling for sprites to be able to draw the background, rainbow and body of poptart cat using sprites as well instead of separate code to draw squares. This would use less bytes than having code to draw the cat using both sprites and squares.

I’ve released my first Chrome Extension, which allows you to zoom certain HTML element to full window size. This is especially useful with embedded videos: where you can normally choose between watching as a tiny element embedded in a website or watching full screen, this extension gives you a third option: full window.
While viewing an element full window, you can resize the window and the element will be resized accordingly.

Over the past few weeks I created a new shellcode that uses the Microsoft Speech API to have the target computer say “You got pwned!” over the speakers. Needless to say, the practical applications are myriad, from impressing women in bars to expediting world peace. However, I expect that the most common application will be people impressing their friends with their 1337 hacker skills.

The size of the shellcode is 242 bytes (add 5 for stack alignment and 39 for EAT bypass). It has all the usual bells and whistles: OS/SP independent, null-free, optional stack alignment and EAT bypass and no register requires a specific value for it to run correctly.

In a previous post, I explained how you can manually optimize JavaScript for size and/or create self-extracting compressed script using JsSfx. Today I release an updated version of JsSfx, which compresses script to even smaller sizes than the previous version and, as far as I know, smaller sizes than any other JavaScript compressor.

JsSfx is designed for use in the demo scene, where people often create JavaScript demos in a very limited number of bytes (and often a power of 2, such as 256 bytes, 512 bytes, 1Kb, 4Kb, etc…). In August/September of 2010, a demo competition was held at js1k.com. Contestants were asked to submit JavaScript demos that were 1024 bytes or less in size. A few of the entries used compression to fit a larger script into 1k. One of the more complex entries, WOLF1k by p01, uses cowboy‘s packify to compress 1370 bytes of script into exactly 1024 bytes. To see how well JsSfx was doing, I tested JsSfx1.2 on the 1370 uncompressed bytes of WOLF1k and found it reduced it to 1031 bytes. Obviously, I needed to improve on that, so I came up with an improved decoder for JsSfx3. The latest version compresses WOLF1k to 1013 bytes in utf-8 and 986 bytes using ISO 8859-1 (aka. latin-1). However, it does take a while to find the best way to compress scripts. JsSfx3 was developed with size in mind and not speed: it takes a minute or two to compress scripts of a few kilobytes. Compressing large scripts such as jQuery is not practical: it would probably take days on a fast computer.

There’s another competition over at js1k.com at the moment, but unfortunately compression is not allowed this time. Peter van der Zee, who hosts the contest, seems to believe that using compression removes the need for “hand tuning” your script and that this removes the fun. I disagree and believe WOLF1k and my own Perlin Noise script prove that. Also, I can assure you that a lot of “hand tuning” went into JsSfx3.2.

Anyway, if you’re working on small JavaScript demos and would like to see how small you can get your script, please give the new version a try and let me know if it works for you!

Many people have asked me for the uncompressed source of my Perlin flames script. At first I though about keeping it private, so people would have to reverse engineer the compressed code. After all, reverse engineering is how I learned the majority of what I know about programming today. But I realized that not everybody may have time to waste on such efforts when I wanted to have a copy of the original source of WOLF1k and couldn’t be bothered to decode it myself. So, I’ve made the uncompressed source available here. This is the source after I manually optimized it for size and it doesn’t have any useful inline documentation: I found it much easier to memorize what each part of 1k of script does than continuously update documentation as I wrote it.

I still believe it is a good exercise to extract the source from the encoded version, as you learn a lot more that way, but I’ll leave that choose to you.