Messages

16

Suggestions de nouvelles fonctionnalités / Re : Déshériter Sprite et ses soeurs de Transformable

« le: Mai 02, 2012, 10:14:02 pm »

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.

17

Suggestions de nouvelles fonctionnalités / Re : Image/Texture, Sprite et Drawable : remonter des méthodes

« le: Mai 02, 2012, 08:27:48 pm »

Tu as raison : les prochaines fois, au lieu de poster sur le coup, je ferai des sujets plus concis, clairs, illustrés, etc. C'est vrai qu'on pourrait en discuter sans perdre de temps à se répéter ou mal se comprendre.
Pour finir, je suis d'accord quand Ceylo dit que la SFML a l'avantage d'un bon design, qui de base met sur une bonne voie. Sinon,  pourquoi utiliser le C++ et faire des classes ? Le C est idéal pour faire des toolbox qu'on peut utiliser dans tous les sens.
Et quand je parlais de casser les Sprite, etc. Je voulais dire les deshériter de Transformable, ce qui enlèverait l'héritage multiple, que n'a pas certains langages. Et remonter setColor et les autres ne créeraient aucun polymorphisme, ce sont juste des mutateurs et accesseurs de bases. En fait, je dis ça mais je n'en suis pas sur mais je ne trouve pas les fichiers .cpp dans la doc.

18

Suggestions de nouvelles fonctionnalités / Re : Déshériter Sprite et ses soeurs de Transformable

« le: Mai 02, 2012, 12:11:04 pm »

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.

19

Suggestions de nouvelles fonctionnalités / Re : L'affichage

« le: Mai 02, 2012, 11:14:02 am »

Aaah, merci bien, c'est très pratique, en effet. Oui, les templates, super .

20

Suggestions de nouvelles fonctionnalités / Re : Image/Texture, Sprite et Drawable : remonter des méthodes

« le: Mai 02, 2012, 11:00:52 am »

et setColor n'en a pas dans Shape

Avec OpenGL, on ne peut pas le faire ? setColor a selon moi du sens sur tous les graphismes. S'il en a dans Sprite et même dans Text, pourquoi pas dans Shape ? D'ailleurs, Shape a déjà deux méthodes de couleur, et une plus globale paraît logique.

Je veux qu'ils utilisent des collections hétérogènes de leurs propres classes, avec des sprites, textes, etc. comme attributs de certaines.

Dans mon code, j'ai créé une classe AnimationSprite qui hérite de Sprite et une classe MovingSprite qui en hérite. J'ai cherché à séparer "Moving" de "Sprite", mais le problème, c'est que la position, la rotation et toutes les autres opérations intéressantes sont dans Sprite, Text, etc. ! Je pense que casser ces Drawable forcerait à coup sûr les utilisateurs à faire leur propre design, et c'est quand-même plus propre d'un point de vue théorique. En plus, ça évite l'héritage multiple, et ça facilite le portage vers d'autres langages (je ne sais pas comment c'est fait dans les autres, actuellement). Et là, ce sera comme tu dis, Sprite et les autres ne seront que des attributs, des classes sans incidence dans la partie principal du code.

Comme je l'ai dit, getGlobalBounds n'a pas de sens dans VertexArray

Si j'ai bien compris, VertexArray, c'est une Shape de plus bas niveau. C'est toujours pratique de connaître la place occupée par un objet. C'est vrai que cette classe est un peu problématique : elle possède en même temps des informations de Transformable (des coordonnées), et de Drawable (la couleur). C'est donc un peu des deux, mais elle n'hérite quand même pas de Transformable. D'ailleurs, Shape a le même problème : elle contient des points et des couleurs en même temps, mais elle fait mieux parce-qu'elle sépare quand-même les positions des couleurs au niveau des attributs. Donc, il se pourrait que ces classes géométriques, en particulier VertexArray, s'intègrent un peu mal dans le design et bloquent donc l'évolution. La solution serait là encore de séparer l'aspect Transformable et l'aspect Drawable.

21

Suggestions de nouvelles fonctionnalités / Re : Un peu plus de Vector2

« le: Mai 02, 2012, 10:40:11 am »

OK, j'aurai tout mon temps pour éditer le titre.

22

Suggestions de nouvelles fonctionnalités / Re : Une méthode get/setRect() pour tous les Drawable

« le: Mai 02, 2012, 10:38:31 am »

Dans ce cas c'est scale dont tu parles.

Oui, c'est un scale, mais qui prend des coordonnées absolues. D'ailleurs, s'il y a un attribut scale, il faut aussi un attribut size, parce-que sinon ce scale n'opère sur rien dans l'objet Transformable .

Et les "setters" pour la taille sont déjà là, ils sont juste un peu cachés : setTextureRect, setCharacterSize/setString, etc.

Justement, pourquoi les "cacher" ? Ces méthodes sont en quelques sortes dupliquées inutilement dans les enfants.

Code: [Sélectionner]

Transformable {
  //rien
}
Sprite {
  setTextureRect
}
Text {
  //la fonction manque à cette classe
}
RectangleShape {
  setSize //un nom différent
}

23

