Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
10. June 2013


The Apple World Wide Developer conference is currently going on and generally there isn’t all that much of interest to game developers.  This year is a bit of an exception as they added SpriteKit to OSX Maverick (10.9) as well as an upcoming release of iOS.  SpriteKit seems to be a combination of sprite library and physics engine.  In their own words:

Sprite Kit provides a graphics rendering and animation infrastructure that you can use to animate arbitrary textured images—sprites. Sprite Kit uses a traditional rendering loop that allows processing on the contents of each frame before it is rendered. Your game determines the contents of the scene and how those contents change in each frame. Sprite Kit does the work to render frames of animation efficiently using the graphics hardware. Sprite Kit is optimized to allow essentially arbitrary changes to each frame of animation.

Sprite Kit also provides other functionality that is useful for games, including basic sound playback support and physics simulation. In addition, Xcode provides built-in support for Sprite Kit, allowing complex special effects and texture atlases to be easily created and then used in your app. This combination of framework and tools makes Sprite Kit a good choice for games and other apps that require similar kinds of animations. For other kinds of user-interface animation, use Core Animation instead.

Followed by:

Sprite Kit is available on iOS and OS X. It uses the graphics hardware available on the hosting device to efficiently composite 2D images together at high frame rates. Sprite Kit supports many different kinds of content, including:

  • Untextured or untextured rectangles (sprites)

  • Text

  • Arbitrary CGPath-based shapes

  • Video

Sprite Kit also provides support for cropping and other special effects, allowing these effects to be applied to all or a portion of the content. All of these elements can be animated or changed in each frame. You can also attach physics bodies to these elements so that they properly support forces and collisions.

By supporting a rich rendering infrastructure and handling all of the low-level work to submit drawing commands to OpenGL, Sprite Kit allows you to focus your efforts on solving higher-level design problems and creating great gameplay.

So basically it’s a 2D game engine competing with the likes of Cocos2D.  Of course, if you use SpriteKit you will be tied to iOS/OS/X and the newest release at that.  If you are an Apple only shop, this isn’t a big deal, but if you work cross platform or are targeting older hardware, this new library is pretty much useless for now.


If you have an Apple ID, you can log in and read the documentation here.


27. May 2013


In this day and age almost all graphics engines are behind the curtain based on 3D.  It's just the way graphics hardware works, so we now deal with textures instead of pixels  SpriteProjectand sprites.  At the end of the day, almost every single 3D game engine get a 2D sprite engine created on top off it, and now jMonkeyEngine is no exception with the release of The Sprite Project.


In case you have never heard of it, jMonkeyEngine is a complete Java based 3D engine, that is quite mature ( version 3+, over a decade old! ) and completely open source.  The Sprite Project is a 2D sprite engine built over top of it.  Here is a sample application taken from the documentation(pdf link).


package mygame;


