Jump to content

Doc308

Members
  • Posts

    6
  • Joined

  • Last visited

Doc308's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Thank you for the follow up, I didn't get the e-mail, so I thought I would follow up on the forums in case of a hiccup in the system. I appreciate all the feedback, Melv & Mich have been hard at the engine integration, and I've been doing my part by providing as much background knowledge with Spriter as I can offer. It shouldn't be too far off for implementation, and just a matter of what improvements get made that would tweak the base get put in. Can't wait to see it working! :)
  2. Melv had some follow up questions, hopefulyl you can answer, we're trying to meet as much of the specification as possible. Are bones are the way to go now or are they optional, in which case the older files are obsolete? If you can optionally use bones then that would make the animation slightly more complex. So in a "a4.1" SCML file I see stuff like this: So it seems that the "bone_ref" parent refers to a parent bone and an "object_ref" parent refers to a "bone_ref" as well. (?) That would make sense i.e. a bone hierarchy with objects "attached" to bones. So that begs the question then that because each "object_ref" has a parent bone but still refers to a "timeline" and "key", what do you do with those references i.e.: ... So this "object" is referred to in the first listing as "timeline=10" and "key=0" but the object is parented to a bone_ref of: ... ... so are the x, y, pivot_x, pivot_y, angle & scales local-space from the bone? I can only presume so. What about (as in older versions) when the object is not attached to a bone? Do those become the origin of the composite/character? For now I'm taking the following assumptions and running with them so just correct me if you know or can find more info: Bones are optional Spatial details of a bone are relative to a parent bone Spatial details of an object are relative to the bone if parented to one else they are relative to the "character" origin.
  3. Just to follow up, I have the default monster file working now. I made a silly coding mistake that was pointed out to me, and was able to diagnose a few rendering problems (invert y, and positive vs negative angles). I am going to attempt to get the animation working script wise, but in the end, an engine specific method would probably be more ideal. I just wanted to sort out the kinks before venturing further. For those unaware, T2D MIT is FREE! It was recently released under a similar license as Torque 3D, and is available from GitHub. You can either go to GarageGames, or use my own forked GitHub repo. My next step is to setup the animation handler. And probably need to transfer the work to C++ and link it as it's own Asset Type for generation and hook the result back to a console grabbable object for users to control. If anyone wishes to assist, please feel free. I am happy to help if needed as well, otherwise will push on in my own time.
  4. Yes & no, I have it close to working with T2D MIT, however I am having problems with getting the Sprites to render for some reason. Also, still need to implement the animation hooks as well. In the end, a runtime for T2D would be far better than taking the SCML data and reading through it and implementing off of that... However I don't know what steps that would entail. As soon as I get a finished working version I'll post my git extension of T2D with Spriter support. Actually I'll post it now, maybe someone here can help figure it out... https://github.com/Doc308/Torque2D My setup is based off of the default Sandbox module included in T2D, my actual module for the Spriter is located under modules/SpriterToy Also, for the record I had to create the .taml files manually for the image assets, and am working on a step around for that (for designers not wanting to have to manually do the step..). If anyone has question, I'll be happy to answer, or if anyone figures out what might be causing the sprites NOT to show up... well, that would be greatly helpful, I have it hardlined in at the moment, but it's still not working.
  5. Johnny, I have looked into your C++ API, and while it's complete for a generic implementation of C++ and from there to a renderer, Torque already has a lot of what is needed, it's just a matter of adding in the SCML read/interpretation to Torque script that is needed. I am making progress by using your SCMPpp on one hand, Mike Ness's script on the other hand. All whilest comparing to what is already included in the Torque 2D Engine itself. The "good" news is, it's not as big of a step as I once thought it might be. As Torque already has xml support, and utilizes tinyxml. I have to work-around the XMLhelper library as the way it's handled is different. I'm looking to add it as a Torque entity of a new type so that user control over it will be easier to maintain. The "trick" so to speak, is linking in the animation, but so long as I gather all the key frames on reading the SCML document I should be able to manage it. My C++ is a little rusty, but I'm getting along ok for now. It's just sitting down and taking the time to get it right. I've also been starting to "pool" others from the Torque community for insight in aread I'm not compeletely familiar with (such as extending the editor to allow users "ease of access", but that's really just a nice-ity moreso than a necessity. Also, just an FYI, I tried implementing your code as whole into Torque, and after a few changes (due to what is there already, and a few minor hooks that I needed to clean up), it came up as a memory sync problem. Which is why the developers created the SimXML functionility in as a workaround. And truth be told, your code is more than what is necessary for Torque implementation.
  6. Very awesome stuff! I've been eager to get Spriter working with T2D (TGB). Quite impressive is the fact you've managed to get this "in place" without exposing it to the source first. I am definitely motivated by this, and am starting to make strides of my own make this into a full integration. I have high proficiency with Torque, and am knowledgeable with C++. The only part that is somewhat confusing to me is the format's, I do know a bit about it, and hopefully will gain broader understanding as I work through this. I would really like to do more with this, and I believe integrating into the source code and then exposing to the editor itself would be the best place to go with it. The only part that somewhat concerns me is how the animations will be handled and whether a specific class reference will be enough for Torque. I think that if it was it's own unique element that housed similar information as Static & Animated Sprites it might function. If anyone else would care to share some knowledge regarding this, it would most likely aid in the implementation. I will be happy to contribute towards this goal.
×
×
  • Create New...