Using Zwoptex is really easy. Just point your browser to www.zwoptexapp.com/flashversion/. Once there, Zwoptex opens, and you can start creating your sprite sheet. The first step is to import images. Another similar tool is Zwoptex (The latter is Mac software, but TP has a version for Windows too.).
Corona Textmate Bundle. Aug 1 st, 2011 3:14 pm. The Corona Bundle for TextMate is designed to help TextMate users code their Corona apps more quickly. It contains a large number of autocomplete terms, commands, and snippets that make it that much easier to access the various Corona APIs using the standard TextMate keyboard/menu shortcuts. 5 Simple Sprite Editor 187. 6 Gumstring 109. 8 Darkfunction 107. 11 Sprite Atlas Tool 28. 12 SpriteMapper 28. 7 more; Pixel Art Tools. 4 Pyxel Edit 240. 6 GraphicsGale 127. 7 Pro Motion 93. 9 Sprite Lamp 37.
//TextureAtlas for andengine |
// Billy Lindeman (billy@zoa.io) |
// 2011 Protozoa, LLC |
//loads texture atlas from Zwoptex Generic plist file |
//you pass it the name of the asset (without extension) |
//it will load .plist as the coordinates and .png as the texture |
//requires https://github.com/tenaciousRas/android-plist-parser |
packageorg.anddev.andengine.opengl.texture.atlas; |
importjava.io.IOException; |
importjava.io.InputStream; |
importjava.util.HashMap; |
importjava.util.Map; |
importjava.util.Scanner; |
importorg.anddev.andengine.engine.Engine; |
importorg.anddev.andengine.opengl.texture.Texture; |
importorg.anddev.andengine.opengl.texture.TextureOptions; |
importorg.anddev.andengine.opengl.texture.region.TextureRegion; |
importorg.anddev.andengine.opengl.texture.source.AssetTextureSource; |
importcom.longevitysoft.android.xml.plist.PListXMLHandler; |
importcom.longevitysoft.android.xml.plist.PListXMLHandler.PListParserListener; |
importcom.longevitysoft.android.xml.plist.PListXMLHandler.ParseMode; |
importcom.longevitysoft.android.xml.plist.PListXMLParser; |
importcom.longevitysoft.android.xml.plist.domain.Dict; |
importcom.longevitysoft.android.xml.plist.domain.PList; |
importcom.longevitysoft.android.xml.plist.domain.PListObject; |
importandroid.content.Context; |
importandroid.content.res.AssetManager; |
publicclassTextureAtlasimplementsPListParserListener{ |
//constructor values |
privateEngine mEngine; |
privateContext mContext; |
privateString mName; |
//texture info |
privateint sizeX,sizeY; |
publicTexture mTexture; |
//textureregion container |
privateHashMap<String,TextureRegion> mRegions =newHashMap<String,TextureRegion>(); |
publicTextureAtlas (ContextpContext, EnginepEngine, StringsAssetName) throwsIOException { |
//store constructor values |
this.mEngine = pEngine; |
this.mContext = pContext; |
this.mName = sAssetName; |
//create input stream for asset |
AssetManager pAssetManager = pContext.getAssets(); |
InputStream asset = pAssetManager.open(sAssetName+'.plist'); |
//create plist handler |
PListXMLHandler plistHandler =newPListXMLHandler(); |
plistHandler.setParseListener(this); |
//parse plist |
PListXMLParser plistParser =newPListXMLParser(); |
plistParser.setHandler(plistHandler); |
plistParser.parse(asset); |
} |
//helper function to grab a region from a keyname |
publicTextureRegionregionForKey(Stringkey) { |
//return key, or illegal state |
if(mRegions.containsKey(key)) { |
return mRegions.get(key); |
}else { |
thrownewIllegalStateException(); |
} |
} |
//initialize the texture to hold our atlas |
privatevoidinitalizeTexture() { |
AssetTextureSource atlasSource =newAssetTextureSource(mContext, mName+'.png'); |
this.mTexture =newTexture(sizeX, sizeY, TextureOptions.BILINEAR_PREMULTIPLYALPHA); |
mTexture.addTextureSource(atlasSource, 0, 0); |
mEngine.getTextureManager().loadTexture(this.mTexture); |
} |
//once plist is loaded, we parse the values and init our regions |
publicvoidonPListParseDone(PListpList, ParseModemode) { |
//grab root element |
Dict root = (Dict) pList.getRootElement(); |
//load size from metadata |
Dict metadata = root.getConfigurationObject('metadata'); |
String tSize = metadata.getConfiguration('size').getValue(); |
String tSizes[] = tSize.substring(1,tSize.length()-1).split(', '); |
this.sizeX =newInteger(tSizes[0]); |
this.sizeY =newInteger(tSizes[1]); |
//now that we've loaded the sizes, init the texturesource |
this.initalizeTexture(); |
//parse our frame info and store in map |
Dict frames = root.getConfigurationObject('frames'); |
Map<String,PListObject> frameMap = frames.getConfigMap(); |
//loop each frame and create the texture region |
for(String key : frameMap.keySet()) { |
//parse rect coords from dictionary |
Dict fDict = (Dict)frameMap.get(key); |
String sRect = fDict.getConfiguration('textureRect').getValue(); |
String aRect[] = sRect.substring(2,sRect.length()-2).split(', '); |
int rX =newInteger(aRect[0]); |
int rY =newInteger(aRect[1].substring(0,aRect[1].length()-1)); |
int rWidth =newInteger(aRect[2].substring(1)); |
int rHeight =newInteger(aRect[3]); |
//create new textureRegion and store it in hashmap |
mRegions.put(key, newTextureRegion(this.mTexture, rX, rY, rWidth, rHeight)); |
} |
} |
} |
Home > Articles > Mobile Application Development & Programming
Chapter 5, 'Image Rendering,' was large and covered a number of complex concepts. Having done all that hard work, and with the classes in place for representing and rendering images, we can move on to the other components needed in the game engine for Sir Lamorak's Quest.
As the title suggests, this chapter is all about sprite sheets. If you remember from Chapter 2, 'The Three Ts: Terminology, Technology, and Tools,' a sprite sheet is a large image that contains a number of smaller images.
There are two key benefits to using sprite sheet, as follows:
This chapter reviews the SpriteSheet and PackedSpriteSheet classes and shows how to extract specific images from within a larger image sprite sheet.
As mentioned in Chapter 2, there are two different types of sprite sheets, as follows:
For Sir Lamorak's Quest, we are going to be using both kinds of sprite sheets. Although it is possible to merge both the simple and complex sprite sheet functionality into a single class, I have split them into two different classes to make things easier to understand. Basic sprite sheets are handled in a class called SpriteSheet, whereas the PackedSpriteSheet class handles complex sprite sheets.
Another term for a sprite sheet is a texture atlas, but I will continue to use the old-school term of 'sprite sheet' throughout this book.
The SpriteSheet class takes the image provided and chops it up into equally sized sub-images (sprites). The dimensions to be used when dividing up the sprite sheet will be provided when a new sprite sheet is instantiated. Information is also provided about any spacing that has been used within the provided sprite sheet image. Spacing is an important property within a sprite sheet. Without going into detail, when defining texture coordinates within an image for OpenGL ES, it is possible to sample a pixel beyond the edge of the texture you are defining. This can cause your textures to have an unwanted border that is made up of pixels from the image around the image defined with your texture coordinates. This is known as texture bleeding.
To reduce the risk of this happening, you can place a transparent border around each image within a sprite sheet. If OpenGL ES then goes beyond the edge of your texture, it will only sample a transparent pixel, and this should not interfere with the sprite you have defined. Zwoptex1 enable you to specify the number of pixels you would like to use as a border around your sprites. Figure 6.1 shows a simple sprite sheet image with single pixel border between each sub-image. If you are drawing non-square triangles, the spacing may need to be more than one pixel to help eliminate texture bleeding.
Figure 6.1 Sprite sheet with spacing between each sprite.
In terms of how we are going to access the sprites on a simple sprite sheet, we're going to use its grid location. A simple sprite sheet makes a nice grid because all the images are the same size. This makes it easy to retrieve a sprite by providing its row and column number. Figure 6.2 shows a sprite sheet of twelve columns and three rows with the sprite at location {5, 1} highlighted.
Figure 6.2 Sprite sheet grid with location {5, 1} highlighted.
The PackedSpriteSheet class takes an image and the name of the control file. The control file is parsed to obtain the location and size of every sprite within the sprite sheet image.
The control file is the key difference between a basic (SpriteSheet) and complex (PackedSpriteSheet) sprite sheet. With the basic sprite sheet, you can work out where each sprite is by performing a simple calculation using its grid position. This is harder to do with a complex sprite sheet because the sprites can be different sizes and are often placed randomly throughout the image to make the best use of space.
To help identify the coordinates of the sprites in a complex sprite sheet, the control file provides information on where each sprite is located inside the sprite sheet, along with its dimensions. The control file also gives each image a key, usually the name of the image file of the original sub-image, which then allows the PackedSpriteSheet class to reference each sprite. Figure 6.3 shows the complex sprite sheet that we use in Sir Lamorak's Quest.
Figure 6.3 Complex sprite sheet from Sir Lamorak's Quest.
As you can see from Figure 6.3, a complex sprite sheet has many images that are all different sizes and shapes—thus the need for a control file to make sense of it all.
You could create your own control file for these files, providing the information on the pixel locations within the image and its dimensions, but to be honest, that is a really tedious job. Luckily for us, there are tools that can help.
The Zwoptex tool (mentioned earlier, and discussed in Chapter 2) is one such tool. It not only produces a PNG image of the generated sprite sheet, but it also creates the control file you need to identify the individual images within.
Zwoptex has a number of different algorithms that can help pack images, but it also enables you to move the images around, making it possible for you to pack as many images as possible into a single sheet. There are some good algorithms out there for optimizing the packing of variably sized images, but you'll always get the best results doing this manually.
Figure 6.4 shows the flash version of Zwoptex editing the complex sprite sheet.
Figure 6.4 The Flash-based Zwoptex tool, used for editing a complex sprite sheet.
Zwoptex has three different outputs, as follows:
The thing I like the most about Zwoptex is that it gave me the control file as a plist file. Although you can obviously handle raw XML if needed (or any other format, for that matter), having a plist file makes things so much easier (and I like to take the easy route whenever possible).
Now that you know what Zwoptex is, let's show you how to use it.