Alright, I got the rotations working. That was simply a matter of rotating the array of texCoords, so all the corners moved. I have another issue now. Trimming. I've updated the topic to reflect that. There are a lot of posts about this, but most of them are not relevant to my specific situation, for reasons I will explain.
I'm really just stuck on this because matrix transformations confuse me. It's frustrating that I haven't been able to figure this out yet after a few days of hammering on it, because there's a lot of posts about it. I realize that this question is somewhat out of the scope of SFML's feature set, but I am under the impression that it's something that is simple to add, that's just going over my head. So I'll ask anyway.
What I want is very simple. TexturePacker can trim sprite textures, saving memory by a pretty good amount on the atlas. It removes the transparent areas around the texture, but saves the offset from the top left of the image to the top left of the actual pixels in the image, allowing you to position it in your engine properly, without wasting memory on transparent data. It's a cool feature and I really want to use it. The problem is that sf::Sprite uses texture size for it's transform and bounds, and I want a class that lets me basically ignore the fact that this trimming has occurred. That sentence is structured weird, so I made an image to elaborate on this.
In this image, the texture data of a trimmed texture is the green box, the original texture data before trimming is the red box, the transparent area is blue, and the offset is the yellow line. I want a class that gives me bounds information of, and allows me to transform and rotate the RED box, sending all of these actions to the green box, as it's child. That way it's like the trimming never happened, but it did. The green square is simply offset, so it won't be MOVING in it's local space. It's just sitting at an offset. I understand that this is basically a (very small) sf::Transform hierarchy.
I already know that in the draw function of a Drawable, this is really easy to do this by using RenderStates, and combining those with the transform of the Drawable. The problem with this is that these SpriteBatchItems are not Drawable, they are just Transformables with vertex information that are sent to the SpriteBatch, which is Drawable. If I were to make them Drawable just for this feature, I feel that might affect performance slightly, and I'm doing all this work to make stuff perform as fast as possible. I've done quite a bit of research on this, and I do know about the hierarchy you can form in the draw function, but I don't think that is relevant to this particular situation, due to the objects not being Drawable.
Usually the answer is "use sf::Transform", and I'm pretty sure that I can indeed solve this problem with one sf::Transformable parent, one sf::Transform representing the offset, and a combination operation any time the transform moves. I'm just asking how, because I've been asking, looking through the documentation, and testing hacky solutions for like two days now, and I feel like I've hit a wall with what originally seemed to be a simple problem. I think one reason is that I frequently mix up a Transform and a transformed Rect, in my head. One of the hacky solutions I tried was using setOrigin in an abusive manner overloading it's set and get functions to silently add and remove the offset, but this felt dirty and the rotations didn't feel right for some reason, I'm not sure why.
Anyway. I would really appreciate help getting this PROPERLY implemented, because I want to start using this to actually do stuff. Once I get this stuff written, I plan on dropping it on the wiki for everyone else. I just have to get it written first. Thanks again.
TLDR: I need a small (size 2) child/parent hierarchy of sf::Transforms/sf::Transformables. I can't use the draw function, because the objects are not drawable. Halp.
Show Posts
