Jump to content

Jeff Ward

  • Content Count

  • Joined

  • Last visited

  1. I see one of the benefits of using a bone based animation system to be that I should be able to create / control multiple animations that can be blended together at runtime (animation layering), but I'm not seeing any of the Spriter runtimes or the tooling support this. I saw some of the Sub Entity work, but what I'm asking for isn't quite that... For example, if I created a seperate Left / Right running animation and a seperate forward / backward attack, I should be able to play any combination of run and attack together and have them blend (and hopefully look good....) Another good example is having an aim "animation" that can be all of the proper aim positions from left to right, then programatically choose the point in time of that animation based on user input, pause that animation, and play other animations on top (run being the main example). So now I can have a look similar to the game "Abuse" without a ton of extra effort Is this possible in any of the provided implementations? Would it be possible to do this type of blending in my own implementation, and would the spriter format be... okay with it?
  2. Of course, as soon as I wrote this I figured it out. Key was actualy realizing that I should be using a unit square with the top left at (0, 0), not centered at 0, 0. Other weirdness is rotated versions should use atlasData.spriteSourcePosition.y - atlasData.sourceSize.y, where non-rotated use atlasData.spriteSourcePosition.y unmodified
  3. I'm trying to integrate spriter into my home grown engine that uses a 3D rendering system on the back end. I'm using SpriterPlusPlus and I've overridden SpriterEngine::AtlasFile to render the actual images, but things don't seem to be in the right place. I'm basing my code off this file in the sample: https://github.com/lucidspriter/SpriterPlusPlus/blob/master/example/override/sfmlimagefile.cpp For the time being, everything is essentially being rendered with a unit square centered at 0, 0 (instead of the top left corner at 0, 0). Things I'm not sure about are that initial translation by atlasData.spriteSourcePosition, and the move of the pivot by -0.5. I think putting the top left corner at 0, 0 might solve the pivot problem, but I'm not sure what the spriteSourcePosition translation is doing. Here's the psuedo code for rendering (in AtlasFile::renderSprite) transform = identity() if(atlasData.rotated) { transform = scale(atlasData.frameSize.y, atlasData.frameSize.x) transform *= translate(atlasData.spriteSourcePosition.y, atlasData.spriteSourcePosition.x) transform *= rotateZ(PI / 2) } else { transform = scale(atlasData.frameSize.x, atlasData.frameSize.y) transform *= translate(atlasData.spriteSourcePosition.x, atlasData.spriteSourcePosition.y) } transform *= translate(-(pivot.x - 0.5) * atlasData.sourceSize.x, -(pivot.y - 0.5f) * atlasData.sourceSize.y) transform *= spriteInfo->scale transform *= rotateZ(-spriteInfo->getAngle()) transform *= translate(spriteInfo->getPosition()) Anyone see anything obvious?
  • Create New...