Up till now I’ve been using the file extension XZ for compressed XAML vectors (Xap, Zipped - chosen uncarefully). But someone was Googling on “XZ”, not finding what they expected because XZ stands for compressed archives under Unix. So from now on, I’ll be using the file extension “CVF”: Compressed Vector Format.

A few days further, I’ve been very busy testing my CVF technique with different images. As expected, these tests had different results. In some cases, it pays to use the vector compression technique over PNG-24 or PNG-8. In some cases, the result of the compression can be larger than a PNG-24 original. It all depends on how much detail the picture has, whether the subject of the image has hard or smooth edges, and which optimization choices you make. So sometimes it works fine, and other times it is the worst option.

But CVF can be an option. I had the most amazing result with the graphic for the vertical bar in the game Slengo. The playing field is bordered by thick blue lines. If the player pushes these thick borders, they will paralyze all enemies which are next to the border. An animation is played, making the border more elastic for a while. This animation is making the graphic for the vertical borders very large in size: 117Kb (PNG-24). Converting this image to a PNG-8 format results in 61Kb. Lastly; I have scanned the PNG-24 vertical bar graphic with Inkscape, saved XAML and converted it to CVF. The result file is 47Kb, which can be Winzipped to 24Kb, in the XAP file. Compared to the original 117Kb, this is a reduction of 79%. The vertical bar is one of the largest images in the game, so it sure counts for download time.

Now for clouds. I wanted a cloudy background for a new game I’ve been creating, and I wanted this the easy way.

So I took clouds from Brazil:

I removed the scene and cropped the image to get clouds in the sky and forming clouds at the horizon. I filtered the result to give it a little more atmosphere. The result:

The PNG-24 version is 59.2Kb. The PNG-8 version is 17Kb. I have traced the PNG-24 with Inkscape, saved XAML and converted to CVF, not paying much attention to optimization. The result CVF file is 82Kb, which may be Winzipped to 38Kb. So the CVF version is smaller than the PNG-24 version and larger than the PNG-8 version.

I decided to test both in my game. Opacity is set to 0.5, to let the sky-background influence the cloud’s appearance.

Image above: The CVF-clouds are quite fluent, not much detailed, so a real part of the background which does not draw too much attention, while still pleasing.

Image above: The PNG-8 version of the clouds is much more detailed, making them a little more realistic. It’s nice, but the style does not match the rest of the game, which is more surrealistic.

Ofcourse we can do more image processing to smooth the PNG-8’s edges, making it look more like the CVF version. And we can do more optimizations on the CVF version, to decrease quality and filesize. That’s a decision to make later. Still it’s nice how the two compare.

The little blob in the centre of both images is an enemy helicopter. This helicopter uses CVF images only. PNG-8 was unsuitable to use for the helicopter, because they had a weird white border around the helicopter, which I was unable to remove. I have encountered this problem more often with PNG-8's, which is why I've been using PNG-24 all the time. The first versions of the CVF also had a strange white border round the helicopter, but I removed them by adjusting the trace options in Inkscape. The result is quite satisfying.

While I should have been testing more images, to prove my concept, I really have been busy with maturing my compression project.

For first time readers, a little flashback. Filesize is highly important when creating browser games. Small data size is required to get faster download times. Download time is a crucial factor for people to decide whether they will play your game or not.

So how to crop lots of images in your game, while keeping the download size acceptable? Well, use a very good compression format for your images. PNG has a good compression, however many PNG’s altogether make a slow download. With Inkscape, it is possible to trace PNG bitmaps into vector graphics and save them as XAML. But these vector graphics are usually much larger than the PNG you started with. I have been busy with a method to compress these Inkscape XAML’s, with some success.

The following picture illustrates different quality results, so they are easy to compare:

From left to right.

The first film-strip is the original PNG-24, 15.3KB, which is used in the game Slengo.

The second film-strip is the original PNG, but now saved as PNG-8, which is 4.59Kb.

