Sujets

1

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.

2

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

« le: Mai 01, 2012, 09:42:55 pm »

Les Vector2 sont beaucoup utilisés pour les coordonnées, les vecteurs, etc. C'est un effort d'écriture, et d'autres auraient eu peur pour la performance, mais finalement c'est plus beau.
On trouve donc des Vector2 dans les attributs Position, Size, avec leurs accesseurs et mutateurs correspondants - j'ai vu que récemment GetWidth() et GetHeight()  avaient été remplacés par un getSize() dans Image dans SFML2 -, mais pas dans une seule classe : Rect ! Elle est définie avec left, top, width, height. Du coup, on perd l'avantage du tout-Vector2, et on doit faire setPosition(unRect.left, unRect.top) au lieu de setPosition(unRect.topLeft) par exemple. Pourquoi ne pas créer un rectangle à partir d'un point Position ou TopLeft et d'un autre Size ? RectangleShape le fait.
D'autre part, devrait-on systématiquement conserver deux fonctions de de type int, int pour l'une et Vector2 pour l'autre, comme on le voit dans setPosition, setScale, setOrigin, setCenter et move ? Je pense que ça encourage plutôt à utiliser des coordonnées séparées partout, et à ce moment-là on recommence à créer des Vector2 et à en extraire les coordonnées en permanence, ce qui allonge le code.  Laurent, tu disais :

toi tu voudrais du minimalisme (pourquoi faire ?) alors que moi je privilégie les noms explicites et qui s'auto-documentent.

3

Suggestions de nouvelles fonctionnalités / L'affichage

« le: Mai 01, 2012, 05:03:32 pm »

Je sais que des propositions d'ordre d'affichage ont déjà été refusées, mais je trouve plusieurs choses curieuses :

• Pourquoi afficher un sprite en-dehors de la View réduit-il les performances ? En fait, je me demande s'il est possible d'afficher ainsi en dehors d'une View, et donc d'une fenêtre, sans que rien ne "déborde" au final. J'imagine que s'il y avait effectivement un affichage qui dépassait ainsi, ça serait visible, et que comme ce n'est pas le cas, rien n'est affiché. Donc pourquoi faut-il que l'utilisateur vérifie que le Drawable est bien dans la View avant de l'afficher pour gagner des performances ? Un tel travail n' est-il pas déjà fait dans Draw() ? Sinon, devrait-il l'être ?
• Ne serait-il pas intéressant de faire du dirty rectangle drawing comme la SDL ?
• Sinon, si on continue à tout ré-effacer avant d'afficher, pourquoi ne pas afficher en partant de la fin pour ne pas avoir à écraser les Drawable les plus au fonds par ceux les plus au-dessus ?

4

Suggestions de nouvelles fonctionnalités / [Déjà fait] sf::Texture : les Surface de la SDL ?

« le: Mai 01, 2012, 03:50:35 pm »

Avec SDL, tout ce qui est affichable est dessiné dans une Surface. C'est un rectangle qui délimite une surface de dessin. Ces rectangles sont très puissants pour certaines raisons, mais aussi pour une autre que je vais présenter ici.
Vous savez que les Sprites utilisent en fait des Textures et les utilisent avec leurs fonctions héritées de Transformable : setScale, setPosition, etc. et de Drawable : draw (dans un autre sujet je propose de mettre quelques fonctions de Sprite dans Drawable pour que tous les enfants puissent en profiter). Ces Texture peuvent être modifiées, et ensuite copiées vers une image. Ca permet, par exemple, de faire un logiciel de dessin qui chargent une Image initiale, la mettent dans une Texture qui est mise dans un Sprite, y appliquer des filtres comme setColor ou setScale, et ensuite de la sauvegarder sur le disque, en faisant un Texture.copyToImage(). Vous avez peut-être aussi remarqué que vous pouvez créer une Image, une Texture, ou un Sprite "vide", mais d'une certaine dimension, qui sera affiché comme un rectangle blanc de cette dimension. Je pense que ça ressemble très fortement aux Surface de la SDL.
Ou est-ce que je veux en venir ? Je vous ai donné l'exemple du logiciel de dessin qui charge une image, passe des filtres, et la sauvegarde sur le disque. Mais ça ne fonctionne qu'avec le trio Image/Texture/Sprite. Tous les Drawable pourraient avoir une fonction copyToImage pour être sauvegardés comme ça sur le disque. Ca permettrait de faire un logiciel de dessin encore meilleur, et de dessiner des rectangles dedans, d'y afficher du texte, et de sauvegarder tout ça sous la forme d'une image !

Avec les Surfaces de la SDL et la puissance d'OpenGL, le monde va trembler devant SFML.

5

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

