Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Parent / Child heirachy sprite support  (Read 5019 times)

0 Members and 2 Guests are viewing this topic.

blockh34d

  • Newbie
  • *
  • Posts: 3
    • View Profile
Parent / Child heirachy sprite support
« on: July 16, 2012, 05:47:08 pm »
It would be great if we could attach one sprite to another in a parent / child way, so when anything happens to the parent it also happens to the child.  Ideally any sprite could be both parent and child.

I already have this hacked together a little with my own class that derives from sf::Sprite.  If the code involved would help let me know and I'll post it, but its nothing special.

Thanks again for all your hard work on this fine project.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11034
    • View Profile
    • development blog
    • Email
Re: Parent / Child heirachy sprite support
« Reply #1 on: July 16, 2012, 07:06:29 pm »
This feature has been suggested a few times but it has always been rejectes for various reasons of which I believe the most important one is, that SFML is a multimedia library and not a game engine/framework. It provides basic functions to draw and move sprites but how diffrent elements get organized should be a task for the developer.
Another reason is that such a class (sometimes refered to as 'Node' class) isn't such a big task and since the idea is pretty generic there are also a lot of hints and how to's on the internet.
Also the transformable class brings already powerfull features for such a task.

Then again I'm not the developer of SFML, so it's not my call. :p
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Parent / Child heirachy sprite support
« Reply #2 on: July 16, 2012, 08:33:58 pm »
I found a compromise for SFML 2:  the feature is not directly implemented (eXpl0it3r is right: this is the job of a scenegraph, and thus a game engine) but it is easily implementable on top of SFML. When you draw something, you can pass an additional transform (sf::Transform) which will be combined with the entity's own transform. You can also get the transform of any SFML class. From there, it's easy to implement a parent-child system.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Parent / Child heirachy sprite support
« Reply #3 on: July 16, 2012, 08:58:34 pm »
The feature you request would imply a whole scenenode concept (of which sprites are just a special case).

You can already now write hierarchies with the use of sf::Transform:
class MyParent : public sf::Drawable, public sf::Transformable
{
public:
     // overrides sf::Drawable::draw()
    virtual void draw(sf::RenderTarget& target, sf::RenderStates states)
    {
        // getTransform() inherited from sf::Transformable
        states.transform *= getTransform();

        target.draw(myChild, states);
    }
private:
    ...
};
« Last Edit: July 16, 2012, 09:17:16 pm by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

blockh34d

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Parent / Child heirachy sprite support
« Reply #4 on: July 16, 2012, 09:35:46 pm »
Funny that both my feature requests would get shot down as 'my job'.  I've already written something very much like SFML a couple times for multiple platforms.  Ortho mappped GL sprites are not that hard.  I'm using SFML because it should hopefully make my life easier.  If its 'my job' to manage everything but low level stuff, then whats the point of SFML? 

I'm not suggesting you put in path solving, steering behaviors, optimized distance calculations or a physics system.  I would agree that all these things, though very helpful, are not the job of the library.  But if you're going to make a sprite class, please do make the whole thing.  Stopping just short of 'useful' just motivates me to do a total rewrite.  Sprites are not only the domain of games btw, the forums obvious disdain for game programmers is misguided in my opinion.  Lots of apps use sprites that aren't games. Game coders are enthusiastic programmers and should not be pushed away just because their game probably will never be known of or played widely.

BTW I've already implemented both the features I requested.  They've very helpful.  You should add them.  Tweening and parent/child relationships.  'Thats the programmers job' just sounds like a weak excuse.  Referring me off to some other add-on library of 'everythign that doesnt fit in SFML' just pointlessly induces bloat.  Making every user reinvent the same wheel just means that wheel is usually going to be made poorly.

This is probably going to be my last post.  People seem kinda diminishing and combative here, like I'm some sorta novice because i suggested these things.  Be glad i took the 30 seconds to give you some honest feedback, dont try to argue with me about what I want.  As the user, what I want should be very, very important to the developer.  If its not, then the developer is no good and does not deserve my time and energy.

Thanks again for this fine library and all your hard work.  Good luck.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Parent / Child heirachy sprite support
« Reply #5 on: July 16, 2012, 10:31:53 pm »
It seems that people tend to get stressed these days. I have no idea why but it starts to be really annoying for everyone.

I don't want to answer to this kind of messages anymore, although I have many things to say. If you can't be friendly on a forum and can't write something without showing all your bad feelings, then please don't post. I'm really tired of this behaviour and don't want it to become the new standard on this forum. People don't come here to be insulted, real life is good enough for that.
Laurent Gomila - SFML developer