TexturePacker / Rotation

edited January 2015 in General discussions
I've been playing around with Orx and testing some things and one issue I hit was that there is no support for rotated sprites in a texture atlas. With our current tech sprites have a bool flag "rotated" and if true than we uv based on a rotated rect.

This is something that I need to support and so I'm wondering where the best place to do this would be, and considering I'm still brand new to the codebase is this the correct approach? Basically flag if the texture region is rotated and if so UV differently... or is there a better way I'm not thinking of that avoids the branch and/or is cleaner?



  • edited January 2015
    Hi Joe. I assume this is for sprites on your sheet turned sideways to save space?

    Right now you could only rotate the object that uses the rotated graphic but that's not really the same.

    There's a FLIP property under the GraphicTemplate. I can imagine a ROTATED = true|false property would be handy.
  • edited January 2015
    I would welcome this too. We've rotated sprites in the sprite sheets, too.

    edit: Maybe you could shader as workaround for now?
  • edited January 2015
    sausage that's exactly what I'm using this for as I have some very tightly packed sprite sheets. With our current tech I just export from TP if it is rotated (i.e. like in the JSON/Cocos exporter) and then I rotated via UVs rather than rotating the actual object itself. Sure I could just work around and store a bool and if true start rotation at -90deg but I'd rather have proper support, hence the reason I was thinking of building this in and looking at the best practice for doing so as it adds a branch to UV recalculation.
  • edited January 2015
    Ah yes, a few months ago I tried to add support for this (I think it was based on a suggestion from Lydesik), but it turned to be a bit more complex than anticipated as the concept of UVs only exists within the display plugin itself, and not orx. I had some complications with repeat/tiled and mirrored sprites if I remember correctly.

    All this should go away the day I implement this issue: https://bitbucket.org/orx/orx/issue/61/add-support-for-non-quad-mesh-graphics
    With support for "generic" meshes, the exporter could easily reorganize the vertices based on the sprite orientation. That shouldn't be too hard to implement, if it's really blocking for you, I can bump its priority in my current todo list.
  • edited January 2015
    Ah yes having access to the vert list would definitely make this a non-issue! Right now I am actually exploring using orx and have been reading through the code and writing demos using our existing assets, etc... this issue came up simply because we rely on it so heavily with our current tech/assets, and without it I have to basically hack work arounds like rebuilding the atlases inefficiently, etc... and we have a lot of assets :huh:
  • edited April 2015
    This issue has actually become quite a major blocker in many regards now so I thought I would bring it up. I've been testing creating small game builds in Orx as well as tools, but not having vert access really makes things hard or in need of hacks.

    The first example is of course this one which we've discussed, where I'd like to export UVs from TP so we could handle rotated sprites in texture atlases. Beyond that though plugging things such as IMGUI for building tools then requires hacking rather than just having access to a vert list that I could feed.

    Anyways I just figured I would share my experience on this, although who knows maybe I am the only one hitting these types of issues.
  • edited April 2015
    As previously discussed, it shouldn't be an issue to implement. Should I deduce from this post that it's the last point to be tested before you choose to use it for your current game?

    I'm simply asking as I like to prioritize feature development given what people needs to develop their current games before what's potentially needed during test phases. For example, lydesik is waiting after me to integrate his pull requests regarding variable height font support and liquidfun integration (both pull requests require some work on my side as well).

    For now do you simply need rotated sprite support or full vertex/UV access?

    If it's for testing purpose, I could maybe give you some workaround code for both situations that would still work when the actual final feature is implemented in the engine?
    The actual data itself wouldn't have to change when the final feature is added to orx: it's simply the code integration that would go down inside orx at engine-level instead of being at the game/test-level and would therefore be more generic and yield better performances.
  • edited April 2015
    Well it's not really a testing issue, it's mainly that it becomes quite a roadblock for me for both the asset conditioning as well as being unable to access verts for third party solutions, etc.

    The largest issue is simply due to having such a large amount of assets and I don't want to have to condition them multiple times (i.e. build the data for a temp solution, and then down the road rebuild the entire dataset) as we don't have a build pipeline equipped for that right now. Mind you at least even in the worst case it is still easy to do, just eats up time and testing.

    So in that regard I really only need rotated sprite support from exporter to in-engine use, as right now roughly 50% of our assets are unusable without it due to having very tight packing... and I didn't want to hack around with this and have to recondition and reimplement the feature down the road.

    The next issue was with building tools. I sat down to build/port our new animation editor this week for making final changes to character texturing and animation, but unfortunately without having vertex lists I was unable to use something like IMGUI quickly so currently I'm just using a hack solution temporarily without an actual GUI. I'm guessing that the best way to do this as of now would be to hack around the engine and implement the GL calls ignoring engine rendering?
  • edited April 2015
    Just my two cents, before attempting to make GL calls directly, take a look at orxDisplay_DrawMesh.
  • edited April 2015
    As enobayram pointed out, orxDisplay_DrawMesh should work for you, regarding the ImGUI.

    For the rotated sprite, the data would change and it wouldn't be a hack per se either, it's just that doing a game-side integration is much faster than doing the final one in the engine. In the end it'd be some code I'd give you that you'd paste in your game code until I submit the proper implementation in orx.

    I see two easy way to do that, both by adding some code to the handler of display events: either modify the end object transform or by using the aforementioned orxDisplay_DrawMesh.

    If this approach if ok with you, I could provide that code to you by next week if you choose so. I'll then do the actual generic low-level version a bit later on, which will allow me to focus on my current started tasks (animation overhaul, non-fixed vertical size fonts, SDF, etc...).
  • edited April 2015
    hmm I'll have to check out DrawMesh as that looks highly promising as really I only need to be able to feed texture/blend/verts which only use pos/uv/colour :)

    Regarding the rotated sprite sheets I don't want to bother you or throw off your time iarwain, if I get really blocked and could use a hand then I'll send a message asking for help. Although really I just wanted to update things in regards to priority as I was hoping this might be something that could be looked at possibly once you are finished your current tasks.

  • edited April 2015
    No worries, I'd be happy to help if I can. I don't think writing the support at the game level would take more more than half an hour, so I'm happy to contribute this way until I get to do the actual engine feature.
    In any case, I'll pick that task next when I'm done with my current ones.
  • edited April 2015
    Great thanks so much! I'll definitely keep you in the loop on how things are going and I'll reach out if I need a hand :)
Sign In or Register to comment.