Working With Sprites – Part 1: Normal Sprites

Sprites are how images are handled inside WildStar and if you need to get your own images into your add-on you’ll need to create a sprite definition for it, which is done through the sprite editor in Houston.

In this tutorial I will go through how to create normal sprites (which are the most commonly used sprites) inside Houston’s sprite editor and some things you should be aware of when creating your sprites.

Adding and renaming a sprite file

After you’ve created your add-on you can add a sprite file as shown below.


You will then be taken to the sprite editor with your new sprite definition file opened for you.


What you will likely want to do here is slowly double-click on “NewSprite” in the Sprites tree view so you get the edit box and can rename it.


For this example I will just rename it to “WWS” (because this particular add-ons is called “Working With Sprites”). You can follow whatever naming convention you like, but there are one thing to keep in mind which I will discuss later.


As you might notice (if you look at the two tabs showing the currently open files) the filename of the sprite file has also changed to reflect the new name.

The reason I renamed it is because is just looks better than having a “NewSprite.xml” file for all of your add-ons, but more importantly because it dictates the prefix of the sprites, which I will get into later.


Creating a Normal Sprite

If you go ahead and expand the tree in the Sprites pane you will see 5 categories of sprites.


For this tutorial we will be dealing with “Normal Sprites” as these are the most commonly used.

A normal sprite is basically taking an image and making it available for your add-on.

However this being a sprite editor there are some nifty options associated with images and how they behave in the game.

First off let’s create that new Normal Sprite which is done by clicking the Normal Sprite icon in the toolbar.


You will now be met by a dialog box asking if you want to “Browse Local Files”, “Browse Game Data” or “Cancel”.

We want to add our own image so pick “Browse Local Files”.
You will then see a standard Windows file open dialog where you can find your image file from.

Your image file should be located inside of the folder of your add-on (possibly a sub-folder) so everything is in order when you pack it up and distribute your add-on.

You will find your add-on’s folder in C:\Users\<Windows login name>\AppData\Roaming\NCSOFT\WildStar\Addons\<Your Add-on Name>\ (at least for newer Windows versions).
Be aware that “AppData” is a hidden folder and unless you have told Windows to display these you will not be able to see it.
A way around that though is to open “Run” and type in “%APPDATA%” (without the quotes) and you will have Explorer opened at the “Roaming” location, so you just have to navigate from there. The same can be done from within Houston if you type “%APPDATA%” (again without the quotes) into the “File name:” edit box at the bottom..


A word about image formats

You might notice that the open dialog lists a few different image formats it’s able to recognize, however these are not currently correct. At this point Houston (and the game) only really works properly with TGA and DSS files – the rest aren’t actually supported and are likely to cause problems, so stick with TGA for now. Once this change I will update the article.

The TGA files supported are both 24- and 32-bit and with RLE compression. 32-bit is used when saving with an alpha channel.


Working with the TGA format

If you haven’t worked with TGA images before there is something important to know when working with alpha channels for the format.

TGA uses straight (unmatted) alpha which can be a little tricky to work with, especially if you haven’t done so before.

As an example I will create a simple fading circle in Photoshop to show what straight (unmatted) alpha means and how you work with it.

Here we have a white circle fading out to fully transparent. It’s on a transparent background as well so everything should be good to go, right?


Not with TGA and straight (unmatted) alpha. Because of this you have to save the alpha information as a new channel (you can see the channels at the bottom right of the screen, where there’s currently 4: RGB, Red, Green and Blue).

To do this hold down Ctrl and left-click the thumbnail of Layer 1, our white fading circle. This will create a selection that has the needed alpha information.
Now go down to the “Channels” section and press the second button from the left to create a new channel based on the current selection.

As you can see from the image above it will create a new channel called “Alpha 1”. Make sure to only have 1 alpha channel when saving your file otherwise you won’t get the option to save the alpha channel.


However there is still one issue which is that anything going to transparent in the RGB channels won’t work – it is all controlled by the alpha channel. So for this image to come out as we see it in Photoshop right now, we will have to create a layer that is completely white (since our circle is white).

When you are working with straight (unmatted) alpha you can’t have anything going to transparent in your actual image – you must have pixels at full opacity anywhere there will be anything shown, and the alpha channel will take care of how transparent they should be.

