Performance Tips (Part 2)

Ben Anderson — Wed, 15 Oct 2008 01:25:52 GMT

Yesterday we began our discussion of performance optimizations in Popfly Game Creator. In that post we discussed how collision detection impacts performance as you add actors and ways to mitigate that impact. Today I’d like to talk a bit about the other bottleneck people hit and that is Silverlight drawing perf. along with some best practices in creating and using your actors to keep your games snappy. Today’s article contains discussion and techniques that are fairly advanced, so if you feel a little over your head, definitely try the tips outlined in Part 1 first.

Silverlight has great support for a number of drawing mechanisms. It supports static images in the form of jpegs and pngs, as well as XAML based vector art which can be generated either by hand, with a tool like Expression Blend or exported from art packages like Expression Design or Adobe Illustrator. Vector art has the advantage that it can be smoothly scaled (as well as rotated, skewed etc) as large as you want, and since it’s all computed geometry it will look as sharp as it did in it’s natural size. Some people also like to say that it has a smaller file size than traditional image files which define their content pixel by pixel, but this isn’t necessarily true. It’s more accurate to say that the file size remains more or less constant regardless of it’s final rendered size. With traditional image files, the file size grows as the image dimensions in pixels grows, however it shrinks when the dimensions shrink. There is plenty of vector art (XAML or otherwise) with file sizes at reasonable resolutions that far exceed the equivalent png or jpeg representation. This is because XAML file sizes grow as the complexity of the image they represent grows. Designers can easily create files that weigh in the megabyte range by adding more and more detail to their images. They can also create relatively small files by sticking to a few simple geometric shapes in their designs.

So what does that mean for all you budding Popfly game designers out there? Actors in Popfly are defined as XAML. First, realize that the complexity of a XAML file doesn’t just increase the file size, it also increases the amount of time it takes Silverlight to draw an image. So if you’re using XAML to draw your actors, you can shorten the time it takes Silverlight to draw them (and thereby increase your framerate) by simplifying their XAML – the fewer and the simpler elements the better. This also has the added benefit of reducing their download size for your users. Sometimes though, a complex image can do the job much better than a simple one. If that’s the case, realize that unless you are scaling your actors to fairly large sizes, you can simply use an Image element in the actor to incorporate a static .png file of the appropriate dimensions containing your actor’s appearance. Because with a static image, Silverlight can simply copy the bits to the appropriate location on the screen (an operation often called bit-blitting), it doesn’t have to do any processing to draw the image. This can dramatically increase the speed at which it draws as bit-blitting is an operation that is highly optimized and has been hardware accelerated by graphics cards for many years – since well before consumer 3D graphics accelerators even existed. Most Microsoft provided actors are XAML based so that they scale smoothly, but if you’re not using this functionality, you can always screenshot them while your game is running (press Print Screen to copy the current screen to the clipboard then paste the results into Paint or Paint.Net), fill in the background with transparency, then save the image as a png of the appropriate size and replace the actor’s appearance with the static image. Particularly with a scrolling viewport, this can save a lot of cycles.

Finally, if your game uses a tiled surface to represent areas of the game such as fences or the ground, you don’t necessarily have to tile multiple actors to achieve a tile effect. Doing so increases the number of actors active in the game which hurts performance as we discussed yesterday. Instead, you can tile the image in your XAML. This is especially easy with image elements since you can just copy the image element, change it’s Canvas.Left or Canvas.Top and tile the image to any length you want. To see an example of this technique check out the game I’ve shared here. If you rip the game you will notice that I did not use a single fence actor but rather several – Tall Fence, Wide Fence and Medium Fence. This is because I simply wanted the fence to stretch across the sides of the screen. If I just stretched the actor the image skewed and if I tiled the actor things slowed down. So instead I manually did the tiling. Click on the Wide Fence’s appearance and select XAML to see the technique. Tools like Expression Blend can help you do this if you’re having a hard time doing it in Popfly’s text editor:

Hopefully these articles will help out those of you who have been running into performance barriers when creating your games. To discuss these tips and tricks, to share your own tips or to get additional help, checkout the Popfly Game Creator forums. You can also check back at this blog for future tips and tricks.

Performance Tips (Part 1)

Ben Anderson — Mon, 13 Oct 2008 18:54:00 GMT

While we’re constantly working to improve the performance of the Popfly Game Creator, there are a number of tweaks you can make to your games right now to improve your users’ frame rate.

Right now, there are two main bottlenecks for games created using Popfly and depending on the characteristics of your game, one or the other can probably help you.

Today we’ll talk about the biggest perf. hit for most games, which is collision detection between a large number of actors. There are a number of ways to address this.

The easiest trick is to make as many actors as possible non-solid:

This is a per state property, so if your actor has multiple states, make sure you set it for each one. When an actor is non-solid, it’s collision bounds will be drawn in blue instead of red.

When an actor is non-solid, it will no longer push or get pushed when it collides with other actors. This allows us to skip testing it for collisions except when there is a collision listener whose event includes the actor. Even then we only have to test it against other actors that are included as the other actor on the same event.

The next approach is to limit the number of actors you use on any scene. While this can lead to a less compelling game, but if your game is bottlenecked on collision checking, it is guaranteed to increase performance.

If neither of the above is desirable, you can also increase performance by limiting the motion of your actors. When an actor has not moved, it often allows us to skip testing it in parts of our collision detection. This also improves Silverlight drawing performance (which we’ll talk more about tomorrow) since we will not have to update the Silverlight plugin and Silverlight will not have to re-render the actor in its new position.

Finally, if you are spawning new actors throughout the course of your game (through shoot behaviors, Appear behaviors, effects etc) there are a couple of things you can do to keep things snappy.

First, make sure you limit the lifetime of the spawned actors. Leaving the “disappear on scene leave” behaviors intact helps with this since once the actor reaches the edge of the screen, the actor will be removed from the game keeping the total number of actors low. Second, limit the rate at which new actors are added. For example, if you allow the player to shoot, try limiting the rate of fire by setting a property to 1 on your actor when the player presses the fire button, then clear the property to 0 on a timer. Then simply add a filter to the fire behavior to only allow the player to fire when the property is 0. Alternately, you can limit the # of bullets the player can fire at once by filtering on the # of BulletName property (you may have to copy the value of this property locally to your actor from the scene using an “every frame” timer). Lastly, you can throttle down the rate at which your enemies fire when there are a lot of enemies on the screen through custom code or using a filter on # of EnemyBulletName.

Hopefully these tips will help those of you with games whose performance is bound by the total number of actors. Because naive collision detection’s performance is an O(N^2 ) problem (where N is the number of actors, adding one more actor will cause another N + 1 collision checks to take place), adding actors can quickly cause problems. Using the tips above can really improve performance. If you’re having trouble after following these tips or they aren’t helping, be sure to head to the forums where other users and members of the Popfly team can help.

Tomorrow I’ll follow up with Part 2 where I will provide some tips for creating actors that are easy for Silverlight to draw and also help keep Popfly’s game engine running fast. Stay tuned.

The Right Moves : performance

Performance Tips (Part 2)

Performance Tips (Part 1)