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?
Thanks!
Comments
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.
edit: Maybe you could shader as workaround for now?
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.
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.
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.
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?
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...).
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.
Thanks!
In any case, I'll pick that task next when I'm done with my current ones.