So for this little example to work we will end up with the following:


Now we can go ahead and save the file.


Make sure that when you are saving with an alpha channel you tick the check box for it, as shown above.

On the next screen you will be met by the options for saving in TGA format.


If you are saving with an alpha channel make sure to choose 32 bits/pixel. If you aren’t using an alpha channel you can easily pick 24 bits/pixel.

It’s worth using the RLE compression. It’s lossless (no image quality loss) and will reduce file sizes fairly well (depending on complexity). There’s no disadvantage to using it and you will take up less space on user’s drives, especially since TGA files can be quite big without using RLE compression.


Now back to making our sprite

Right, let’s get that TGA file opened and named.


As you can see I named it “WhiteFadingCircle” and this will be the name you use to use the sprite in your add-on. You can see that it’s also shown in the tree view out to the left.
Likewise the background of our image comes out as a dark-redish color, which is basically the color shown for the background of something transparent.

Now you might notice that both “Preview” and “Frame Preview” are empty which is because we actually haven’t defined what part of the image we want to use for our sprite.

A sprite doesn’t equal the full image – you can have multiple sprites defined from a single image by simply setting different selections for each of them.

The two “Preview” and “Frame Preview” windows are used for, you guessed it, previews. “Preview will show the full sprite preview (if for instance it’s animated) while “Frame Preview” will just show the currently selected frame.

Below where we named our sprite you can see a list that now only has 1 sprite defined. This list is used for animation and with just one frame there we just have a static image sprite. I will get into animating sprites later.


Defining a sprite from the image

This is one place where you will be able to see the advantages of not just using images directly but defining them as sprites.


Shown above you can see a dark-red stripe on each of the rulers – that’s actually 6 different markers in each stripe. Yes, it’s not very well done and are a pain to work with so hopefully they’ll be improved.

For this sprite we want to use the entire image and for that we just drag the 6th markers to the end of the image on each ruler like shown below.


As you can see those markers are rather tiny – so much fun. 😉

There is an alternative method to doing this though, one that can be better in other cases.
On the right side of the top ruler you will find 3 buttons marked M, R and H. These set 3 different modes them being: Move, Rectangle and Hotspot.


If you click the “R” button it will allow you to draw the area of the sprite on the sprite sheet itself. The “M” button will allow you to move an already created rectangle if you need the same size somewhere else in the sprite sheet (if you have multiple sprites defined in one image for instance).

The “H” button I actually don’t know if it works currently. According to Packetdancer it’s supposed to basically allow you to set the anchor point of your sprite, so you could for instance set the hotspot at the center of your sprite and it would size from there, meaning it would always stay center. I haven’t done any real testing of it and doesn’t seem to be functional within Houston from what I can tell.

So we now have our sprite defined as it has a start position (0, 0) and an end position (256, 256). Pretty sweet!
The start is defined by the 1st markers and since they’re at 0, 0 to begin with we didn’t have to change them for this sprite.

But you may notice that it is black in the preview windows, which certainly isn’t what we want. This is due to the colors set just above the horizontal ruler, which for some reason defaults to black (a bit annoying if you ask me as they should really default to white).

These 2 color buttons basically allow you to colorize your sprite for even more freedom, you can even create color animations with this method, which I’ll explain in a later tutorial.


For now we set the “Start color” to white, which basically means the colors of the original sprite is unaffected and you get a “pure” version of it, as you created it. Also make sure that the “Use start color as end color” is checked or it will start to animate.

That’s basically it! You have a sprite now! 🙂


Inserting a sprite into your add-on

Time to get this bad boy into our sweet add-on, so I open up the XML file for the add-on in the form editor and add a new “window” type control to put the sprite into.


I just named this window “SpriteForm” but you are of course able to name your window anything you like – this is basically the identifier of this particular control and what you use to reference it.

There is one important Style to have enabled when you want to display a sprite like this, and that’s the “Picture” one. So choose the “Styles” tab in the Window Properties window and make sure it’s checked. The window is created with a few standard options set, one being “Picture” already checked. Root windows are created with all these Styles already set while children windows have less set per default. For this tutorial we will just leave the Styles as they are now.


