imgui-sfml
imgui-sfml copied to clipboard
SFML
Image drawing sf::Sprite respects transformation
A sf::Sprite drawn via Image function doesn't respect the transformaiton. That's what I wanted to fix.
This pull request is rather WIP, but this way its easier to talk about improvements and actual behaviour.
The sprite transformation works (proof below) but I had to apply some changes to the interface. This is not a big deal, because it should be easy to simply add my function and call it from the previous two overloads, thus no breaking change necessary. But here is my second struggle. The positioning and size behaviour of the sf::RenderTexture, sf::Texture and sf::Sprite now seem to differ quite a bit. I wasn't able to determine how a size param should change the appearance of such a sprite, as a sprite itself has a complete transformation. I decided to get rid of that overload and instead add a sf::Transform param, because this is much more flexible than the provided interface of a sf::Sprite. With a sf::Transform its possible to perform transformations in different order; the sf::Sprite uses a fixed ordering.
Looking forward for any feedback!
Well, I think I solved most of my struggles. I simply scaled the sprite to size after all other transformations have been applied. Additionally I improved the handling of the sprite, as it is now properly handled by ImGui (mostly copy-pasted from original ImGui::Image function).
One question is still unsolved. How to handle the border? Is it expected to apply transformations to the border rect or should it stay uneffected? Currently it is transformed, but I wonder if there ever is an actual usecase for this... (look at the picture above, its very far from pretty) On the other handside this is the more difficult part. If one simply wants a border around the sprite frame, than it should be very easy to do so, without expecting the function to do it.
One question is still unsolved. How to handle the border? Is it expected to apply transformations to the border rect or should it stay uneffected? Currently it is transformed, but I wonder if there ever is an actual usecase for this... (look at the picture above, its very far from pretty) On the other handside this is the more difficult part. If one simply wants a border around the sprite frame, than it should be very easy to do so, without expecting the function to do it.
Does Dear ImGui have any widgets that can be rotated? If it does, please see how it transforms the borders. If it doesn't - please try to create an implementation of this complex overload outside of ImGui-SFML's code. If it's possible, then maybe we should provide this as a code snippet/example.
I really don't want to support a code which uses imgui_external and does so many complex things not related to the actual backend implementation, to be honest. :(
Does Dear ImGui have any widgets that can be rotated? If it does, please see how it transforms the borders. If it doesn't - please try to create an implementation of this complex overload outside of ImGui-SFML's code. If it's possible, then maybe we should provide this as a code snippet/example.
Actually don't know. But the I think the best solution would be to simply draw the border independent to the transformation.
I really don't want to support a code which uses imgui_external and does so many complex things not related to the actual backend implementation, to be honest. :(
What do you expect? Transformation handling isn't just straight forward. Creating bridge code between two independant domains, neither. Additionally you require to keep things c++03 conform.
As I have to emulate the internals of ImGui::Image, inclusion of imgui_internal.h is simply necessary. Otherwise such functions like ItemSize and ItemAdd will not be available.
I've refactored the code accordingly to your comments.
I also decided to simply draw the border without the sprite transformation. This looks like this:
Perhaps this could be merged then? Will probably need this functionality in my project.
After some thought, I'm closing this. The complexity and future maintenance cost is not worth it.
Everything here can be done without making it a part of ImGui-SFML.