Voir les contributions
Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.
. Une classe ressemblant à, tiens, Transformable, représentant quelque-chose de géométrique, devrait avoir en premier lieu un tableau de points, de sommets, ainsi qu'une relation qui relie les points entre eux, des courbes. En fait, la librairie parfaite implémente du dessin vectoriel au sommet. Quand aux textures, elles sont soit elles-mêmes en vectoriel, soit des images qui s'affichent dans un polygone vectoriel. Les calculs de collision sont applicables pour tout, avec une extrême puissance ; les classes comme Shape n'ont plus de raison d'être car elles se retrouvent dans Transformable ; tout peut posséder une texture, une couleur, etc. Quant à Text, c'est soit un groupe de polygones vectoriels, chacun formant une lettre, soit un rectangle sans fond et au bord transparent dans lequel est dessiné le texte avec la fonte donnée. Ça peut marcher : ça s'imagine très bien et ça existe déjà. Je suis par contre effrayé des performances au sein d'un jeu, peut-être à tord.
class Player/Tile/Missile : sf::Sprite { ... };, à ça : class Player/Tile/Missile {
public:
int x, y;
void update() {
Graphics.SetPosition(x, y);
}
private:
sf::Sprite Graphics;
}; ou à ça : class Player/Tile/Missile : sf::Transformable {
private:
sf::Sprite Graphics;
}; ? Tu appelles ça "Sondage anonyme pour l'amélioration de la SFML" et tu obtiens n * 1000000 de votes, où n est le nombre de jours depuis la publication du sondage. La fonction est simple 
.de bons tutorielsPourrait-on mettre l'accent sur le piège qu'on veut éviter de façon à ce que l'utilisateur ne tombe pas dedans dans les tutoriels sur les graphismes ?
Gérer une bibliothèque avec beaucoup d'utilisateurs, c'est aussi savoir faire des compromisEn voilà un (pour SFML3) : on sépare effectivement Sprite et ses sœurs de sf::Transformable, mais on crée une troisième hiérarchie de classes qui héritent Sprite et Transformable, etc. pour qu'on puisse parvenir à un bon design sans "mauvaises manipulations" et que la simplicité soit toujours au rendez-vous ? Quand aux nouveaux noms, pour les classes qui héritent Sprite et les autres avec Transformable, je propose : FullSprite, StandaloneSprite ou quelque-chose d'autre dans le genre. A moins qu'on ne fasse l'inverse et que les Sprite qui ne viennent que de Drawable soient nommés SimpleSprite, BaseSprite, HalfSprite, ou autre afin que les codes de SFML2 fonctionnent toujours.
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é initialJustement, ç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.
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".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;
}
sf.Transform.getRectInscription drawable = case type drawable
sf.Sprite -> Rect(drawable.getPosition(), drawable.getSize())
sf.CircleShape -> Rect(drawable.radius * 2, drawable.radius * 2)
sf.Shape -> #un calcul plus compliqué
#etc.
On peut déjà séparer sans problème avec l'API actuelle (tu peux ignorer la transformation du sprite et lui en passer une perso lors du draw): j'ai répondu en quoi c'était dangereux et ça favorisait ce que tu cherches à absolument éviter dans la première partie de mon avant-dernier message.
mais j'ai quand même voulu garder la simplicité des classes actuelles (reprises de 1.6)Dans un vrai projet, un bon design, séparant Transformable et Drawable, simplifiera plus le code qu'un design où ce n'est pas le cas car on évite les opérations inutiles comme "tu peux ignorer la transformation du sprite et lui en passer une perso lors du draw".
car la plupart des gens les utilisent comme ça.
C'est une mauvaise chose car ça oriente très fortement les gens vers une direction qui n'est pas forcément la bonne. En mettant des classes très haut-niveau, "finales", dans SFML, j'incite les gens à faire pareil pour leurs propres classes, et donc utiliser les mêmes classes de base. Mais les classes des gens ne sont pas celles de SFML, et on voit très vite arriver plein de gens sur le forum qui se plaignent de limitations ou autres.
Et je ne veux pas que les gens utilisent des collections hétérogènes de Drawable. Je veux qu'ils utilisent des collections hétérogènes de leurs propres classes, avec des sprites, textes, etc. comme attributs de certaines.N'est-ce pas la solution ultime qui n'apporte que du plus ?
toi tu voudrais du minimalisme (pourquoi faire ?) [...]La "simplicité" n'est qu'illusoire et n'est qu'un chemin vers le côté obscur qui attend tous les débutants à bras ouverts.
. Je pense avoir le mieux répondu dans mon message précédent, et j'attends avec impatience de nouveaux arguments !
En premier, une consommation mémoire inutile (c'est bête en C++), et une mauvaise conscience .Commençons par la "mauvaise conscience". Peut-être le codeur va commencer par créer un attribut Sprite à son propre objet, mais il se rendra compte qu'il doit dupliquer les attributs de coordonnées, de rotation, etc. puis les passer à son attribut Sprite à chaque fois. Il va se lasser de la recopie, ne pas apprécier qu'on puisse accéder à ces attributs autrement que par Sprite.get/setAttribut, va aussi penser à l'aspect "consommation inutile", et va finalement commettre une grosse erreur (c'est exactement mon parcours que je vous donne) : il va faire hériter sa classe Player de Sprite, et va ensuite continuer dans cette lancée en créant des listes hétérogènes de Drawable* (malheur !).
.
Pourquoi le fait d'avoir plus d'attribut que nécessaire te rebut???En premier, une consommation mémoire inutile (c'est bête en C++), et une mauvaise conscience
.Qui peut le plus, peut le moinsMais si on peut facilement faire mieux (moins)... Pourquoi faire moins bien (plus et pas de séparation alors qu'un bon design l'impose). Je ne sais pas comment ça marche chez vous, mais chez moi, je ne fais en fait pas "le plus" : j'ai ma propre classe Shape et mes propres Rectangle, Circle, etc., ce qui me fait mal au coeur à chaque fois que j'y pense. J'évite ainsi du "plus" (attributs Drawable là ou j'en voudrais pas : bounding boxes) mais c'est au prix de "hacks" du design.
Puis si on fait ce que tu demande, mon système d'affichage de bounding boxes de Box2D s'appuyant sur DebugDraw ne fonctionne plus. Et là je vais devoir bricoler(rien de méchant, mais évitable).Ma fois, je ne saurais te répondre ici, ne connaissant que Box2D de nom et pas DebugDraw. Peux-tu préciser vite-fait ?
Le malheur des uns, fait le bonheur des autresEt au final, le bonheur de tout le monde. Le conservatisme est un frein à l'évolution. Le mieux aurait été de séparer dès le départ, pour éviter aux utilisateurs d'avoir à adapter leurs codes, car ils auraient bien démarré dès le début. Mais
Mieux vaut tard que jamais.
. A la place, on dériverait Transformable, et on traiterait la partie graphique naturellement à part.class Player : sf::Transformable {
public:
Player() {
attachTo(new sf::Sprite(textureMachin));
}
};Drawable.Draw() utilise les attributs du Transformable associé avec attachTo().class Player : sf::Sprite {
};mis dans une collection hétérogène de sf::Drawable.class Player : std::vector<sf::Sprite*> {
};Et si chaque classe est différente : l'une est sf::Sprite, l'autre est std::vector<sf::Sprite*>, l'autre est composé de Sprites et de RectangleShapes, eh ben chacune doit changer son parent et c'est pas propre. Le vrai parent recherché est sf::Transformable. C'est ses attributs qu'on ré-utilise dans toutes ces classes utilisateurs quel que soit le Drawable utilisé. Mais ça, tous ne le savent pas. En forçant la séparation, tout le monde le saura.