Suggestions de nouvelles fonctionnalités / Re : Déshériter Sprite et ses soeurs de Transformable

« le: Mai 01, 2012, 11:57:04 pm »

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".

24

Suggestions de nouvelles fonctionnalités / Re : Un peu plus de Vector2

« le: Mai 01, 2012, 11:54:21 pm »

C'est vrai que les sucres syntaxiques manquent beaucoup au C++. C'est l'une des grandes raisons pour lesquelles je suis souvent tenté d'aller du côté des langages "de scripts" ou fonctionnels plus souvent.

25

Suggestions de nouvelles fonctionnalités / Re : Une méthode get/setRect() pour tous les Drawable

« le: Mai 01, 2012, 11:52:25 pm »

setSize est à size ce que setPosition est à position, et de même avec setRotation et rotation, et tous les autres. En fait, en prenant cette règle, qui est la seule "règle des mutateurs", on pourrait en venir à mettre setColor et color. C'est pourquoi la deuxième règle est que l'élément doit correspondre à une donnée euh... mathématique disons. Il se trouve que position et origin sont des points. Et size est aussi un point.
Vu de cette façon, size semble avoir sa place. J'ai envie de dire... que changer la taille est une transformation de la zone prise par l'élément. Qu'en dis-tu ?

26

Suggestions de nouvelles fonctionnalités / Re : [Résolu] View : hériter de Transformable ?

« le: Mai 01, 2012, 11:51:40 pm »

C'est dommage que ce ne soit pas possible pour SFML2 : l'API restait la même pour une fois . C'est bon à savoir quand-même.

27

Suggestions de nouvelles fonctionnalités / Déshériter Sprite et ses soeurs de Transformable

« 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.

28

Suggestions de nouvelles fonctionnalités / Re : L'affichage

« le: Mai 01, 2012, 11:33:34 pm »

Je comprends pas le type erasure et je ne trouve pas de tutoriel .

29

Suggestions de nouvelles fonctionnalités / Re : Image/Texture, Sprite et Drawable : remonter des méthodes

« le: Mai 01, 2012, 11:32:04 pm »

Tiens, j'aime bien cette idée du scale négatif !

Je parle des transformations du type setColor, comment les appeler ?
Pour changer, je vais faire des "diagrammes" :

Code: [Sélectionner]

Drawable {
  Draw = 0 //methode virtuelle pure : bien. on peut faire des Draw sur des collections hétérogènes, ce qui est sûrement très courrant
}
Sprite < Drawable, Transformable {
  Draw //ok
  setColor //tiens, un truc specifique de Sprite
  getGlobalBounds //une autre méthode spécifique de Sprite
}
Text < Drawable, Transformable {
  Draw //ok
  setColor //mais c'était pas déjà dans Sprite? code répété
  getGlobalBounds //eh mais, c'était aussi dans Sprite ! pourquoi c'est pas fait comme Draw
}
RectangleShape < Drawable, Transformable {
  Draw //ok
  getGlobalBounds //encore ? ça aurait été bien pratique dans des collections hétérogènes
}
VertexArray < Drawable {
  Draw //ok
}Et a la place on fait

Code: [Sélectionner]

Drawable {
  Draw = 0
  setColor //cool
  getGlobalBounds //cool
}
Sprite < Drawable, Transformable {
  Draw //ok
}
Text < Drawable, Transformable {
  Draw //ok
}
RectangleShape < Drawable, Transformable {
  Draw //ok
}
VertexArray < Drawable {
  Draw //ok
}Comme ça, tout le monde profite de ces fonctions. Ca évite la répétition de code. Puisqu'il y a une classe mère, autant utiliser tout ce que permet la POO, non ? Actuellement, c'est fait pour Draw, mais pas pour les autres.
Ca permet de faire des trucs cool comme ça :

Code: [Sélectionner]

std::vector<sf::Drawable*> All;
All.push_back(Sprite(Player))
All.push_back(Map.load("truc.map")) //Map retourne un Group
All.push_back(sf::Text('Level 5'))
All.push_back(sf::WidgetCounter()) //WidgetCounter hérite de RectangleBox

/***
plus tard, dans le jeu, un appel a updateAfterPreferencesChange()
***/
switch(Preferences.themes) {
  case 'ambiance night'
    foreach elem in All {
      elem.setColor(sf::Color::Grey); //ambiance nuit => il fait sombre => on teint tout en gris, meme les widgets, cest stylé
    }
C'est écrit en pseudo-code, mais j'espère que ça montre à quel point ce serait utile.

30

Suggestions de nouvelles fonctionnalités / Re : Une méthode get/setRect() pour tous les Drawable

« le: Mai 01, 2012, 11:09:45 pm »

Quand on crée un Transform avec le constructeur par défaut, je suppose que tous les attribtus sont à 0, aussi bien rotation que le serait bounds.
Dans l'implémentation actuelle de Transform, il y a des attributs comme la position. Très bien. Pourquoi ne peut-il pas y avoir la taille, Size ? Ce sont tous les deux des points. Et a ce moment-là, Position et Size formeraient un Rect. scale peut très bien s'appliquer sur un Rect, rotate aussi, etc., comme on le voit avec getGlobalBounds().