![]() ![]() Rather than having to produce two versions of your graphics files and use TexturePacker twice to export separate sprite sheets for retina and non-retina, you are able to tell TexturePacker to do all of this for you. This is where the ‘Scaling Variants’ feature comes in useful. MonoGame will automatically load the version when run on a retina device. If you are targeting iOS with MonoGame then this is no different. Those who have done iOS development before will know that you should create two versions of your graphics – a high resolution version for retina screens and a ‘normal resolution’ graphics file for non-retina screens – and by appending to the end of the retina file, iOS will take care of ensuring the appropriate graphics file is used at run-time. In a later section within this tutorial I will walk you through creating a MonoGame app, targeting iOS, using Xamarin Studio. I will explain the few that we will use in this tutorial, however an extensive set of documentation can be found here. Now, the final steps, before hitting the ‘publish’ button to create your sprite sheet data, is to alter a few settings depending on your requirements. Immediately you’ll see that TexturePacker has grouped all the images together, as below… (For the purposes of this tutorial I am using a set of images from my demonstration project on GitHub here). Then drag and drop the parent folder into TexturePacker. Next gather your individual images together into a logical folder structure. Select the MonoGame option and then ‘Create Project’ to move forward… You’ll be presented with a screen like below… ![]() This means that all the hard work of loading the sprite sheet and rendering the correct frame is taken care of for you – as described further below…įirst step – Download a copy of TexturePacker from here and load it up. ![]() Now the above maybe nothing new to a lot of people, however what you might not know, is that the latest version of TexturePacker has an option for exporting the sprite sheet and data file in a format targeted at MonoGame – along with access to source code for loading and handling the resultant data files within your MonoGame app. SpriteSheets – TheMovie – Part 1 by CodeAndWeb ![]() (See this fun video from the makers of TexturePacker that explains it better than I can) Using a single sprite sheet is much more efficient than loading lots of individual images in game development. The idea is that you draw the individual frames of animation for your game characters as separate image files – and then drag and drop them into TexturePacker – whereupon you end up with a single image file and accompanying data file ready to load into your game. I’ve mentioned TexturePacker in a previous blog post however, for those that haven’t used it before, it is a very easy to use application for creating Texture Atlases / Sprite Sheets. Also a link will be provided to the source code. May be we need to give some more thoughts on its implementation.Hello! It’s been far too long since my last blog post, however I’ve had nothing interesting to say – that is until now! Today I will talk about the latest version of TexturePacker, which has a new export option specifically for MonoGame – thus allowing you to easily create animations within your MonoGame apps.įor those who just want to see the results straight away, here is a video of the iOS simulator running a MonoGame animation produced with the help of TexturePacker…īelow I will walk you through how to produce the above application. As, distributed animation frames makes less sense to me as its hard to read, hard to combine and hard to troubleshoot. This will actually gives a lot of clarity to the developers and artists. So, something like the root sheet contains all the animations and related mutipacks contains the frames only and do not have anything for animations object at all. As in the POC that I shared, I myself added the run: animation here. since at the end PIXI is holding the map of the Textures so, it really doesn't matter if it is coming from shee-1.json or sheet-2.json. I was just thinking that may be one of the easy implementation is if the root spritesheet contains the animation array. This means all you need to do is ensure every spritesheet contains an animation object with all frames that relate to the information, *even if its just one frame in the file.Īs per it will load the asset if there is related_multi_packs even if it contains a single sprite. (spritesheetname).load(setup) Ĭonst referencedSpriteSheet = Ĭonst multiPack = _multi_packs load sprite sheet image + data file, call setup() if completed ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |