Unpack texturepacker xml1/16/2024 ![]() The people will get their GM:S implementation! It's taking me forever but I'm not going to give up on it. On a side note, I didn't know you could do that in Spriter. That would make sense as that is the file format I'm using to import the data. Gline is the tag where Spriter saves that information. You can drag them from the rulers on the top or left side of the main canvas. ![]() It should only be there if you are using guidelines in Spriter Pro. Sorry I must have missed the question earlier. This is much faster obviously but results in the mass memory usage and multiple textures pages/swaps. You can put the images in the included files which is quick and you can drag folders in there to keep your organization. You can create a sprite in the editor and then import existing images that way which is more efficient but slower to setup Out of them, there are "Sprites" and "Included Files" GM:S has several different types of resources. Just in case anybody gets confused, when I'm talking about importing images dynamically or just loading them in. I've already tried to just dive in coding and sure enough that was a pure mess. Right now I'm just trying to get some ideas on how to move forward with this. If it doesn't go without saying, I'm only in the planning stages right now but I would really like to get something up and running for everybody (me included) as soon as possible. It would be one imported sprite, one texture page, one texture swap. Is it possible to get all the images into a sprite sheet and then have the SCML file reference images from that? That would make it MUCH quicker when setting up a project since you could just import the single sprite sheet and then just draw the part that you need in GM:S. I remember seeing something about TexturePacker in Spriter but I'm not sure what that is all about. That would unfortunately result in a longer setup time compared to most other implementations but that's just one of the many quirks of working with GM:S The best solution I can think of is only pulling out the skeleton data and then loading the images directly into GM:S. Not really sure what happened there. It won't be hard to make a simple XML parser though, so that's not as big of an issue. I thought I was going to get lucky with the parser by using the built-in json_encode/json_decode functions in GM:S but that turned into a good laugh as GM tried to make a 1.5 TB ds map and damn near froze my computer. This turns into terrible performance with GM:S, especially once your characters start getting more complex. Then say you're drawing all ten of those sprites to render your skeleton, that results in ten texture swaps every draw update. Which means if you import ten images, you've created ten texture pages. When you add an image dynamically in GM:S it adds a new texture page to the resources. ![]() The biggest problem with using Spriter and GM:S together is the way GM:S works with external images. I would love to make a plugin for GM:S but first I need to address some issues. ![]()
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |