Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more

Tech

v1.3 Vector Sprites

Posted on 28 November 2013

Note: Only Professional and above users will receive advanced SWF functionality. 


A new feature that we’re adding for the latest version of GameMaker: Studio is support for vector sprites, imported from the popular SWF file format. Up to now all sprites in GameMaker have used bitmaps which, while flexible in terms of content, place limitations on both the size and number of frames possible in a sprite before memory usage can become prohibitive.

 

 

Vector sprites work around these limitations by storing and drawing their contents differently. Instead of a grid of pixels, which can become blocky or fuzzy when scaled, they are drawn as triangles which can be scaled up without losing definition. Here’s a comparison (bitmap on the left, vector on the right):

 

1.png

 

This image shows the triangles that are actually being drawn in the above vector sprite:

 

 2.png

 

As nothing is ever for free, the tradeoff with vector sprites is that they are more expensive to process (from a CPU perspective) than bitmap sprites and this speed difference increases as the complexity of the animation increases. Also, their memory usage is affected by their visual complexity, unlike bitmap sprites. 

On the flipside of the performance equation, because vector sprites only draw the pixels absolutely required (unlike bitmap sprites which also ‘draw’ the empty space around the image) then can be cheaper from a GPU perspective. Also, in general vector sprites are much smaller than their bitmap equivalents – for the fireman example above the sizes of the various sprite types are as follows:

Bitmap at 70x68 = 4x70x68 bytes x 12 frames = 223k

Vector = 54k

If you quadruple the resolution of the sprite:

Bitmap at 280x272 = 4x280x272 bytes x 12 frames = 3570k

Vector = 54k

So as you can see a lot of memory can potentially be saved by using vector sprites, and we still have a lot of potential for future space savings. Overall, they make it possible to add large animated graphics in ways that would have been practically impossible beforehand. 

How To Use Them

 In general we have tried to make the process of using vector sprites as close as possible to using bitmap sprites, so how you add and work with them isn’t significantly different. Please note that we’re still tweaking and adding things so some dialogs may look or function slightly differently in the released version.

To add a vector sprite, open up a sprite object which will show the usual dialog:

 

3.png

 

Hit Load Sprite and select an SWF file in the file selector. A progress bar will pop up as the SWF is processed – depending on the complexity of the file this can take a while (up to a minute for more complex animations).

When processing has finished you’ll be returned to the sprite properties dialog, which will now look like this:

 

4.png

 

As you can see it looks like the normal sprite dialog, with the first frame of the SWF file shown in the image window on the right.

There are a couple of changes from a normal sprite dialog though. Firstly, the Edit Sprite button has gone since there aren’t any bitmaps to edit in this sort of sprite. Secondly, a new Show Sprite button has been added – this opens the SWF file in whatever application is associated with SWF files (normally your web browser) and allows you to see the whole thing (note that if you have no application associated with SWF files this button won’t work– you can set up the association by right clicking on a SWF file in explorer, selecting “Open with” then selecting the desired application).

From this point most things should function the same as they do for bitmap sprites – some of the sprite drawing and sprite management functions are not supported for technical reasons (these will be noted in the documentation) but all the sprite variables associated with instances should work similarly. 

Things to watch out for

 Actionscript isn’t supported, so if your SWF relies on it to work correctly then it won’t turn out right. Similarly, any embedded movie clips that have their own timeline will only have their first frame shown throughout the animation – all animation must be on the main timeline. 

If your SWF file has particularly fine detail you may occasionally find that holes or strange triangles appear in the resulting sprites – at small scales geometry can sometimes collapse together to create shapes that don’t triangulate well. In this case you have two options – you can scale up the contents of the SWF file which gives the importer more room to play with, or you can try to reduce the level of detail in the object that is breaking.

GameMaker uses the stage size of the SWF as the bounds of the resulting sprite – however, if you have anything on the stage outside these bounds it is still drawn. This means that you should either try to avoid putting anything outside your stage bounds if you don’t want it to be shown, or use a mask layer to limit drawing to this area. The stage size also affects the size of any collision masks that are generated. Therefore if you have a large stage size and a lot of frames in your animation you can potentially eat up a lot of memory. Therefore only use precise collision if you really need it.

As a SWF file is created from many layers, some of which potentially overlap, alpha doesn’t work quite the way it does with bitmap sprites – overlapping areas will not look as transparent as other parts of the sprite, as the pixels there are being drawn over multiple times. The image below illustrates this:

 

 5.png

 

Bitmap fills are supported though if you use tiled bitmap fills as part of your SWF file you need to make sure the bitmap is a power-of-two in size, otherwise it won’t tile properly.

Text rendering is also supported, but you need to embed the font in your SWF file for it to show up in the resulting sprite. Also, currently only left-aligned single line text is supported. 

Conclusion

 Vector sprites are an effective way of drawing large animated images without the associated memory requirements of bitmaps. The current implementation unlocks a whole range of new possibilities for visual imagery that wouldn’t have been possible previously, but we are also considering future additions, such as the ability to convert the vector sprites to bitmaps at runtime (with controllable resolution settings) to have greater control over runtime performance while still using the same source data.

We hope you enjoy this latest addition to the GameMaker: Studio toolset.

 

Back to Top