When developing a game, at some points you need to face the truth why your idea is not working. Well, I’ve been developing a shooter game, based on a C64 game of which I don’t remember its name. I liked the game back then and the graphics in the original are somewhat simpler then my approach.

This is the result:

What is wrong with this game? Well, the movie demonstrates exactly what is wrong. The world is based on 3D coordinates, which are translated to 2D using perspective projection. And this is very hard to play. As the movie shows, when the player is to the right and shoots, the fire-balls do not go straight up to the horizon, the follow a perspective diagonal line, tilted to the left. When shooting at the left side of the screen, the problem is vice versa. Only when the player is at the middle of the screen, the bullets go straight up.

The game would be more playable when the player’s bullets would go up all the time, as like in the middle of the screen. The bullets would follow a path of parallel projection, where the position on the Z-axiz (into the screen) would be a factor of the Y-axis (vertical).

But do players buy this? The “ground” could be in perspective projection, like it is now, but bullets follow a parallel projection path? Gamers would probably buy it, because like television, games are lies.

There is more wrong with this game, things that fall in the category “not finished so don’t complain”.

It is these moments one could give up the whole idea and declare the invested energy as a waste of time. However, you can also look away from it, and get back to it again later with better ideas. I guess it is part of the creative process.

Thanks to Silverlight’s powerful clipping features, it is incredibly simple to create a triangle sliding volume control.

1) Create a Canvas, which contains all visuals;
2) Create a rectangle for the background within the Canvas. Width=100, Height=50. Here, the background is green;

3) Create a rectangle for the slider, on top of the background. Height=50, Width is smaller than 100 to show that this red rectangle is on top;

4) Create a clipping on the Canvas which contains the rectangles;

The clipping XAML defines the rectangle path:

Note that Blend converts the above to a more compact format, but this is not a problem. The path starts at the left-bottom corner, then via a line segment, it goes to the upper-right and then to the bottom-right. The bottom line segment is not required thanks to the “IsClosed” setting.

5) Create a border around the volume control. A part of the clipping geometry is copied for this, into a Path control. The XAML for this path control needs to be inserted below the XAML of the red rectangle, so that the border is on top:

Note that Blend will convert this Path figure into something more compact, which is no problem if you are satisfied with it.

6) Now that we have the visual part ready, it is time to implement the code behind. First, give names to your controls. The green background gets the x:Name=“Background”, the red slider gets the x:Name=”RedRectangle”. In Visual Studio, both green and red rectangles need mouse events. For both rectangles, these mouse events are wired to the same function.
Add these mouse event attributes to both rectangles:

7) Implement the mouse events:

Explanation:

The mouse-move event should only work when the mouse button is clicked, so the mouse-down and mouse-up events set a variable “clicked”. When clicking, the slider’s position should be adjusted right away, so in the mouse-down event the SetVolumePosition function is called. We are interested in the horizontal mouse-position, relatively to the green background rectangle, as this is our origin. The SetVolumePosition only sets the width of our sliding red rectangle.

Finished!

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.