Switching back to the “Window” tab we find the “Sprite” input field with a button next to it. Clicking the button will allow us to open the Sprite Browser.


In the Sprite Browser there is a “Filter” input field in the top right corner and because we named our sprite file “WWS” we can just put in “WWS” and we will see all sprites defined inside that file.

This is what I talked about earlier in relation to naming your sprite definition file, as it will basically prefix your sprites with this name which has different advantages.

It allows you to easily find all your sprites in the Sprite Browser by just typing in this prefix in the filter section – you can even include the colon to make sure it only gets sprites with the prefix, as you can see in the following screenshot that a sprite is listed as “prefix:spriteName”, which is how it’s called.

For now our list only has the WhiteFadingCircle sprite.


However do note that this only works because the sprite file is attached to the Form XML file that we’re working with. If this wasn’t the case you would not be able to find the sprite from inside Houston. And if you’re working with another Form XML file it will need to be attached to that as well.

The way we created this sprite definition file it automatically got attached to our Form XML file, which can be verified by going to the “Files” tab/pane in Houston and see that it’s listed as a child of the Form XML file as so:


In the Sprite Browser we select our WhiteFadingCircle sprite and it will be put into our window control.


Well hello there, sprite! As is evident the window control is not big enough to show the entire sprite (and someone messed up on properly fading it out to fully transparent…;)) so we can adjust the size of the window accordingly.
Since our sprite is 256×256 we’ll just set the control to that by adjusting the offsets.


And well, that’s the sprite inserted and fully displayed!


Sizing a sprite

Now what if we want to have the sprite be half the size of what the image actually is?
If we half the size of the control right now we will end up with this:


Not really what we’re looking for, so back to the sprite editor to fix that.

Remember how the rulers have 6 markers that can be dragged? These come in handy now, more specifically the 5th markers.

If we take the two 5th markers and drag them all the way to the end, just like with the 6th ones, we will define a stretchable area for the sprite.

Save the sprite file and go back to the form editor and see that the sprite is now scaled down to fit the size of the control. With this in place a sprite can now be sized/stretched as you please.

You will also have to enable the “Stretchy” button in the sprite editor (located above the horizontal ruler) to make it actually stretch accordingly.


Further controlling sprite sizing

If you for instance want to create a frame type sprite, where you have borders and perhaps rounded corners, and want the corners and borderes to not go wonky, this can be done too.

I’ve created a small frame type sprite to demonstrate and already set up the basic sprite settings to have it show, like we went through earlier.


It’s time to get that 4th marker on the ruler into play and change how we use the 5th.

By combining the 4th, 5th and 6th markers we can slice our sprite up and define which areas should not stretch, which is very useful for creating frames and the likes.


As shown above I have created basically 9 slices using the 4th and 5th markers. The 6th is still defining the size of the entire sprite (together with the 1st marker, of course) and with the “Stretchy” button enabled we now get a frame that is fully sizable as it should be. To demonstrate we can put it into a window control in the form editor.


As shown this example is 200×600 and you can see that the borders and everything stays correct in terms of stretching.


The same of course holds true if we size it differently as shown above..


The way it works is best explained with a picture:


I’ve diveded the different slices up into different colors to show what happens.

All the green slices, meaning the corners, will never get stretched. They will stay the size as defined no matter what.

The two yellow slices will get stretched horizontally, so their width will increase/decrease according to the size of the control it’s in. Their height will not change.

The two blue slices will get stretched like the yellow ones, just vertically instead of horizontally, so their height is what’s affected. Their width will not change.

The red slice will stretch both horizontally and vertically, adjusting its width and height accordingly.

The 2nd and 3rd makers I’m not entirely sure about yet but I will update this tutorial when I know how to use them exactly. I just haven’t had time or reason to really play around with them as of yet.


In closing

This is the basics of dealing with (normal) sprites but there is a lot more ground to cover. In my next turotial I will go over animating sprites and how to improve the way you alter animations from outside the sprite editor as some things are a bit of a hassle to do in that.

Until next time; happy add-on’ing! 😛

Bookmark the permalink.


Leave a Reply

Your email address will not be published. Required fields are marked *