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.

The motive for smaller image size is evident: faster download time. But how low can you go? Inkscape is an OpenSource drawing program which you can download for free. It has a brilliant feature to convert bitmap images (PNG’s) to vector graphics. Silverlight used to advertise that vector graphics have higher quality as you can zoom in without quality loss. This is true, however PNG’s and vector graphics are not very well exchangeable.

I took the following steps to convert a PNG to vector graphics:

1. Import PNG from the File menu;
2. Convert it to vector graphics, Trace Bitmap in the Path menu. Select “Colors”, Scans=12, Remove Background checked. Click Update then click OK.
3. Reduce vector points, Simplify in Path menu;
4. Save as XAML, File menu;

This is the result in Inkscape:

The left is the original, the right is converted to vector graphics and Simplified only once. Now obviously, there is quite some quality loss in the vector representation. We deal with quality later, this article is about file size.

Open the resulting XAML in Visual Studio. Now go to the Edit menu, Advanced, Format Document. Remove empty tags “Resources” and “RenderTransform”. Remove the “<?xml” line at the top. This result can be copied into a new Silverlight UserControl.

If the new UserControl is now compiled, the resulting binary is larger in file size than the original PNG you started with. The reason for this is that Visual Studio does not convert XAML to binary code. If you open a Silverlight binary in for example Notepad, you will notice that a complete copy of the original XAML is somewhere within the dll. In most cases, text is larger in size than the binary equivalent.

Compression 1: text-float to binary float

The Path geometry data from your Inkscape XAML contains many floating point numbers, in text representation, while a binary float is only 4 bytes long. As these floats occupy the larger part of the Inkscape XAML, we could write a little program to convert this Inkscape result into something binary.

Well, that is what I did experimentally. And although this converter does not support the full Path data mini-language yet, the lion-part is already converted to a binary representation. And if you have the lion-part, then there is a good moment to determine whether your experiment will ever have any success: get smaller file sizes.

These are my findings:

The original PNG is 16KB. The product from Inkscape is 50KB. This will also be the size when you compile the UserControl. When zipping this to a xap will never be better than the original 16KB.

Converting the Path textual data to binary .Net floats, the product is now 22Kb (the .XZ file). When adding more features to the converter, this size will be a little larger; I estimate about 1Kb, because these features are rarely used.

The next step is to look at the size of the XZ file when zipped: 11Kb. Zipping the original PNG will result in a zipfile with the same size. So with this immature and still-under-development compression technique, we already gain 35% in filesize.

Compression 2: text-float to binary short

I also tested another technique for further compression. Float’s are 4 bytes long, while shorts are 2 bytes long. A technique learned from the past: multiply the float with a factor to gain precision, and cast it to short to discard remaining precision. Evaluation of this technique is out of scope here. The result is however that a number no longer occupies 4 bytes, but only 2 bytes.

To only know the results of this technique, I did a test, having factor = 100. These are my findings:

The XZ file, the result of my compression program, is 12KB, already smaller than the original PNG. Compressed, the XZ file is only 6KB, giving a gain of 62%.

Discussion

Now, let’s not get too excited. I have cheated this discussion on two important points. Yes I have converted the Inkscape XAML to a binary representation, but I never decompressed it. I don’t know what the results will be when I decompress the XZ file and construct a UserControl in my Silverlight application. It could turn out to look very bad. This is the next research step.

Secondly, after I converted the PNG to vector graphics, I used the Simplify function in Inkscape, to decrease the amount of floats in the resulting XAML. How far does this Simplify step affect the compression results? Well, quite a bit.

This is the result of converting PNG to vector graphics, without simplify function:

Here are the compression results for text-float to float:

And here are the compression results for text-float to short:

So when it is forbidden to use Inkscape’s simplify function, the conclusion is that the compression 1 method is not worth implementing, while the compression 2 method is worth investigating.

Ofcourse it is not forbidden to use the simplify function. You can even create graphics which anticipate this function in the art process.

Great developments on the VorbisPlayer. To reduce the download time of Slengo, the bitrate of all sound in the game was reduced from 44.1Khz to 16Kh. Although the quality of the sound is lower, it still sounds quite good. 1.87Mb of data was reduced to 0.99Mb.

Another advantage is that the VorbisPlayer uses less CPU at this bitrate, and performs much better. On high-end machines, people did not have much problems with performance, however on lower end machines the sound could stutter. With a lower bitrate, this problem solved for low-end machines. The VorbisPlayer was modified to allow for lower bitrates.

A new release of the VorbisPlayer has been uploaded on CodePlex:

Avios is a great game if you liked Wings of Fury during the nineties. It took 5 months to develop, but it isn’t very well appreciated. There are different aspects for improvement. One aspect is to get a better loading time experience.

Players of online games don’t like to wait very long for a game to load. I have seen different approaches for better a better game-loading experience.

1. Load everything all in one
The game exists of only one xap, which is loaded at once. At Mashooo and Silverarcade they’ve found a way to improve experience. Each game is loaded by a generic preloader, displaying the current percentage. This is very well done. The drawback is however that the game will be loaded completely, you cannot split it into parts. This approach cannot distract the player’s attention if the game is very large.

2. Partial preload
A preloader loads the basic data. The rest of the data is loaded while the game is playing. This is the scheme I’ve been using for most of my games. In my case, the preloader has a list of images and sound effects to be loaded. Any music which is played during the game, is played from the server during the game. Music files can be quite large and they’re not always played completely. So this approach has an advantage over loading it all at once.
You also have more control of what will be loaded in the preloaded, and what will be loaded during the game. Nokola’s Shock for example loads the most basic things to play the first level in the preloader and everything else during the game. Avios however loads all images and sound effects for all levels in the preloader.
An improvement for Avios could be to load everything to play the first level, while loading everything else when the first level is played. No problem for Avios. But in a different game, in such a scheme, the loading and playing of music could compete with loading other data. It could interfere with the music being played. So this needs to be tested.

3. Lower quality
It isn’t surprising that visuals in many games are very small. Smaller graphics reduce the data volume and give better loading experience. For the same reason, players experience lower sound quality for the same reason. Lower quality improves game load experience but may reduce playing experience. This balance is the choice.

4. Change the Encoding
Unfortunately, using vector graphics doesn’t increase quality, while data volume is reduced. I have been playing around with Inkscape 1), to convert bitmap images into vector graphics, exporting it in XAML. In many cases, where I replaced a bitmap image for a vectorized version, the data volume increased. If you want to preload such resources, you need to dynamically load a dll, instead of loading a list of resources on the server.

For my games, I usually use PNG’s. PNG supports alpha channel –  transparency. JPG’s do not support this. In Photoshop you can export JPG’s at low quality. One could use these low-quality JPG’s, assign a transparency color to it and process the images using WriteableBitmap, to support alpha channel. I have done a little study to this option, but I found the image-quality so very low that I decided it was not worth it.

There is also a gain for sound encoding. MP3’s are usually larger than WMA’s. So it does pay to encode for WMA. It is worth it to play around with the encoding settings. I was able to encode an original MP3 file of 1.8 MB, to a 491 KB WMA file, without significant loss of quality.