« le: Mai 01, 2012, 03:35:08 pm »

Ce serait intéressant de pouvoir appliquer des transformations sur Image ou Texture (je n'ai pas compris la différence clairement) : scale, setColor, flipHor/Vert, etc. Ainsi, les méthodes seraient utilisables sur les Images/Textures, ce qui les modifierait en mémoire, et sur les Sprite, qui agiraient un peu comme des filtres inoffensifs sur leur texture. Dans pyglet, les groupes sont des collections d'objets affichables qui définissent, pour simplifier, des "filtres" à appliquer sur leur ensemble, même s'il s'agit simplement de l'ordre d'affichage. Et devinez quoi, les Sprites sont aussi des groupes à une image, et ils agissent donc aussi comme des "filtres".
Mais, quelle classe, entre Image/Texture et Sprite doit implémenter ces fonctions ? Je pense que, tel que le design est défini, ça doit être Sprite. Il peut toujours modifier sa texture source à partir de ses transformations, s'il le veut.

Une partie de ces méthodes est déjà implémentée dans les classes supérieures : scale et rotate dans Transformable, etc. donc Sprite en hérite. Mais je pense que toutes ces fonctions de transformation pourraient être implémentées dans les classes supérieures. Pour Drawable par exemple, des méthodes comme setColor et FlipHor/Vert, ou même setSmooth permettraient de faire des effets intéressants sur du texte ou des figures. En effet, Text implémente sa propre version de setColor, par exemple, et Sprite aussi, mais Shape n'en a pas de globale. C'est l'occasion de tout remonter vers Drawable ! (D'autre part, cet setColor pourrait s'appeler setTint ou setTintColor, non ?). On peut penser qu'il définit la couleur de fond d'un sprite, à moitié transparent par exemple, ou je ne sais pas quoi. En donnant tant de puissance à Drawable, on peut, si View hérite de Drawable comme je le suggère dans un autre sujet, faire une espèce de gallerie des glaces avec des flip et appliquer un filtre de couleur sur  tous les objets, pour par exemple assombrir quand c'est la nuit. Mais même si ma proposition d'héritage de Drawable par View est rejetée, on pourra quand-même retourner du Text, par exemple, pour crypter comme le faisait Léonard de Vinci.

6

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

« le: Mai 01, 2012, 03:14:42 pm »

Quand on regarde les méthodes de View et celles de Transformable, on voit beaucoup de similitudes : move, rotate, etc. On peut considérer que zoom est comme scale. View hériterait aussi de setPosition, de setOrigin, dont je suis sûr qu'on peut trouver une utilité, ce qui évite d'avoir tout le temps recours à reset au profit de setPosition, parfois. Par contre, setCenter() pourrait garder sa place.
Comme je l'ai dit dans un autre sujet, setSize et reset pourraient être remplacés par setRect, etc.
En allant plus loin, View pourrait-elle être Drawable ? D'un point de vue technique, je pense que ce n'est pas le cas actuellement, mais ça pourrait... et ça bouleverserai aussi tout le système des coordonnées.

7

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

« le: Mai 01, 2012, 01:55:59 pm »

C'est une chose bien pratique dans la SDL. On peut déjà utiliser getPosition() sur tous les Drawable, mais GetSize() ne fonctionne que sur Sprite, Texture et RectangleShape. Ce serait d'en faire une méthode virtuelle pure de Drawable et de pouvoir l'utiliser sur Text, Shape. L'avantage est que dans les trois que j'ai cités au début, la méthode renvoie simplement un attribut, mais que pour les autres le calcul pourrait être fait à la volée, à moins que Drawable ait un attribut Rect et plus de Position. Dans ce cas, on pourra même changer Left et Top par X et Y, étant donné que les Rect seront présents partout. Je viens juste de voir Text.getLocal/GlobalBounds, qui pourrait aussi être remplacé par un getLocat/Global/Rect. D'autre part, certaines fois je vois bounds et d'autre fois rect, quelle est la différence ?
Dans ce sujet du forum Anglais, ça serait utile avec ce que propose Tex Killer.
En ce qui me concerne, ça me permettrait par exemple de centrer un exemple sans utiliser des calculs sur getGlyph() approximatifs et d'implémenter une optimisation du Draw des éléments dans une View : seuls les éléments dont les Rect entrent en collision avec celui de la View seront affichés, alors qu'en ce moment je ne sais pas comment faire avec ma collection hétérogène . Sprite a une méthode setTextureRect(), mais tous les Drawable pourraient avoir ce setRect qui définirait la surface affichée !
Enfin, ça pourrait simplifier les calculs de collision et rendre sf::Rect::Intersects plus célèbre, du moins dans mon code .

Je me demande aussi si un tel attribut rect devrait appartenir à sf::Transformable ou sf::Drawable. Pour l'instant, le Vector2 de position est dans Transformable, donc il est logique qu'on y mette aussi le Size, et donc le Rect entier. Ca permettrait de séparer encore plus le visuel de la "logique".

8

Suggestions de nouvelles fonctionnalités / [Refusé] Suggestions minimes sur quelques identificateurs

« le: Mai 01, 2012, 01:54:16 am »

Voici quelques propositions de simplification, de généralisation ou de raccourcissement des noms de fonctions.

Window
setVerticalSyncEnabled => setVerticalSync
Du moment que le type est bool, y'a-t-il besoin du Enabled ? Pour setSmooth par exemple, il n'y est pas.
isOpen => isOpened ou opened

Image
flipHorizontally => FlipX
flipVertically => FlipY
Les sf::Vector, par exemple, sont toujours en x et y, aussi bien pour GetPosition() que pour GetSize(), et on n'a pas de w et de h. De même
Sprite possédait des méthodes  FlipX() et FlipY(), qui semblent d'ailleurs avoir disparu.
getPixelsPtr => getPixels
Le type de retour n'est-il pas assez explicite ?

Rect
left => x
top => y
J'ai bien aimé le changement de right et bottom en width et height, et pourquoi s'arrêter là ? D'ailleurs, x et y sont plus courts à écrire .

Keyboard
isKeyPressed => isPressed voire pressed
Comme il s'agit de la classe Keyboard, et que cette fonction est la seule, on peut comprendre qu'il s'agit de touches, d'autant plus qu'on s'apprête à mettre un paramètre de type Key. Quant au "is", le retour de type bool et la fin en "ed" indiquent qu'on veut obtenir un état.
On pourrait même renommer Keyboard en Key, ou pas.
Mouse
isButtonPressed => pressed
Joystick
isButtonPressed => pressed
getButtonCount => buttons ou getButtonSize
Pour faire court ou se rapprocher du size de std::vector.
Avec tout ces pressed partagés entre Keyboard, Mouse, et Joystick, on pourrait s'en souvenir facilement.

D'ailleurs, Keyboard, Mouse et Koystick ne devraient-ils pas être regroupés sous Event ? Mais ça serait un peu long...

Clock
getElapsedTime => getElapsed ou elapsed
Puisque le type de retour est Time.
Time
asSeconds => s
asMilliseconds => ms
asMicroseconds => us
Comme les unités officielles.

D'autre part, est-ce que appeler Time() ne revient pas à utiliser Zero ?

Enfin, pourquoi ne pas enlever les marques d'accesseurs et mutateurs "get" et "set" ? Par exemple, jQuery le fait. $('tag').attr('truc') récupère l'attribut truc de la balise tag et $('tag').attr('truc', 'foo') donne la valeur foo à truc de la balise tag. Généralement, quand il n'y a pas de paramètre, c'est un accesseur, et c'est certain quand la fonction est constante. Le choix est dur : réduire la plupart des noms de fonctions de trois lettres ou risquer de semer le doute dans l'esprit des utilisateurs débutants de SFML ?
De la même façon, on peut garder ou enlever les "is".

Sinon, j'ai remarqué que dans le changelog, les nouvelles fonctions ne sont pas indiquées en camelCase.

9

Suggestions de nouvelles fonctionnalités / [Résolu] Une classe Group héritant de Drawable

« le: Avril 27, 2012, 10:52:05 am »

EDIT : une page sur le wiki a été créée.

Je pense qu'il manque un dernier enfant à Drawable pour que la famille soit complète. Dans d'autres frameworks, comme Pygame ou Pyglet, j'ai récemment remarqué que cette classe était déjà implémentée. Avant, j'avais vite trouvé le besoin de la créer, et je pense qu'à partir d'un certain niveau d'abstraction tout le monde en a besoin.

Code: [Sélectionner]

#ifndef GROUP_INCLUDED_HPP
#define GROUP_INCLUDED_HPP

#include "Drawable.hpp"

class Group : public sf::Drawable, public std::vector<sf::Drawable*> {
public:
Group();
~Group();

void render(sf::RenderTarget&) const;
};

#endif

Code: [Sélectionner]

#include "group.hpp"

Group::Group() :
sf::Drawable(),
std::vector<sf::Drawable*>() {
}
Group::~Group() {
for(std::vector<sf::Drawable*>::iterator i = begin(); i != end(); ++i) {
delete *i;
}
}

void Group::render(sf::RenderTarget& Tar) const {
for(std::vector<sf::Drawable*>::iterator i = begin(); i != end(); ++i) {
Tar.draw(*i);
}
}