Ca ne te gène plus que la plupart (sûrement) des utilisateurs débutants tombent dans des pièges de structure qui, en plus, finissent par les bloquer ? Avant, tu tenais absolument à soutenir le contraire, il me semble.
Maintenant avec SFML 2 on peut faire simple ou bien carré, les gens n'ont qu'à choisir ce qu'ils veulent, moi ça me va.
Mais les gens ne choisissent pas vraiment, ils sont "naturellement" attirés vers le mauvais choix à cause de cet héritage multiple ! Le casser permettrait toujours de recréer le vice avec une classe héritant de sf::Sprite et sf::Transformable, par exemple, mais on serait plus conscient que c'est un mauvais choix et le choix naturel serait le bon. La SFML est très souvent utilisée comme base pour un design, alors il faut enlever les erreurs de ce genre quand elles sont détectées. On ne peut pas laisser un utilisateur construire une structure qui tombera inexorablement, c'est trop bête et trop frustrant !
Je suis d'accord mais malheureusement on ne vit pas dans ce monde où tout est carré et bien séparé
En programmation, c'est possible. En tout cas, il y a peut-être une limite mais on ne l'atteint pas en séparant le visuel de la logique, qui est un principe fondamental.
et qui veulent garder le niveau de simplicité initial
Justement, ça devient de plus en plus compliqué parce-qu'on a voulu trop réunir au départ ! C'est aller à l'encontre des classes.
Regardons ce que ça change concrètement.
sf::Texture Tex("machin.png");
sf::Sprite Spr(Tex);
Spr.SetPosition(50, 50);
Spr.Rotate(45);
sf::RenderWindow Win(...);
Win.Draw(Spr);
il suffira d'ajouter deux lignes de code, juste après la déclaration du sprite :
sf::Transformable Transf;
Spr.attachTo(Transf);et de remplacer les "Spr.machin" par des "Transf.machin".
Et on se débarrassera surtout de l'abominable :
class Player : public sf::Sprite {
public:
Player() {
}
void update() {
SetPosition(50, 50);
SetRotation(45);
}
}ou d'un
//meilleur design mais lourd à mettre en place donc peu utilisé. Comme il a l'air mal formé, l'utilisateur va penser qu'il se trompe et va choisir la pire solution possible alors qu'il avait raison, mais la SFML l'a induit en erreur !!
class Player : public sf::Transformable {
public:
Player() :
Graphics(new sf::Sprite()) {
}
~Player() {
delete Graphics;
}
void update() {
SetPosition(50, 50);
SetRotation(45);
//et c'est parti mesdames et messieurs
Graphics->SetPosition(GetPosition());
Graphics->SetRotation(45);
}
private:
sf::Drawable* Graphics;
}au profit de
//on est plus tenté d'hériter Sprite grâce à sa séparation de Transformable et à sa fonction attachTo qui indique qu'il serait bizarre de faire "attachTo(*this);" et on est orienté vers le deuxième design mais de façon moins lourde en lignes de code et en mémoire consommée inutilement.
class Player : public sf::Transformable {
public:
Player() :
Graphics(new sf::Sprite()) {
Graphics->attachTo(*this);
}
~Player() {
delete Graphics;
}
void update() {
SetPosition(50, 50);
SetRotation(45);
/*on peut même à tout moment changer de Graphics:
delete Graphics;
Graphics = new sf::RectangleShape(10, 10); */
}
private:
sf::Drawable* Graphics;
}
Sujet: Déshériter Sprite et ses soeurs de Transformable (Lu 8898 fois)