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!

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.

It is fun to create a basic shape, which can be used in a larger scene. For example, I created a usercontrol to present an arc bow with arc segments.

This control has uses two parameters, “Radius” and “Thickness”. With Radius I can make the outer part of the circle larger, which drags the inner part of the circle with it.

As you can see, the Radius has now a larger number and the arc is bigger. With the Thickness parameter I can decrease the size of the inner circle part.

Both parameters are dependency properties, so that they can be used in a Storyboard. It is not very hard to create this control. It is actually a list of 6 arc segment controls, with the correct rotation and position settings. The Radius and Thickness parameters are both wired to all these 6 arc segment controls.

Make sure to use the Nerd Plus Art Silverlight code snippets for Dependency Properties. I used the “sldpc” macro to create the Dependency Properties for the Radius and Thickness parameters. In the change handler, the new value assigned to one of the parameters will be propagated to the whole list of arc segments.

So really, all the magic is in the arc segment control.

The arc segment is a Path geometry, and it is created in Visual Studio. This is a XAML snippet for the arc:

Notice the usage of x:Name. Naming the path figure segments gives you control over these segments. You need to be careful when working in Blend, because Blend converts these segments into Path data, and you lose all x:Name declarations and control over your shape.

The Arc control has three parameters to control it, all are Dependency Properties: Radius, Angle and Thickness. Radius and Thickness ofcourse work as described above. Angle sets the angle between the x-axis and the end of the arc, where a positive angle starts in quadrant 1 (upper-right).

Each time one of the parameters is changed, the shape is recalculated. When angle is larger than 180, the “IsLargeArc” parameter is set to true.

For the finishing touch, the UserControl’s properties “Fill” and “Stroke” are rewired to our shape:

Now all coloring of the shape can be done in Blend, using the common features for this, including the gradient tool.

What is it good for? Well, I thought the segmented arc could give a radar-like effect, to draw attention to a new enemy, entering the playfield of a game.

Over the weekend, I completed my new webdesign. It was incorporated into the website and also into the weblog. I hope everyone likes it this way. The design has two stylesheets, one for 1024x768 resolution and one for 1280x1024 resolution. If you have a higher resolution, you'll see the 1280x1024 stylesheet, because I cannot test these resolutions myself.

I've also added the Captcha's challenge for comments, as I was receiving a lot of comment-spam. This challenge requires a person to enter the two words in a distorted picture, before a comment can be submitted.

I call this the Neon-design. It is actually metal, neon-light, to give a little 80's arcade-hall feeling. For the website, I have removed the categories feature. The main page now just display all games. Clearly I do not have enough games to put them into a category. I hope the new design is able to attract more visitors.