public class Main extends SimpleApplication {

static Main app;

public static void main(String[] args) {
  app = new Main();

static SpriteEngine engine = new SpriteEngine();

public void simpleInitApp() {
  Sprite sprite = new Sprite(“Textures / Sprite.png”, “Sprite 1”, assetManager,
    true, true, 9, 1, 0.15f, “Loop”, “Start”);
  SpriteLibrary.l_guiNode = guiNode;
  SpriteLibrary library = new SpriteLibrary(“Library 1”, false);

public void simpleUpdate(float tpf) {

Pretty simple looking eh?

So if you are looking for a 2D sprite library built on top of a great Java 3D engine, you need look no further.

6. February 2013

As we reported back in december, Torque2D was going open source.  Well, the day has finally arrived, Torque2D's source code is up on Github now.

Torque2D Logo



So what is Torque2D?  It is a 2D cross platform game engine, previously under a commercial license.  I will let them describe their baby:



In simple terms, Torque 2D is an extremely powerful, flexible, and fast engine dedicated to 2D game development. The following is a breakdown of the core facts about the engine:

Currently supported platforms:
* Windows
* OS X
* iOS

Support for new platforms is surely on the way. In fact, YOU get to help us decide what we should work on, be it Linux, Android, editors, or just simple bug fixing. 

* Core: C++
* Windows: C++ and Windows API
* OS X: C++, Objective-C, and Cocoa API
* iOS: C++, Objective-C, and Cocoa touch API

Main Features:
* Box2D physics
* Simple and flexible sprite system
* Composite system capable of rendering thousands of images and animations with little performance impact
* Integrated asset system that manages all your asset loading and unloading in an optimized manner
* Flexible module system that makes rapid prototyping a snap and code reusability a simple matter
* TexturePacker Support
* TAML serialization format (like XAML and XML)
* Batched rendering
* Multiple collision shapes
* Built-in unit testing framework, cross platform
* Solid behavior system for packaging reusable game logic that can be applied to multiple sprites in different projects

In addition to the core engine languages, you can script all your game play via TorqueScript. This is a C-like syntax language that is very simple to learn and utilize for your projects. Additionally, persistent files such as particles, levels, GUIs, and more are stored as "TAML" (Torque Application Markup Language). If you have ever edited XML or XAML in the past, you should feel more than comfortable with TAML.

Blazing Speed
Blazing fast performance on Windows, OS X, and iOS. On desktop platforms, you can have thousands of sprites, particles, and physics objects running at once without ever dipping below the 60 fps mark. While more limited, iOS hardware can run the engine at a solid 60 fps, even with hundreds of objects interacting on screen.


Very cool move open sourcing this GarageGames, I hope it works out for you.


You can read the complete announcement here.

7. May 2012


As the title suggests, this thread is going to be about using sprite sheets with PS Studio.  For those of you unfamiliar with the term, a spritesheet is a single image with multiple sprites.  You generally group your sprites together on a single sheet as it is much more efficient for loading and generally performs better than loading one texture per sprite.


EDIT(5/11/2012): If you are working with an actual Vita device and using the beta SDK, there is a bug on the Vita XML that prevents this from working. Read this post for a simple workaround. Hopefully in time Sony fixes this and you no longer need to apply the bug fix. Note, the problem only occurs on an actual device.


Instead of showing you how to generate a spritesheet, I am going to recycle a previous post I made on creating a spritesheet using Daz3D.  Fortunately Daz Studio is still available for free if you want to follow along.  Of course you can create your spritesheet however you want, or can simply download a freely available spritesheet such as those available at  Or of course you can just use my sheet which will be available later.


In this example, I am going to use a different program than the GIMP for assembling the spritesheet.  The end result of my Daz tutorial is a directory full of 128x96 images like these:




You can download a zipped copy of the sprites I rendered right here.


I generated 19 frames of walking animation in each direction.  This time I am going to use the free version of the tool TexturePacker to generate my sheet.  Download and fire up TexturePacker and you will be greeted with this interface:




The first thing you want to do is add your sprites to the sprite palette. You can either drag and drop the folder ( using Windows Explorer ) containing your sprites to the sprite panel on the right or hit the Add Sprites button and select the sprites individually.  Add all of the sprites you just created in Daz3D ( or the folder you downloaded and unzipped ) using either method.  Dropping a folder will automatically add those sprites in a folder by that name keeping things a bit more organized.  Here is the results of me dropping my walkCycle folder on the sprites panel:




As you can see, it added all of the sprites under a folder named WalkCycle and automatically layed out our sprite sheet as efficiently as possible.  As this point though, we don’t really care all that much about efficiency, so we are going to make a few small changes.  In the Texture Settings panel we want to fill in a couple options.  First drop down DataFormat and change it to “Generic XML”.  Next, under Data File, pick a directory and filename to save your sprite sheet, I choose c:\temp\walk.xml.  This will automatically set the texture file to c:\temp\walk.png.  Otherwise, these are the settings I used:





You of course can use whatever settings you want, but if you want exactly the same results as me, use the above.  Now that you are ready, hit the publish button.



The end result is a PNG file and an XML document. 


The resulting image file:




You can download the generated image file here.


It also generated an XML file with all of the sprite details.  The contents of that XML file look like:


<?xml version="1.0" encoding="UTF-8"?> <!-- Created with TexturePacker> <!-- $TexturePacker:SmartUpdate:a6e51795dbe6b13cd639951a1f67241c$ --> <!--Format: n => name of the sprite x => sprite x pos in texture y => sprite y pos in texture w => sprite width (may be trimmed) h => sprite height (may be trimmed) oX => sprite's x-corner offset (only available if trimmed) oY => sprite's y-corner offset (only available if trimmed) oW => sprite's original width (only available if trimmed) oH => sprite's original height (only available if trimmed) r => 'y' only set if sprite is rotated --> <TextureAtlas imagePath="walk.png" width="512" height="960"> <sprite n="Walk_left00" x="0" y="0" w="128" h="96"/> <sprite n="Walk_left01" x="128" y="0" w="128" h="96"/> <sprite n="Walk_left02" x="256" y="0" w="128" h="96"/> <sprite n="Walk_left03" x="384" y="0" w="128" h="96"/> <sprite n="Walk_left04" x="0" y="96" w="128" h="96"/> <sprite n="Walk_left05" x="128" y="96" w="128" h="96"/> <sprite n="Walk_left06" x="256" y="96" w="128" h="96"/> <sprite n="Walk_left07" x="384" y="96" w="128" h="96"/> <sprite n="Walk_left08" x="0" y="192" w="128" h="96"/> <sprite n="Walk_left09" x="128" y="192" w="128" h="96"/> <sprite n="Walk_left10" x="256" y="192" w="128" h="96"/> <sprite n="Walk_left11" x="384" y="192" w="128" h="96"/> <sprite n="Walk_left12" x="0" y="288" w="128" h="96"/> <sprite n="Walk_left13" x="128" y="288" w="128" h="96"/> <sprite n="Walk_left14" x="256" y="288" w="128" h="96"/> <sprite n="Walk_left15" x="384" y="288" w="128" h="96"/> <sprite n="Walk_left16" x="0" y="384" w="128" h="96"/> <sprite n="Walk_left17" x="128" y="384" w="128" h="96"/> <sprite n="Walk_left18" x="256" y="384" w="128" h="96"/> <sprite n="Walk_right00" x="384" y="384" w="128" h="96"/> <sprite n="Walk_right01" x="0" y="480" w="128" h="96"/> <sprite n="Walk_right02" x="128" y="480" w="128" h="96"/> <sprite n="Walk_right03" x="256" y="480" w="128" h="96"/> <sprite n="Walk_right04" x="384" y="480" w="128" h="96"/> <sprite n="Walk_right05" x="0" y="576" w="128" h="96"/> <sprite n="Walk_right06" x="128" y="576" w="128" h="96"/> <sprite n="Walk_right07" x="256" y="576" w="128" h="96"/> <sprite n="Walk_right08" x="384" y="576" w="128" h="96"/> <sprite n="Walk_right09" x="0" y="672" w="128" h="96"/> <sprite n="Walk_right10" x="128" y="672" w="128" h="96"/> <sprite n="Walk_right11" x="256" y="672" w="128" h="96"/> <sprite n="Walk_right12" x="384" y="672" w="128" h="96"/> <sprite n="Walk_right13" x="0" y="768" w="128" h="96"/> <sprite n="Walk_right14" x="128" y="768" w="128" h="96"/> <sprite n="Walk_right15" x="256" y="768" w="128" h="96"/> <sprite n="Walk_right16" x="384" y="768" w="128" h="96"/> <sprite n="Walk_right17" x="0" y="864" w="128" h="96"/> <sprite n="Walk_right18" x="128" y="864" w="128" h="96"/> </TextureAtlas>


You can download the xml file here. This XML file contains the details about how our original sprites are arranged within the sprite sheet and will prove useful in a moment.


Alright, now that we have our spritesheet and our sprite map XML file, lets fire up PSSuite and get down to some coding.  This tutorial assumes you have already gone through my earlier tutorials, at the very least the two Hello World tutorials.


Now create a new solution in PlayStation Studio, I called mine SpriteSheet.  We need to add a couple of references right away, add a reference to GameEngine2D, System.Xml and System.Xml.Linq. Now add your spritesheet png and xml files to the project, right click them and set their build action to content.



First we are going to create our gameloop in AppMain.cs.  I want to point something out right away… this is not the way you handle game events!  So the way things are done in this example are *NOT* the way we will do things in the future.  I went this route because you are already familiar with most of the code here.  In a (very near) future tutorial, I will show the “proper” way to handle updating game objects.


With that warning in place, lets take a look at AppMain.cs


using System; using System.Collections.Generic; using Sce.Pss.Core; using Sce.Pss.Core.Environment; using Sce.Pss.Core.Graphics; using Sce.Pss.Core.Input; using Sce.Pss.HighLevel.GameEngine2D; namespace SpriteSheet { public class AppMain { private static Walker walker; public static void Main (string[] args) { Director.Initialize(); Director.Instance.GL.Context.SetClearColor(255,255,255,0); walker = new Walker("walk.png","walk.xml"); var scene = new Scene(); scene.Camera.SetViewFromViewport(); var sprite = walker.Get("Walk_left00"); sprite.Position = scene.Camera.CalcBounds().Center; sprite.CenterSprite(); sprite.Scale = new Vector2(2,2); scene.AddChild(sprite); Director.Instance.RunWithScene(scene,true); System.Diagnostics.Stopwatch timer = new System.Diagnostics.Stopwatch(); int spriteOffset = 0; timer.Start(); bool walkLeft = true; while(true) { if(timer.ElapsedMilliseconds > 100f) { string spriteName; if(walkLeft) spriteName= "Walk_left" + spriteOffset.ToString("00"); else spriteName= "Walk_right" + spriteOffset.ToString("00"); sprite.TileIndex2D = walker.Get (spriteName).TileIndex2D; if(spriteOffset >= 18) { spriteOffset = 0; walkLeft = !walkLeft; } else spriteOffset++; timer.Reset(); timer.Start(); } Sce.Pss.HighLevel.GameEngine2D.Director.Instance.Update (); Sce.Pss.HighLevel.GameEngine2D.Director.Instance.Render(); Sce.Pss.HighLevel.GameEngine2D.Director.Instance.GL.Context.SwapBuffers(); Sce.Pss.HighLevel.GameEngine2D.Director.Instance.PostSwap(); } } } }

Click here to download AppMain.cs


Most of the concepts in this code we’ve seen in a previous tutorial, so I will only highlight the new details.  First thing is we declare a Walker object, this is a class we are going to create shortly that is going to handle our sprite sheet.  As you can see, the Walker constructor takes the file name of the sprite texture and xml file you created earlier as parameters. 


Most of the remainder of this initial code is a matter of setting up our scene and sprite objects just like we did in Hello World.  A key difference is we are getting the sprite from our walker object instead of creating it from scratch or loading it from file.  The line:

sprite.Scale = new Vector2(2,2);

Is simply to double the size of our sprite in the viewport to see it better, you can easily remove this if you wish.


We create a Stopwatch ( a .NET object ) and start it counting up, then enter our infinite game loop.  Lets take a look at the new logic in our game loop


if(timer.ElapsedMilliseconds > 100f) { string spriteName; if(walkLeft) spriteName= "Walk_left" + spriteOffset.ToString("00"); else spriteName= "Walk_right" + spriteOffset.ToString("00"); sprite.TileIndex2D = walker.Get (spriteName).TileIndex2D; if(spriteOffset >= 18) { spriteOffset = 0; walkLeft = !walkLeft; } else spriteOffset++; timer.Reset(); timer.Start(); }


This is basically the “guts” of our game loop.  What we are doing here is waiting for the timer to reach 1/10th of a second.  Every tenth of a second we want to move on to the next frame of animation.  However we have only 19 ( walk_left00 to walk_left18 ) frames of animation in each direction and once we hit the end of our walk cycle, we want to walk in the other direction.  So what we do here is loop through each frame of animation until we hit walk_left18 or walk_right18, at which point we flip directions by inverting the value of the walkLeft bool.  This results in changing the spriteName text prefix, otherwise we simply increment to the next frame.  Then we start our timer over again to begin the process again a tenth of a second later.  One more time, this is not the proper way to handle updates!


The key line in all of that was:

sprite.TileIndex2D = walker.Get (spriteName).TileIndex2D;


This line actually tells our sprite to refer to a different sprite within our spritesheet, causing the animation.  That will make more sense in a second when we look at the code for Walker.cs.  Speaking of which, lets create it now!


To create a new cs file we either click the New icon ( image) or hit CTRL + N.  In the resulting dialog select General on the left, Empty Class on the right and name it Walker.cs, like such:




Now open up Walker.cs and enter the following code:


using System; using System.Linq; using System.Xml; using System.Xml.Linq; using System.Collections.Generic; using Sce.Pss.Core.Graphics; using Sce.Pss.HighLevel.GameEngine2D; using Sce.Pss.HighLevel.GameEngine2D.Base; namespace SpriteSheet { public class Walker { private TextureInfo _textureInfo; private Texture2D _texture; private System.Collections.Generic.Dictionary<string,Sce.Pss.HighLevel.GameEngine2D.Base.Vector2i> _sprites; public Walker (string imageFilename, string imageDetailsFilename) { XDocument doc = XDocument.Load ("application/" + imageDetailsFilename); var lines = from sprite in doc.Root.Elements("sprite") select new { Name = sprite.Attribute("n").Value, X1 = (int)sprite.Attribute ("x"), Y1 = (int)sprite.Attribute ("y"), Height = (int)sprite.Attribute ("h"), Width = (int)sprite.Attribute("w") }; _sprites = new Dictionary<string,Sce.Pss.HighLevel.GameEngine2D.Base.Vector2i>(); foreach(var curLine in lines) { _sprites.Add(curLine.Name,new Vector2i((curLine.X1/curLine.Width),9-(curLine.Y1/curLine.Height))); } _texture = new Texture2D("/Application/" + imageFilename,false); _textureInfo = new TextureInfo(_texture,new Vector2i(4,10)); } ~Walker() { _texture.Dispose(); _textureInfo.Dispose (); } public Sce.Pss.HighLevel.GameEngine2D.SpriteTile Get(int x, int y) { var spriteTile = new SpriteTile(_textureInfo); spriteTile.TileIndex2D = new Vector2i(x,y); spriteTile.Quad.S = new Sce.Pss.Core.Vector2(128,96); return spriteTile; } public Sce.Pss.HighLevel.GameEngine2D.SpriteTile Get(string name) { return Get (_sprites[name].X,_sprites[name].Y); } } }

Click here to download Walker.cs


Our Walker class is in charge of loading and handling our spritesheet.  TextureInfo and Texture2D you have already been exposed to and in this case, nothing is different here.  Next up we declare a Dictionary of <string,Vector2i> named _sprites.  The Vector2i type is declared in GameEngine2D.Base and is simple a pair of ints. _sprites is used to store the x,y location of each individual sprite in our spritesheet, accessed by the sprites filename.


Let’s take a look first at the constructor.  This code is pretty straight forward if you have ever worked with Linq or XML.  We are simply opening our XML file, the filename of which we passed in from AppMain.  Note that we added “application/” to our paths, all your files on Vita are located under this subdirectory.  Next we read the XML file and extract each <sprite> entry into a new anonymous type composed of Name, X1, Y1, Height and Width.  Name represents the file name of the source image, X1 and Y1 represent the pixel coordinates within the generated spritesheet, while Height and Width are the dimensions of the sprite within the sprite sheet.  Given that all of our sprites are the same size, these values are of little importance.


Now that we’ve parsed out our XML file, we populate our _sprites dictionary using these values ( minus height and width which we don’t need past this point ).  However, we don’t actually want the x and y pixel coordinates of our image, but instead the offset within the spritesheet texture.  We can determine this value by dividing the X and Y values by the sprite Width and Height respectively.  Keep in mind, this works because all our sprites are the same size ( 128x96 ) and would require different logic if you had sprites of differing sizes in your sprite sheet.  You may notice I subtract 9 from the height value… this is because GameEngine2D SpriteTile’s locations start from the bottom left instead of the top left!  I prefer top right and this is how I generated the sheet, so invert the values.  If you design your sprite sheets to start at the bottom left ( so the first frame is at the bottom left corner ), you wont need to perform this calculation.  Now you may be wondering… why 9?  Well that’s the number of sprites we have in each row on the sprite sheet (10, counting from 0 equals 9).


Finally we load our texture using the filename we passed in to the constructor.  Again we prepend “Application/” to our filename.  The last thing of note here is the second value in our TextureInfo constructor.  This Vector2i informs the TextureInfo the dimensions of our sprite sheet, telling it at there are 4 columns of 10 rows of sprites.  It doesn’t matter that the last row isn’t full of sprites ( there are only 2 in the spritesheets bottom row ), if you try to access them you will simply get an empty space or whatever the background colour of your spritesheet is.


Our destructor is nothing special, just cleans up like a good little citizen should.  Remember it’s your responsibility to dispose of any objects you own and are no longer using.  C# is garbage collected, but its still easy to run out of memory in a hurry if you don’t keep things tidy.


Finally we have a pair of Get() methods.  The one takes a sprite name, looks it up in our _sprite dictionary, retrieves the X and Y offset of the sprite within the texture, then passes those values into the other Get() method.  This Get() method then creates a new SpriteTile assigning it our already created _textureInfo.  Next it sets the tiles index within the texture using the passed in coordinates to represent our currently selected sprite, sets the tiles dimensions to 128x96 (pixels) and returns our sprite.  Please notice there is absolutely no error checking or handling here in order to keep things short.  You really should have a wee bit more error checking in your own code! Winking smile


The end result of all this activity:





Click here to download the entire project source. In addition to the full project source, the zip also includes all the image files used in this tutorial.


29. December 2011




This week’s cool thing isn’t new, not even close in fact.  It is actually 3 years old and has a fewimage thousand alternatives, also freely available.  So then, why the hell am I show casing it?  Frankly because a) it’s damned good work b) programmers are always looking for alternatives to programmer art and this is the perfect source!



Without further ado, let me present to you a Free Airplane Sprite Pack (download link). Years ago, 2008 in fact, Gamedev user Prinz Eugn released a selection of hand painted airplane sprites for free use in this thread.  I mention it again because the links have recently been re-established.  The work is very good, much better than a lot of freely available sprite art and includes a number of angles and frames to work with.  Below is one such sample sprite sheet:





So, if you are looking at creating a 2D game and are looking for some artwork to start out with, this is a very good place to start.  It is a lot easier to keep yourself motivated when your game looks good.


Again, the download link.



EDIT: As was rightly pointed out in the comments, there is a condition on using the sprites.  If you use them in a released product, contact and credit the author.  I think you will agree this is a very small thing to ask.  For more details on the author, you can see more of his work here or you can ( or at least, could ) email him at prinz_eugn [@]  Frankly, if you use his sprites even in a non-shipping project, I highly recommend you send him even just a quick "thanks man!" email.  In running this site I have received some of those and I can't begin to explain how nice they are to receive. 






Cool Thing of the Week

GFS On YouTube

See More Tutorials on!

Month List