hippyman

Another long break and I'm back again.... I've found a framework that solves the external image texture page issue I spoke of previously and JSON seems to work better in GM:S so I'm messing with this again. I'm just curious about one thing at the moment. Is the "interval" tag in animations the "playback speed" of the animation? EDIT: Also I noticed I did ask but I never got an answer. What is the "gline" tag used for? It's always empty

I've actually been reading up on it and I'm getting better with DLLs and GM:S. I think using the C++ implementation will be possible. I will have to make some changes but I have some ideas that I'm going to try out. I'll be sure to keep you guys updated if I figure something out.

I'm taking yet another stab at this and I'm curious about something in the scon files. What is the gline variable found in animations used for? It's always empty from what I've seen so far. I'm also interested in possibly using the C++ implementation and making a DLL extension for GM. The only downside is it would be Windows only but it would have much better performance since C++ would be handling the most of it and GML would simply retrieve data from it. I'm also not very experienced with C++ so any help would be appreciated. Is it possible to just compile the engine code as a DLL or is there more to it than that?

Thank you, that is very helpful. Are you using the MaxRects algorithm for the free AtlasGuy? Should basic and MaxRects be the same pretty much Never mind I see the difference between full and free now after looking at them. I think I'd like to try something different. I don't see why it wouldn't be, but it should be possible to just import the bone data into GM:S and then let the programmer assign sprites in code to the bones. I really don't quite understand the SCML files very well so I guess I'm not sure how tied in the sprites are. Do you think this would be doable without breaking the way everything works? @lucid @BrashAdmin I wasn't sure if you saw my edits and I don't know your rules on bumping so hopefully you notice this.

Sorry for the long break with no reply. I've been taking a break from programming but I'm back to messing with stuff once again. I'm curious about some of the variables in the json file for AtlasGuyFree. Each frame has the following variables frame, rotated, trimmed, spriteSourceSize and sourceSize I'm assuming the frame variable tells you the xy position of the top left corner and the width/height of the sprite inside the texture and the sourceSize looks like it's just the size of the original sprite. The one that confuses me is the spriteSourceSize variable. I see that the width and height are the same as frame but the xy position is different. So I don't really know what it's there for. Any information on this would be greatly appreciated. p.s. I hope your wife made it through the flu without too much struggle. I managed to catch it too while it was going around and it definitely was no party.

I keep getting this error code for those links. "Error code: 2C171/1"

Thanks for the video. I'm glad to see that texture atlases work like that. It's exactly what I was hoping. The only down side is if anybody wants to use this plug-in they'll have to use Spriter Pro to make it work but I think I have a plan for that.

I would love to make a plugin for GM:S but first I need to address some issues. The biggest problem with using Spriter and GM:S together is the way GM:S works with external images. When you add an image dynamically in GM:S it adds a new texture page to the resources. Which means if you import ten images, you've created ten texture pages. That causes memory to spike. Then say you're drawing all ten of those sprites to render your skeleton, that results in ten texture swaps every draw update. This turns into terrible performance with GM:S, especially once your characters start getting more complex. 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. 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. The best solution I can think of is only pulling out the skeleton data and then loading the images directly into GM:S. 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 I remember seeing something about TexturePacker in Spriter but I'm not sure what that is all about. 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. It would be one imported sprite, one texture page, one texture swap. 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. Right now I'm just trying to get some ideas on how to move forward with this. I've already tried to just dive in coding and sure enough that was a pure mess. Just in case anybody gets confused, when I'm talking about importing images dynamically or just loading them in. GM:S has several different types of resources. Out of them, there are "Sprites" and "Included Files" You can create a sprite in the editor and then import existing images that way which is more efficient but slower to setup OR You can put the images in the included files which is quick and you can drag folders in there to keep your organization. This is much faster obviously but results in the mass memory usage and multiple textures pages/swaps.

Every time I try to import my Spriter Project after importing the Spriter unity package I get a bunch of missing asset errors saying it can't find all the textures used. I don't know what I'm doing wrong. I followed what the instructions said. If you need anymore info let me know, sorry I'm fairly new to Unity.

Dude that is incredible!

Very cool to hear and I definitely look forward to it. I'll take a closer look at everything next time I run through it all again.

For starters I just want to say thanks for making this! Is there any chance you could put together something to help others understand a little better how the implementation works? It does work with minor issues. I had one crash when transitioning animations on the green rectangle scml file but I didn't look into it too much. Overall it's nice and clean and works quickly. My only issue is that there's literally like no comments and for somebody who doesn't know c# that makes things a bit difficult. I really don't need much, I was just hoping you could make like a flow chart or a diagram to show how everything works together along with a SCML file. PS Sorry to sound ungrateful, I really don't want you to think that's what this is. This is extremely cool that you have a full-featured implementation! :D

Wow +1 each for you guys as well as RPG Maker. Gives me a little more reason to actually get MV.

I'm so freaking ready for this! Super excited, thanks for the updates and hard work! Even more excited to finally be able to get a working implementation setup for Gamemaker

Good stuff. Just glad to see that it's moving forward. No hard feelings for not having a video. :)

Very cool to see this progressing. What's up on that video? :huh:

Can't wait to see the video update!

Language API first All the others later I'm going to be using Gamemaker Studio but I have no idea how to play the animations at runtime. I need a generic implementation to figure out how to handle them. I already have parsed the SCML file but I don't know how to handle animations

They're currently working on a generic implementation. That's about all the info we've got so far.

Paste to all keys after adding sprites to already made animations are not keeping the same depth. It's just putting all the new sprites at the very top

Thank you for that! I've been waiting on any kind of sign of progress and this is something.

I'm glad to hear this. I started working on an implementation for GM:S but I only managed to figure out how to parse the SCML file and store it in data structures for later use. I really didn't know where to go from there. Having a reliable reference to go off of will make this way easier to figure out.

Sorry to revive an old thread but I felt this didn't need a new post. I was just checking to see if there's an ETA on when some updated documentation would be available? I've managed to parse SCML files and get all the data from it stored in data structures for my Game Maker Studio implementation I'm working on but I still don't understand how I'm supposed use the data to make the actual animations.