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.

tut_wws-p1_adding_sprite_file

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

tut_wws-p1_NewSprite_added

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.

tut_wws-p1_renaming_sprite_file_01

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.

tut_wws-p1_renaming_sprite_file_02

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.

tut_wws-p1_adding_a_sprite_01

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.

tut_wws-p1_adding_a_sprite_02

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?

tut_wws-p1_TGA_alpha_01

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.

tut_wws-p1_TGA_alpha_02

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:

tut_wws-p1_TGA_alpha_03

Now we can go ahead and save the file.

tut_wws-p1_TGA_alpha_04

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.

tut_wws-p1_TGA_alpha_05

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.

tut_wws-p1_adding_a_sprite_03

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.

tut_wws-p1_defining_a_sprite_01

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.

tut_wws-p1_defining_a_sprite_02

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.

tut_wws-p1_defining_a_sprite_03

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.

tut_wws-p1_defining_a_sprite_04

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.

tut_wws-p1_inserting_a_sprite_01

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.

tut_wws-p1_inserting_a_sprite_02

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.

tut_wws-p1_inserting_a_sprite_03

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.

tut_wws-p1_inserting_a_sprite_04

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:

tut_wws-p1_inserting_a_sprite_05

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

tut_wws-p1_inserting_a_sprite_06

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.

tut_wws-p1_inserting_a_sprite_07

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:

tut_wws-p1_inserting_a_sprite_08

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.

tut_wws-p1_further_size_control_01

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.

tut_wws-p1_further_size_control_02

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.

tut_wws-p1_further_size_control_03

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

tut_wws-p1_further_size_control_04

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

 

The way it works is best explained with a picture:

tut_wws-p1_further_size_control_05

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.

8 Comments

  1. Nice write up Viper. Glad you wrote this, I have worked with the sprite editor and I wish this article was around to save the frustration of figuring out the tool on your own.

    FYI… I am using PNG format in my sprites, no problems that I am aware of. I do sometimes see a clipping effect, but I thought that was more likely due to the occlusion bugs, but it could be the format, I will check it out.

    • Thank you! πŸ™‚ It took longer to get out than I wanted but things came in the way and reduced my time. :/

      I started using PNG files as well – it will actually work. Well, maybe… I then started getting Houston crashes and bugged it, which is when I learned that right now TGA and DSS are the only actually supported formats. Everything else isn’t really and while it might work it may as well not. I recently asked Jon (Bitwise) about the status of the image file formats (for finishing up this tutorial) and he said that it was still the case that TGA and DSS are the only supported formats.

      So yeah, for your own sake I would just switch over before you run into problems with either Houston or the game. πŸ™‚

      • Yeah, I switched everything over to TGA format, and I am no longer seeing clipping issues. My change coincided with Patch 4, so it could have been that, but either way I am satisfied using TGA now.

  2. Not Sure what I am doing wrong, I am 99.9% sure I did the TGA properly, and even later tried the PNG after reading the above comment, but my problem is getting them to view in game. I create the sprite, it shows up in Houston, looks great, the picture style is selected and everything looks as it should in houston, but in game my sprite doesn’t show up. After some frustrating, I borrowed a TGA from another addon that obviously works and the same deal…nothing I add actually makes it in game, but shows up in Houston. So frustrated ATM.

    • How are you loading your XML? If you are using the Apollo.XmlDoc method a linked sprite file in the XML file won’t load, in which case you need to use Apollo.LoadSprites(“Sprites.xml”, “YourPrefix”); to get your sprites into the game.

      …I forgot to add that to the tutorial…:P

    • I agree with Viper, the two mistakes I made when first trying to do a custom sprite was:
      1. Not dragging the red stripe markers. And then also selecting the Stretchy button. You must see the image in Preview above if it is working properly.
      2. Not issuing the LoadSprite function in LUA properly. For me I didn’t need a prefix.
      3. Not including yoursprites.xml file in your addon directly (even though it doesn’t show when you open your addon module).
      4. Forgetting to include the image itself (.tga, .png) in your addon folder. The sprite doesn’t get “decoded” into your sprite.xml

      Hope this helps. Feel free to post some code or a screenshot of your Houston sprite page, maybe we can help.

  3. Has anyone figured out how to get a sprite animation to stop looping yet?

  4. If you’re doing something simple that doesn’t really need Photoshop, Paint.NET creates perfect game-compatible TGA files without any extra effort.

    It’s also very easy to convert PNGs generated in Photoshop into TGAs in Paint.NET, but it may be easier to just fix them in Photoshop.

Leave a Reply

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