The third filmstrip is an Inkscape result and then compressed with my compression technique. The original PNG-24 is input. Trace bitmap, smooth=false, remove background=true, scans=11. The size of this file is reduced to 11Kb, when winzipped.

The fourth filmstrip is an Inkscape result, compressed with my technique. Input is a regenerated image, similar to the PNG-24 original, but now twice its size. The original uses 40x40 frames, while this image uses 80x80 frames. The Inkscape steps taken are:

1. Trace bitmap, smooth=false, remove background=true, scans=11.
2. Simplify.

The size of the compressed result is 7.16Kb.

The fifth filmstrip is like the fourth filmstrip, but Trace bitmap has been performed with scans=10; one color-layer less than the fourth filmstrip. The resulting file can be compressed to 6.36Kb with Winzip.

An honest conclusion is that I did not beat PNG-8. However, I did beat PNG-24 with interesting results. The loss of quality, between original and result is clearly visible. But the quality of the fourth and fifth filmstrips are still quite acceptable.

I still need to investigate this method with more images. Even though it does not outperform PNG-8, it still may be an interesting method to compress vector-based images. 

Just after posting the previous article, I did a new experiment. Obviously, the quality of the resulting image was very, very bad. And the method described to improve quality, had such a low result in file decrease, where you could question whether this method is worth its while. But an important thought is, that you must know how to use your tools, to get the best results for both compression and quality.

The first article used option “Smooth” checked, for the “Trace Bitmap” function in Inkscape. This option obviously decreases the quality of the result. Also, in the first tests of the first article, the function “Simplify” was used to decrease the amount of vector points, but making quality even worse.

How to get better quality with less points? The answer is, use the Simplify function in Inkscape, but this function must remove lesser points. As the Simplify function in Inkscape does not have an options screen, where you can program this function to remove lesser points, we will need to influence this desire from the outside.

The character in the original PNG is actually a 3D model. Animation-frames are outputted at 40x40 pixels, and then concatenated in the vertical direction. For this experiment, I outputted animation-frames at 80x80 pixels and concatenated them. The image is now twice the size of the geometry which I intend to use in my Silverlight game.

This image was used as input for the whole Inkscape process:
1) Import Bitmap;
2) Trace Bitmap, Smooth=unchecked, Scans=11, Remove Background;
3) Simplify;
4) Save as XAML;

Because the input image in this process now contains more detail, the simplify function in step 3 will decrease less quality, than if we’d used this simplify in the original, smaller image.

After the result was saved as XAML, my compressor created an XZ file, with the compression 2 method, and then showed it with my Silverlight decompressor. The first result was very bad. With a larger picture, the factor=100 overflowed some values beyond the Int16 borders, breaking the image. I used factor=10 instead and to my surprise, this lower precision didn’t affect the quality of the image very much.

This is the result for my decompressor, with factor=10 and the result being scaled to 0.5 (because the original is twice the size we want to use).

This is the visual output:

Well, that quality is not very far from the original PNG with 40x40 frames, 16KB.
These are the file stats:

The name of the files used is “MrA_Large”. Compressed and then zipped, it only takes 8KB, while the original PNG was 16KB. These values may be compared, because the 40x40 animation frame is my target in the game, while the path to achieve this, is of lesser importance, as long as we can use the method for all or most of the images.

By using an image twice the size of the image we want to use, we put more detail into the picture. In Inkscape, the simplify function now worked on this more detail, leaving enough detail after its execution. As far as the simplified image has glitches, these were hidden when the end result was scaled down with factor 0.5. The end-result is quite statisfactory, and the compression/decompression algorithm hasn’t even been optimized to make even smaller files.

A compression of 50%, well, for my testcase that is.

As we’re now using factor-10, to convert floats to short, the numbers in the vector data must be between -3276 and 3276. With larger numbers, the numbers will overflow and corrupt the image. However, this limitation is relative. How many images need a resolution larger than 3200x3200? If there are such images, perhaps further optimization of the compression algorithm might overcome this limitation.

