Forum de la communauté SFML
Général => Suggestions de nouvelles fonctionnalités => Discussion démarrée par: L01man le Mai 01, 2012, 11:44:20 pm
-
Sprite, Text et Shape deviennent de simples Drawable. Mais on leur crée une méthode attachToTransformable(sf::Transformable&) pour que Draw fonctionne quand même. Pour cette méthode, il faut peut-être créer une classe intermédiaire.
En théorie, c'est un bon choix. Le visuel et le reste ne doivent pas être mélangés, et c'est très bien qu'il y ait des classes Drawable et Transformable séparées. Le problème, c'est qu'à partir de la génération de Sprite, les deux sont à nouveaux mélangés !
Finalement, on peut se retrouver avec des hacks comme un attribut Sprite auquel on passe les coordonnées de sa propre classe, et ça fait doublon.
Ca permet plus de flexibilité pour l'utilisateur. Il peut faire hériter sa propre classe Player, Actor ou Spaceship de Transformable au lieu de Sprite et à la place il utilise un attribut de son choix pour s'attacher à un Drawable autre que VertexArrays. Ça permet entre autre de pouvoir changer de Drawable en gardant les mêmes transformations. Par exemple, ça permet de simplifier les groupes. On crée un seul Transformable auxquels plusieurs Drawable sont liés.
-
Ce post ne fait-il pas doublon avec http://fr.sfml-dev.org/forums/index.php?topic=7765.msg51740 ?
-
Héhé, non, je n'irais pas jusqu'à dupliquer mes posts pour les faire accepter ^^.
Dans ce topic, je parle simplement de mettre setColor et d'autres méthodes directement dans Drawable, mais elles resteraient utilisables dans Sprite et les autres. Ici, je propose carrément d'enlever les setPosition, setScale, setRotation, etc. de Sprite et des autres, pour séparer le visuel du côté plus "physique" ou "mathématique".
-
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), mais j'ai quand même voulu garder la simplicité des classes actuelles (reprises de 1.6), car la plupart des gens les utilisent comme ça.
-
tu peux ignorer la transformation du sprite et lui en passer une perso lors du draw
Ca risque d'être lourd en mémoire, non ?
car la plupart des gens les utilisent comme ça
N'est-ce pas une erreur ? Et de toute façon, tout le monde est obligé de les utiliser comme ça, à moins de changer le code source de la SFML ^^. Les habitudes changeraient sûrement avec cette séparation.
Quant à la simplicité, elle ne vaut que pour les mini, mini jeux. Dès qu'on fait quelque-chose de plus élaboré, on butte dedans.
La séparation entre Texture et Sprite est quelque-chose de similaire, même de très similaire : Sprite représente la partie plus mathématique, et Texture la partie graphisme. On peut lier plusieurs Sprite à une même Texture, avec des pointeurs.
-
Ca risque d'être lourd en mémoire, non ?
Bof, non. On n'est pas en train de parler de 1 000 000 d'entités à afficher sur un système embarqué avec 32 Mo de mémoire.
N'est-ce pas une erreur ?
Disons qu'il faut que le S de SFML garde son sens. C'est sûr que si je laissais uniquement sf::VertexArray et sf::Transform ce serait suffisant, mais dans ce cas autant taper dans OpenGL directement.
Et de toute façon, tout le monde est obligé de les utiliser comme ça, à moins de changer le code source de la SFML
Non, c'est justement tout l'intérêt de la nouvelle API graphique de SFML 2 : rien n'est forcé, on peut toujours utiliser le système comme on veut.
Quant à la simplicité, elle ne vaut que pour les mini, mini jeux. Dès qu'on fait quelque-chose de plus élaboré, on butte dedans.
Visiblement non ; et là je ne te parle pas de mon ressenti personnel, mais des années passées d'échange avec les utilisateurs.
La séparation entre Texture et Sprite est quelque-chose de similaire, même de très similaire : Sprite représente la partie plus mathématique, et Texture la partie graphisme.
... et j'ai remis les fonctions les plus utilisées directement dans sf::Texture (principalement les load) pour garder en simplicité, et que sf::Image puisse ne pas être utilisé dans 90% des cas.
-
Salut Lolman,
Beaucoup de post en peu de temps où la SFML est malmenée mais tient bon, grés et vents !
Je me permet de poster dans ce topic car tu parles de la séparation d’entités entre visuel et géométrie.
Tu as de bons arguments, mais qui ne correspondent pas à la simplicité requise pour la SFML.
Je développe actuellement une librairie qui fait la distinction entre ces deux concepts. Elle se concentre sur tout le côté géométrique des objets, avec les opérations et interactions associés. Une autre lib lie ce côté géométrique à l'aspect affichable (via SFML), et une autre le lie avec la physique.
Tout ça pour dire que si la SFML ne te convient pas directement y'a plusieurs autres libs qui pourraient la compléter (en perdant un peu de simplicité) que tu pourrais utiliser (je pense à Thor aussi).
-
D'accord, le défaut est le manque de simplicité... Zinlibs, ton projet m'intéresse beaucoup, je vais aller le voir très sérieusement ^^. C'est vrai qu'avec du type erasure, des libs qui se posent en couche, etc., on peut arriver à faire des hacks pour implémenter son design. Mais si ces changements sont bons, il n'y a pas de raison pour que ce soit l'utilisateur qui les implémente.
-
En enlevant les attributs de Drawable de Shape, on pourrait utiliser cette classe pour les bounding boxes, et à tout moment, pour du debugging par exemple, les attacher à des Drawable afin qu'on puisse visualiser les collisions sans vraiment changer le code.
-
Pourquoi le fait d'avoir plus d'attribut que nécessaire te rebut???
Qui peut le plus, peut le moins ;D
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).
Là on est vraiment dans la problématique :
Le malheur des uns, fait le bonheur des autres
De toute manière avec l'approche de la sortie de SFML2, ce genre de changement n'est pas envisageable(ce propos n'engage que moi).
-
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 :P.
Qui peut le plus, peut le moins
Mais 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 autres
Et 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
.
Je suis sûr que ça éviterait à 99% le comportement que Laurent abhorre : la création d'un design basé sur les Sprite, les Shape, etc. puisque ce serait impossible >:(. 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().
Personne ne sera tenté de faire :
class Player : sf::Sprite {
};mis dans une collection hétérogène de sf::Drawable.
Et un jour, quand on veut que le joueur soit fait avec plusieurs sprites
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.
-
En premier, une consommation mémoire inutile (c'est bête en C++), et une mauvaise conscience :P.
Citer
Ca risque d'être lourd en mémoire, non ?
Bof, non. On n'est pas en train de parler de 1 000 000 d'entités à afficher sur un système embarqué avec 32 Mo de mémoire.
Ma fois, je ne saurais te répondre ici, ne connaissant que Box2D de nom et pas DebugDraw. Peux-tu préciser vite-fait ?
DebugDraw est une classe abstraite qui permet d'implémenter diverse fonction dessin comme un rectangle, une ligne, un cercle...
Le but étant de donner un objet de type Debug Draw à notre monde pour qui se dessine automatiquement dans une logique de debug. Généralement je rend mes objets graphiques transparents et je peux observer en dessous le monde physique.
j'ai ma propre classe Shape et mes propres Rectangle, Circle, etc.
(mes propos) Laurent souhaite que nous évoluons ainsi. Mais je suis incapable de faire de même ;D
Vivement les tutoriels qui vont bien ;)
Et 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
Dés le départ??? Lors de la création de SFML1??? L'idée n'était pas encore envisagé. Actuellement tu peux coder à l'ancienne ou à la nouvelle méthode. Peut-être une fois la nouvelle méthode adapté dans plus de projet...
(Mon point de vue) Normalement tu ne fais pas hériter player de Drawable, mais GraphicPlayer qui sera un attribut de Player.
-
Je vais préciser le :
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 !).
Ensuite, une consommation mémoire inutile, qui doit être faite pour éviter un mauvais design, est tout simplement, comme le nom l'indique, inutile. Elle n'a pas lieu d'être. Elle est facilement contournable. Mieux encore, elle force à choisir le bon design, à faire ce que toi et Laurent pensez !
Je me souviens d'une version plutôt récente d'OpenGL qui "cassait" aussi ses fonctions et nous laissait ainsi plus de libertés, d'augmentations de performances, etc., car ces fonctions réunissaient sûrement plusieurs opérations ensemble alors que certaines n'étaient utiles que dans certains cas.
Sur ce coup, je suis sûr d'avoir raison. A la limite, au diable mes qui consistent à "remonter" des méthodes, si c'est pour considérer celle-ci. D'un point vu théorique reconnu par tous et au niveau de mon expérience personnelle, qui selon Laurent est plutôt répandue chez les débutants puisqu'il veut absolument éviter les comportements qu'induisent la réunion des attributs de Transformable et de Drawable dans Sprite, etc., j'en suis convaincu.
Certes, pour faire un "Hello World" + Sprite, il faudra créer un objet supplémentaire et appeler une fonction en plus. Mais sur tous les autres projets, utilisant des classes Player, etc. contenant un attribut Drawable permettant de la flexibilité, évitant de transmettre tous les attributs à son Drawable puisqu'il utilisera directement celles de la classe le contenant, etc., des lignes de codes seront même gagnées.
En tout cas, merci, Orwel (Georges ?), de faire vivre le sujet :).
-
Honnêtement j'ai oublié le propos de cette discussion (ça fait longtemps, et puis t'avais posté toutes tes idées en même temps à l'époque), donc si tu pouvais faire un petit résumé de ce que tu proposes au final, j'avoue que ça ne me déplairait pas ;D
-
Laurent pointe le bout de son nez ! Vite, entraînons-le dans une discussion de laquelle il ne pourra plus sortir et sera donc contraint d'accepter le changement.
En pratique le changement est assez simple et ne s'appuie sur aucune de mes autres idées. Il est principalement exprimé dans le premier post et consiste en ce qui suit :- Enlever l'héritage de sf::Transformable dans toutes les filles de Drawable qui en héritent, comme Sprite, Shape et Text, mais pas VertexArray
- A la place, créer une méthode attachToTransformable(sf::Transformable&) afin que les attributs de ce sf::Transformable soient appelés dans le Draw()
Je pense que c'est tout. Après, tu auras sûrement d'autres idées plus astucieuses quant à l'interaction entre le Drawable et le Transformable mais ça devrait ressembler à ça.
Ce qui fait couler le plus d'encre, en revanche, c'est le débat sur l'application de ce changement :P. Je pense avoir le mieux répondu dans mon message précédent, et j'attends avec impatience de nouveaux arguments !
-
Je pense que la première réponse que j'ai donnée dans cette discussion est toujours d'actualité.
En ce qui concerne l'éventuelle application de changements, j'ai aussi répondu plusieurs fois : pas avant SFML 3 de toute façon, donc autant dire qu'on est dans du très abstrait là.
-
Oui, mais même si ces changements sont effectués dans ans ils pourraient ne nécessiter que 5 minutes de code.
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.
Mettre sf::Transformable et sf::Drawable dans sf::Sprite et les autres, c'est comme mettre sf::Texture directement dans sf::Sprite.
-
Je suis d'accord mais malheureusement on ne vit pas dans ce monde où tout est carré et bien séparé. Il y a des gens qui ne font pas des gros programmes bien structurés et qui veulent garder le niveau de simplicité initial, je ne peux pas aller contre ça.
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.
-
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;
}
-
Le problème, avec un attachTo, c'est qu'on aura deux objets liés l'un à l'autre mais dont la durée de vie est gérée par l'utilisateur. Avec les problèmes que l'on connaît pour Sprite/Texture, Font/Text, etc. Si ce n'est pas extrêmement nécessaire, je préfère éviter ce genre de design.
Ensuite, faute d'avoir un design parfaitement carré, on a de la bonne doc, de bons tutoriels, et du bon support sur le forum. C'est déjà pas mal.
Ensuite, il y a beaucoup plus d'utilisateurs qui préfèrent la simplicité des classes actuelles, que d'utilisateurs qui construisent un truc complexe et utilisent les classes comme tu le décris. Gérer une bibliothèque avec beaucoup d'utilisateurs, c'est aussi savoir faire des compromis. Surtout quand on a un "S" dans le nom.
Et enfin, étant donné que ça ne se ferait pas avant SFML 3, pourquoi ne pas attendre d'avoir du recul sur la façon dont SFML 2 est utilisée ? Elle n'est pas encore sortie, ça me paraît un peu tôt pour refaire le monde.
-
Oui, quand les allocations dynamiques pointent leur nez, c'est pas génial.
de bons tutoriels
Pourrait-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 compromis
En 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.
Quant à l'utilisation de SFML2, je ne suis pas sûr que les utilisateurs remarquent la nouvelle Transformable et qu'en plus ils aient l'idée de bousculer leur design actuel pour l'hériter, en sachant que Sprite et les autres le font déjà. Si tu veux, on peut arrêter d'en parler temporairement ^^.
-
Je pense qu'on peut en effet arrêter d'en parler pour le moment. Je vais expliquer tout ça dans les tutoriels, et j'observerai ensuite la façon dont les gens utilisent les nouvelles classes. Et puis là j'en tirerai les leçons qu'il y a à tirer.
-
D'accord. Que penses-tu de faire un sondage demandant : votre code ressemble-t-il plus à ça :
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 ;).
D'ailleurs, comment t'y prends-tu actuellement pour voir la façon dont les gens se débrouillent ? Tu le fais à partir des demandes d'aides ?
-
On ne va pas faire de sondage maintenant, ce serait idiot.
Et pas besoin de sondage d'ailleurs, puisque quand les gens ont un souci ou une question ils viennent en parler ici :P
Et lorsque les gens n'ont pas de problème alors je n'en ai pas non plus.
-
Oui, pas maintenant.
Mais je ne pense pas que tous viennent partager leurs problèmes : je ne l'ai jamais fait, par exemple, mais ces sujets m'ont au passage fait avancé.
Le sondage n'est pas du type "avez-vous un problème ?", mais plutôt "Quelle structure utilisez-vous en ce moment ?". La pire des structures proposées peut fonctionner à un certain niveau et l'utilisateur en question peut ne pas la changer et ne pas demander de l'aide ici.
Les sondages sont simples à mettre en place et ont beaucoup plus de participation qu'un forum. Ils vont très bien de paire avec les forums.