Jump to content
Spriter Forums

KGeist

Members
  • Posts

    2
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

KGeist's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Sounds OK. It must be a bug somewhere in my code, then (quite expected). I tested my wrapper with a square (rotating/scaling around random pivots) and it seemed OK, but it failed with the data passed by SpriterPlusPlus. Perhaps I misunderstood some API (especially considering pivots, such as, is scale applied according to the pivot or the actual center etc. - it's not obvious from the examples because they use interfaces of a third-party lib I'm not familiar with, perhaps it's where the errors stems from). Anyway, thanks for the confirmation that it's not your code which is to blame, perhaps a wrong order of matrix multiplications somewhere. Will have a look at my code again... (although it already works OK as it is) On an unrelated note, one minor complaint is that the interface is quite cumbersome; can't we have an option to iterate over all the pieces in one loop in Z-order (a list of infos describing the position + the angle around center + scale around center + texture path; can't we omit the pivot thing altogether too?), instead of scattering it around in subclasses (like ImageFile). Or maybe I overlooked?
  2. Hello, I'm making a game with 3D environments and 2.5D characters, the animations are amazingly smooth, however I had a bit of a problem while integrating SpriterPlusPlus. As far as I understand, the library expects to be used in a 2D game, so it treats 1 unit as 1 pixel. This is confirmed by the fact that Spriter and the examples have lengths around 200 units IIRC, which makes sense in a 2D game. However, my game is 3D, where 1 unit equals 1 meter (which is more intuitive to deal with). I tried scaling down the GreyGuy example to around 2 units in size, however Spriter was bugging out at me, I guess it wasn't meant to be edited at such small scales. Anyway, after saving the SCML file and reading it in my game engine, SpriterPlusPlus behaved in peculariar ways. I don't know if the fault is in my code (can't find) or there're some assumptions in SpriterPlusPlus or Spriter which I did not respect. Basically, if I export the file at 200 units, and tell SpriterPlusPlus to scale it down by ~0.02 (setScale(..) is the API? I did the integration quite some time ago now) to convert from the 2D units to 3D units, I get quite messed up rendering. A character's pieces are a bit detached from each other, and they become increasingly detached the more I scale down by using setScale(..). If I set the scale to 1.0f, then everything renders super nicely (awesome library, I love you), but it's quite buggy if I use setScale(..). It's as if the library casts floats to int's somewhere (or floors), which is not noticeable with 2D units (pixel scale) but becomes noticeable if your skeleton is around 1 unit in size (floor'ing/casting to int makes the pieces mislocated by 1 meter instead of 1 pixel). Anyway, I solved the problem by simply telling SpriterPlusPlus to render at 100% scale (200 units or so), and then I scale it down in OpenGL myself. So I'd like to have a confirmtation, if SpriterPlusPlus assumes the skeletons to be in the >100-200 unit range and therefore does not care about "subpixel" rendering (below 1), or there's a silly bug on my side. Everything works well now, but it's something which has been bugging me for a while.
×
×
  • Create New...