a tree of geom transforms

[gsaurus]

rotation is applied after the scale.

Does that have to be like that, or is it possible (on the Matrix3 class) to invert this order?


In the meanwhile I solved my mirroring by deriving a class from sf::Drawable which has another Drawable inside. The parent takes care of translation and scale (my own scale for negative values), the child takes care of rotation and origin. This way rotation is applied before the scale, making the desired effect.

The bad of this on my tree is that I double the number of drawables (and so double the recursive calls), and I had to "redefine" scale, rotation and origin setters and getters. They aren't virtual on sf::Drawable, so I can't use my drawables as sf::Drawable*, or the methods called are the sf::Drawable instead of mine. But I can live with it.

Edit: I just started using sfml2 and I'm not yet very familiar with the new class sf::Renderer. It is passed on the Render method, but since I have to draw my drawable child, I do nothing with the renderer parameter:

Code: [Select]

void DrawableBox::Render(sf::RenderTarget& target, sf::Renderer& renderer) const{
    // apply my own matrix (because of my scale allowing negative values)
    (...)
    // render child
    target.Draw(*child);
}
Is it ok? What can happen by ignoring that parameter?

[Laurent]

Does that have to be like that, or is it possible (on the Matrix3 class) to invert this order?

It is possible, but I won't make it possible in the SFML API, sorry.

Is it ok? What can happen by ignoring that parameter?

It's perfectly ok, the renderer must be used when you reach the lowest level of rendering, it is a replacement for direct OpenGL calls. So as long as you still deal with drawables, you can safely ignore it.

[gsaurus]

is it possible (on the Matrix3 class) to invert this order?

It is possible, but I won't make it possible in the SFML API, sorry.

I guess it's a question of efficiency, it's ok :wink: I deal with it as I can  :wink:

[Laurent]

Not at all :lol:
It is a question of consistent / simple / clean interface.

[gsaurus]

Ok, so, on my derived drawable class, I solved my flip operations this way:
   - I remove (inverse operations) the origin and rotation transformations applied by the sf::Drawable class (note that I let position and scale unchanged)
   - apply my flip (scale by -1 on x and/or y)
   - apply the origin and rotation back again.

Note that I didn't changed order of any original operation, just added a negative factor in a different order than the scale relatively to origin and rotation.

This works great, drawables are now just equal to what they where before, except that they now have FlipX and FlipY methods, that truly flips them over their origin.
I think this is a very consistent/simple/clean concept and interface, don't you? I think flip shouldn't be limited to sprites, it should be provided for all drawable objects.
Also I think Sprite::Flip methods aren't that useful nor consistent, because it isn't a flip over their origin. The origin doesn't coincide with the same pixel anymore, and that's not concordant with the expected properties of the geometric flip operation.

The bad of my implementation is that it requires some extra matrices to be applied on the renderer.

Would you consider to change sf::Drawable (and sf::Matrix3), adding a myIsFlippedX and myIsFlippedY and inverting scale directly on the matrix, in an order that doesn't change anything of the current operations order? So that drawables become with a geometric flip operation. I think it would be of great use! Shouldn't be hard to do and keeps interface simple.
Oh, just if you find that scale by -1 has any problem (didn't find any yet, maybe you restricted it to avoid scale by zero?).

[Laurent]

I'll think about that, do my own tests and decide whether it deserves to be added or not

Thanks for your help, I'll let you know when I do it (I'm currently destroying the network API, so it may take a while).

[gsaurus]

Thanks for your help, I'll let you know when I do it (I'm currently destroying the network API, so it may take a while).

Wow! eheh
Thanks, take your time  

[gsaurus]

I did a video of my first experimentations with my drawable tree and "flippable" drawables
It's a weird test :roll:, but you know...



I didn't used shapes nor text this time, but since it's all about geometric transformations on drawable classes, it doesn't matter. When it's flipped on X, it does a mirror over the character center (it's feet).

[Laurent]

This is exactly the kind of stuff that I wanted to do (in another life), very nice

[panithadrum]

By the name of the post I couldn't know what was the thing you were working on.
I made an animation system like yours long time ago, but it made it so simple (just to fit with the game I was doing).
Now I'm going to remake it so I'm going to do the same you do

I want to see this finished!

BTW, if you want to check the game I'm talking about, watch a video

[gsaurus]

Eheh. I see. Yeah the test I did is quite simple too.

 - A class named DrawableNode extends sf::Drawable. It contains drawable children, with methods like "addChild".

 - A class for InversibleDrawables that adds the FlipX and FlipY methods for true geom flip around the drawable origin. This class works for any kind of drawable objects.
Unfortunately the flip code isn't great, it's as I said above: reverts rotation and origin previously applied by sf::Drawable, apply the negative scale, and apply the rotation back again. But I'm hoping that Laurent implement flip methods directly on sf::Drawable so I can discard my workaround class. While it doesn't happen, this class works fine .


Doing this example was just create some nodes and access them directly (nodes and sprite leafs) to change geometric properties.
This is a feature for my project EvE (Evolution Engine) (I posted about it on the SFML projects board some time ago )

[panithadrum]

Oh yes, I remember that post. It looks amazing.

So will you make an animation editor?

What a coincidence: my game was called Apocalyptic "Evolution" lol

[gsaurus]

Thanks
Yeah, it will have editors for "everything", and will use Lua scripting for characters behaviour and stuff like that

[EatMyShorts]

I know I am digging this up, but did you bother to do any kind of soring draw queues? IS performance OK?

I am working on similar solution with extending Drawable class and I am not sure if this will not be an issue.

I know that SFML 2.0 had something like render queue, but AFAIK this was removed.

[gsaurus]

What do you need exactly?

For a tree-structured drawable I just created a "DrawableNode" class, which has a vector of Drawables inside (the children). The render function just draws them in the vector order. If perhaps some children are DrawableNodes themselves then it becomes recursive.