One thing is for sure, this method works for this image. The next step is testing more images and study the results.
The graphics in the game Slengo occupy 2.04 MB. If I could slash that with only 40%, while keeping an acceptable image quality, then this method would definitely be my choice.

In the previous article, I investigated the file sizes of two compression methods. But compression is nothing, when you can’t decompress.

I took the next step. What does the image look like when decompressed in Silverlight?

Well, here are the results:

To the left is the image decompressed according to compression method 1. To the right is the same image decompressed, now with compression method 2.

As described before, compression method 1 is just the conversion of text-floats into binary floats.

Compression method 2 is more interesting. The text-floats are converted to binary short (Int16). In this experiment, it became clear how important precision is. When floats are casted to short, all numbers behind the decimal point are discarded. The first result looked bad.

In the second test, I multiplied every float in the data with 100, and then casted it to short. With the factor 100, you gain 2 decimal numbers extra precision, before cutting everything off. In the decompression, the input short is divided by 100 again and the resulting float is then used for the path data. The result of this factor-100 test is displayed at the right side. The multiplication factor can’t be too high though, because an Int16 is limited to -32,766 until 32,767.

In my image, the largest number is 318, which fits in the Int16 range with factor 100. Most numbers lie somewhere between -15 and 15. Also, the larger numbers are used for the M command, while the other commands use lower values. So to improve this compression technique, we should sometimes allow floats to be converted to floats, while the lion-part of floats is converted to short, with the best precision factor. As long as the results give better compression than PNG, it is the right way to go.

Other considerations

Make sure you have read the previous article before reading this paragraph.

In the previous article, I used the Simplify function in Inkscape. Also, for every test, I scanned the original bitmap with option “Smooth” checked, and scans=12. One also needs to consider these options, because they affect quality.

Unchecking the Smooth option in Trace Bitmap, gives a better quality vector image, for the image I’m testing with, making the saved XAML and the compressed XZ file much larger. But hey, the amount of scans does not have to be 12. Perhaps it could be 11, discarding one color layer and lots of floats.

The above shows an interesting result. To the left is the original PNG of 16KB. To the right is a decompression result in Silverlight. The right result was produced with Smooth unchecked and scans=11.

The compressed XZ file is 46KB. Zipping this XZ file results in a 14KB file, still a little smaller than the original 16KB file. So the lesson to learn is that this compression technique might indeed work, but when used incorrectly, it will produce larger files than the PNG original.

Here are a couple of very interesting pixel games. Pixel games are to give you a retro-nostalgic feeling. Click on the links to play.

Color Theory
Brilliant pixel platform game. You need to find your way through this, well, sort-of maze and get to some wormhole thing. The funny thing is, when you touch colored items in a level, the platforms change. Some platforms disappear and others appear, changing the rule of game.

Jump on that red plus-sign to get rid of the red platforms

Pixel
A very good chain-reaction clone. You pick your own avatar and then you shoot enemies. These enemies explode pixels, which can kill other enemies. The fun with this game is that it has continues play. Most chain-reaction clones give you one shot and you must kill a percentage of all enemies. In this game you keep on shooting. The level-transformation is smooth. While you are aware of the next level, the playing is hardly interrupted.

I played the footstep symbol in the center-right, dodging enemies and collecting pixels

Different colors, different enemies and a great mess of pixels to look at

One Button Bob

For your authentic retro-game feeling. It even has a C64 load screen! I’m not sure whether this game is for real, or it is a parody on the discussion that games should be even easier to control. You control the character with the left mouse-button only. In each level, clicking the button has a different function. In one level it the button is to throw a boomerang against a bat. In another level the button stops the player from walking, so that you can avoid a falling spear from the ceiling. Parody or not, this is a very creative game.

In this level, you need to press the button to start walking