Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by slopps

  1. Congrats guys! You've nearly killed yourselves but you're almost there. Big kudos on an amazing piece of software, and I look forward to it! I hope it becomes the defacto for 2D games.
  2. for implementing bones, you basically just need to understand a few basics. With bones, everything can possibly have a parent (but doesn't have to). The transform data (position, scale, and rotation) of each ref, be it a bone or an object, is relative only to that ref's immediate parent. So, you must traverse the bone hierarchy from the top down, and append your transforms as you go. Luckily, the SCML data for each Timeline is structured in hierarchy descending order, so you should only need to loop through your bones once. You can look at the source code for SpriterMC (the updatevisuals method) or grimfang's C++ implementation. There are also a few good forum posts about it: viewtopic.php?f=3&t=5824 and viewtopic.php?f=2&t=1400
  3. Hey again Speedtouch, Thanks for letting me know about those errors. I had never compiled with anything other than Flash CS6, so I was unaware of the issues stricter compiling found. I've updated the package on both the github repository and my website, so hopefully no one else will run into these things.
  4. Hi speedtouch, Thanks for your patience and also for the bug report... So you're compiling from command line I take it? Is there a further stack trace than that? The issue you reported stems from the compiler being confused about which "Event" class to use. The namespace for the native Flash event (flash.events.Event) is totally different than the Starling Event (starling.events.Event), and if you try to combine them the world blows up. Even using the full namespace to define what you ant tends to end in error in my experience... I've had major issues with this, and to counter it, I've usually had to cast any Flash Event as * if I also need the Starling Event. I've never tried compiling the benchmarks or code with command line...actually, the benchmarks won't work via command line due to the simple fact that there are assets in the FLA's that the code references. I will look into this asap, and try to find a solution to your Event issues. I'm just curious how it's happening...it might just be matter of typing some arguments for event listeners as *. Can you pm me some further info about your system or the error?
  5. Thanks! I've updated the website and github with the latest versions. After some major optimizations I've managed to get around 400+ instances with bones at 60 fps, and far more without bones. The simpler the animations and less body parts/keyframes, the more instances you can get. Also, for some reason I get far more in Firefox (which uses DirectX) than I do in Chrome (using openGL), not sure why exactly...anyone have any idea? Benchmark with bones Benchmark without bones Basic Demo of features
  6. I've actually resolved this issue and increased the speed by over 400%. I'll be posting a new version late tonight when I get home from work. I apologize for the issue!
  7. slopps

    What's left to do

    This is great, Edgar. Sorry to hear about the injuries...that stuff is serious. I'm excited for the full release! Anything plugin developers could know ahead of time to start preparing features?
  8. Thanks! I've added an official website for the plugin in case anyone cares: http://www.sammyjoeosborne.com/SpriterMC
  9. SpriterMC is now a featured extension on the Starling Extensions page. There is also now a SpriterMC wiki page. Still working on an official site for it :)
  10. Excellent, thanks a lot Lucid! I love what you guys have done and I look forward to the next Spriter release. @sHTiF: Can you verify what text is displayed under the "Display Driver Used" box provided in the benchmark? My guess is your flash player is either falling back to Software support or you are using a Debug version of the flash player in either Firefox, IE, or Safari. If you view the file using a debug version of the flash player, the benchmark will run terribly. I'm guessing you're either using a debug version of the flash player or it is falling back on Software support instead of using the GPU. The debug player is much slower than the release flash player, and it's been verified to cause a huge performance difference (Starling forum post): http://forum.starling-framework.org/topic/spritermc-starling-extension-for-skeletal-animations-created-in-spriter#post-21919 I will update the benchmark and sample tomorrow night to issue a warning notification if a viewer is in fact using a debug version of the flash player (determined by evaluating Capabilities.isDebugger). If you're not using a debug player, or if you're not in fact falling back to Software support instead of GPU, then I'm at a loss. I included a last-resort warning in both the benchmark and sample to warn viewers if no GPU support was detected. Did you happen to see the red warning bar, as displayed in the screenshot below?
  11. I've updated with the first public release of SpriterMC v.01! If you check out the benchmark, you can achieve over 100 instances at 60FPS with extremely low memory and draw calls. Check out the Readme referenced up top (located in the github repo) for full reference until I can get the AsDocs generated
  12. Glad there's interest. For that reason, I want to be certain this is the best, most efficient, easy-to-update/modify/extend, and flexible implementation possible. The Spriter class (or Character class...haven't decided on naming yet) will be as similar to the Starling MovieClip class as possible, with many of the exact same methods. This should ensure it's familiar and easy to use. While the foundation for interpreting and animating the SCML data is there (no more playback bugs!), I'm still refactoring some things and changing the way assets are managed to allow for multiple instances of the same character with little memory overhead. I'm still hoping by the end of the week, but with documentation and such it could be a little longer. Working as fast as I can!
  13. Sorry for the delay! Trying to get it completed as fast as possible, but keep finding slight errors with my playback (specifically playing backward). There are actually some inconsistencies with Spriter itself and the way it plays back animations...but I think I know what it's supposed to do, so I'm gonna integrate it that way. I've now included ability to play more than one animation, and integrated looping/non-looping. Once the playback irregularities are ironed out, I've still got to make it load assets individually or via spritesheet. Right now it only has spritesheet support. While I anticipate it being easy to use, I suppose I'll need to make some sort of documentation as well. I'm hoping no more than another week...but we shall see. Only able to work on it in the evenings after I get off work so it's been somewhat slow going. I'll post here as soon as it's ready for public!
  14. SpriterMC - A full-featured AS3 Starling Implementation Official website http://www.sammyjoeosborne.com/SpriterMC Overview SpriterMC is a Starling implementation for importing skeletal (and non-skeletal) animations generated with Spriter, complete with a familiar API mimicking Starling MovieClip. Features include SpriterMC generation from an existing TextureAtlas or individual assets (a TextureAtlas is generated from assets dynamicall), bone support, ability to create multiple instances with low overhead, Framerate-independant and adjustable playback speed and playback direction, swap entire texture sets at runtime, and more. It currently supports all features of the Spriter file format (version a4.1), with future support planned for any subsequent changes to the SCML format. Demo and Benchmark Benchmark - Several hundred SpriterMC instances at ~60FPS Basic Demo - Showcasing some basic SpriterMC features such as bone display and frame sounds Usage For full features and API, see examples in the ReadMe provided on the SpriterMC Github page. Quick and simple example: var monster1:SpriterMC = SpriterMCFactory.createSpriterMC("monster", "xml/monster.scml", _myTextureAtlas); monster1.play(); //Note: SpriterMC's will not actually start playing or show up on stage until SpriterMC.SPRITER_MC_READY is broadcast, though there is no need to listen for this event myJuggler.add(monster1); //Add each SpriterMC to a Juggler, just like a regular Starling MovieClip Features [*:1jnin3vk]API mimicking Starling MovieClip for easy and familiar use [*:1jnin3vk]Generates a SpriterMC (similar to a Starling MovieClip) from a provided SCML filepath (loading of the SCML file is handled for you) [*:1jnin3vk]Accepts a preloaded TextureAtlas for assets, or loads the individual assets referenced in the SCML file and dynamically generates a TextureAtlas for you (uses a modified version of Emiliano Angelini's Dynamic Texture Atlas Generator) [*:1jnin3vk]Effortlessly create multiple instances of existing SpriterMCs with little to no additional memory or processing (100 instances at 60FPS in the Benchmark) [*:1jnin3vk]Draw underlying bone structure (for debugging) [*:1jnin3vk]Attach frame sounds [*:1jnin3vk]Attach frame callbacks [*:1jnin3vk]Framerate-irrelevant playback features ability to play and adjust your SpriterMC's playbackSpeed in real time, even reversing play direction altogether (by setting playbackSpeed to a negative) [*:1jnin3vk]Switch between Animations in the SpriterMC effortlessly (mySpriterMC.setAnimationByName("Running");) [*:1jnin3vk]Switch out TexturePacks at runtime to completely change the graphics used (TexturePack must contain the same folder/file structure as the SpriterMC's original TexturePack) [*:1jnin3vk]Friendly and familiar API featuring most (though not all) of the same methods of the Starling MovieClip [*:1jnin3vk]Queued commands that will execute once the SpriterMC is loaded and ready for display, so you don't have to wait on an event listener to start issuing calls such as play(), playbackSpeed = -1.5, currentFrame(), setAnimationByName(), etc. (You can still add an event listener to wait for the SpriterMC.SPRITER_MC_READY if you need to) Acknowledgements Special thanks to: [*:1jnin3vk]GrimFang - for his valuable insight into transform concatenation when I was erroneously trying to use matrix math [*:1jnin3vk]Coworkers at NogginLabs for support and advice (Brent Meyers, Paul Burowski) License SpriterMC is licensed under the MIT License. Download The API and samples are available on GitHub: https://github.com/SammyJoeOsborne/SpriterMC
  15. My main objective with my Starling implementation of Spriter is to integrate it with a physics engine (most likely Nape, which is faster than Box2d). The way other game engines accomplish this is having the character body parts be driven by animation data, with the physics bodies following along but not being effected by the physics world. Then, whenever the body needs a ragdoll effect or any other physicsy-interaction, the character skins switch from being driven by the animation data to the physics data. Certain games can even turn physics on just for certain body parts, while others continue to be animated with animation data! Check out the mobile game Zombie Smash for an example of this. There's a forum post from the developers about this here: http://www.cocos2d-iphone.org/forum/topic/18075 (look for the post near the bottom by the user Zombie)
  16. Ok, now I get the directional scaling problem. Sigh...looks like I'l be calculating the manual/only way possible as well. Thanks again for your insight. In case anyone is wondering, imagine you have a square. Then rotate that square by 45 degrees. Then imagine applying a transformation matrix to it that applies scaleY of 2. Instead of having a rotated rectangle, you will instead have a funky, skewed diamond since the scale-direction is still being applied vertically instead of rotating with the object.
  17. Really?! dang... I'm not sure I understand the " scaling directions are not rotated as they would be when composed as a matrix" comment. Can you explain further? I feel like if the parent is rotated 90 degree and scaled by 3, applying that transformation matrix to the child (and that of all parents above) should be just fine, no? In doing some quick tests in flash, it seems to work. Is there something about the rotation values in the scml file I'm not understanding? Thanks again and sorry to be a bother.
  18. I only meant using matrix math to figure out the final and actual coordinates, scale, and rotation of the images. Since the coordinate systems are all nested inside one another, one of the best ways to do this is to concatenate all transformation matrices from the top-most parent down to the final child, and apply that concatenated matrix to the child. Of course, it would be far easier to treat the bones as containers and just add children inside of them, since they would inherit their parents transformations, but then the z-indexes of the images would be all wrong. Thanks for the link to the C++ implementation, I'll check it out. Does it already have bones implemented properly? thanks again! [update] In the post you linked you, they're basically doing the math the long/hard way, assuming the language or framework in question has some functions to help concatenate matrices. I suppose either way is accomplishing the same things, just with fewer lines of code on my end. There's could be more efficient, actually, since they aren't creating full blown matrices and calculating skew, rotation, etc.
  19. Is there a reason the bones have a scale applied to them when you create them at the length you need? The way you have it implemented now, a bone seems to have a default length, and any bone drawn at a different length is considered scaled. I would think instead, the bone should be considered at scale 100% when you first draw it, no matter the size. Any changes to its size from that point forward could be considered a scale change. Am I thinking about this wrong? Is there a reason you've done it this way?
  20. I'm amost finished with my As3 Starling implementation of Spriter, which is successfully using loaded sprite sheets instead of individually embedded images. Of course, I've hit a snag now that I realize how the parenting to bones work. I'm trying to figure out which would be more overhead: calculating all the transformation matrices of parents to figure out the coordinates/angles of each image so that I don't actually have to create the bones themselves, or creating displayObjectContainers for the bones to house the children images so that I don't have to manually do any of the transformation math. [update] I now realize that creating displayObjectContainers for the bones to house the child images wouldn't really be effective because it wouldn't allow proper z-indexing of the images. So I suppose that's out. So, to figure out the actual coordinates/size/rotation of the images, do I pretty much have to go down the chain of bones and concat the matrices or something? I'm lost at this point. Anyone have any suggestions?
  21. Hey guys, just bought my preorder copy, great work, this is pretty amazing. My question is about IK. It seems when holding Shift to engage the inverse kinematics, it only effects 1 bone up the chain. For example, if I move the foot, only the shin bone is effected by the IK and the thigh bone remains in place. Is there a way to move the foot so that the IK effects more than 1 bone up the chain? Is this a feature that's possibly coming? Thanks guys!
  • Create New...