During bootup, we’ll be adding all our images via this library, and if you need one later on, ask the library to find it (by idName). This is a collection that contains ALL available Images. Last but not least, we add yet another file called “GxImageLibrary.java”. That’s it for now, just a really simple file. This.texture = new TextureAtlas( this.atlasFilePath ) Public TextureRegion findRegion( String regionName ) ( "GxImage created: "+ idName+" path: "+this.imageFilePath ) Public GxImage( String idName, String imageFilePath, String atlasFilePath ) Now that we have some stuff for testing purposes, let’s proceed with GxImage.java in the Graphics section: A region has (sub-rect) coordinates and an idName that equals the original input filename. This file describes the "regions", where each region is one of the 11 images. The packer tool throws them all together, and generates a single imge file + an atlas descriptor file. In the example above, I made 11 pictures of a (clay orb), to make sort of a "sparkling" animation. It makes a lot sense if you plan to make a tile based map, like this one: If you group/sort your entities on Image, that is. If you have 10 entities all using the same image (but different sub-sections or "regions" of it), only 1 swap is needed. If you render 10 entities with 10 different images, LibGDX (or actually OpenGL) has to swap the active texture 10 times, which isn’t for free. Loading 1 (big) file is more comfortable than loading 10 (small) files. The benefit of that? Computers like bulk stuff. Or just put them all together in the same file. You could create 10 separate image files. Remember your teacher pointing at Eskimo county or Pizza land? Let's say you have 10 different "Crate" objects - thus 10 different images. Sounds like we need an Image class then! We’ll be creating a “GxImage.java” file, which is basically a wrapper around the LibGDX “TextureAtlas” (instead of Image) class.Īn Atlas image is just a bigger picture with multiple smaller images inside. Pretty much every visual entity will be linked to an Image (collection). Resources are typically static (just loaded once, never changing from there on), Entities dynamic (they come and go). After you have created your very first libGDX project, we highly recommend our A Simple Game and Extending the Simple Game pages. In general, try to make your game (classes) in such a way that there will be one resource, that can be used by multiple users (entities). If we have 10 explosive barrels, they can all share the same image(collection), instead of loading there own stuff individually. Second, we don’t want to load the same image many times. Animations on themselves have properties too, like animation-speed, frameCount, and whether the animation is looped or should trigger another animation when it’s done. So we actually need a collection of some sort. But there are two problems with that.įirst, a sprite may need multiple images, and animations. We could simply add a few lines to the class that will load an image and apply that to the sprite. As we saw in earlier code, the LibGDX sprite needs to be connected with an image, something to draw. We were making a Sprite Entity, but it isn’t finished yet.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |