Bienvenue, Invité. Merci de vous connecter ou de vous inscrire. Avez-vous oublié d'activer ?

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.


Messages - L01man

Pages: « Précédente 1 2 3 [4]
46
Ah, c'est donc déjà fait ! C'est sûrement nouveau. Merci pour l'info.
On peut recycler ce pavé comme l'histoire de la création de RenderTexture :).

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

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

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

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

51
Citer
Smooth est un adjectif, donc la texture est ou n'est pas smooth. Par contre, la fenêtre n'est pas synchronisation verticale, par contre elle peut l'activer ou non.
Je le lis plutôt comme : "utiliser la sync. ver.". Ou sinon : useVerticalSync, enableVerticalSync. Garder un "set" ici avec le "enable" reviendrait à vouloir écrire "getIsOpened" ou "getOpenEnabled" à la place de "isOpened".

Ah, je viens d'apprendre un peu d'anglais ^^.

Citer
Avec FlipX, on ne sait pas si on retourne [...] autour de X (verticalement).
Et avec FlipHorizontally, on pourrait aussi penser tourner autour de X ? N'est-on pas habitués aux machinX et machinY ? Sinon : symetryX et symetryY.

Citer
Tu penses vraiment que c'est clair, que (x, y) est le coin haut-gauche ?
Oui, l'axe est aussi inversé pour les Sprite et tout le reste ! Et dans les Drawable, les noms sont x et y. D'ailleurs, serait-ce une bonne idée de faire un Rect { sf::Vector2f Position, Size } ? Avec la SDL, tout ce qui se dessine est affiché dans une Surface, un Rectangle, quoi. Dans ce cas-là, appeler GetRect() renverrait GetPosition() et GetSize(). Ca permettrait de faire des calculs de collision plus généralisés sur des sf::Text et autres.

Citer
mais j'ai rien non plus pour à vrai dire.
C'est plus court et ça peut être généralisé à Mouse et Joystick. On peut inférer "touche" ou "bouton" puisqu'en effet on ne peut appuyer sur autre chose : "est-ce que le bouton {x} est appuyé ?" => "Est-ce que {X} est appuyé" ? Disons que dans la langue "pressed" est une méthode spécifique aux boutons ^^. Et d'une certaine façon une touche est un bouton. Contrairement à ces deux-là, un clavier ne peut qu'avoir des touches, et il ne peut pas y avoir d'ambiguïté avec des axes ou des molettes.

Citer
(j'ai l'impression que tu n'as pas remarqué ce point)
Si, c'est d'ailleurs pour ça que j'ai écrit cette phrase ^^. J'avais lu sur le forum que tout serait en camelCase dans la 2.0, et je l'ai aussi vu dans la nouvelle Doc', mais dans le changelog même les fonctions ajoutées sont écrites en CamelCase. D'ailleurs, j'ai voulu faire une regex pour remplacer "\.([A-Z])" par "\.upperase(\¡)" mais il n'y a aucune fonction pour ça >:(, et je dois dire qu'ici les "Get", les "Set" et les "Is" étaient bien plus pratiques à remplacer ;).

Citer
(pourquoi faire ?)
Pour tenter de raccourcir les noms, à vrai dire. J'essaie quand-même de "généraliser" les noms pour qu'ils restent explicites : quand on a utilisé un biduleX ou un isPressed on saura les utiliser ailleurs, sans changement comme "Horizontally" ou "Button/Key".
Citer
moi je privilégie les noms explicites et qui s'auto-documentent
Oui, c'est le plus important. J'essaie de voir si un compromis n'est pas possible.
Citer
Désolé, je ne retiens aucune de tes suggestions.
Oh ! c'est pas grave. Ca m'y a fait un peu plus réfléchir et ça va sûrement m'aider à utiliser de meilleurs noms.

Deux autres suggestions :
RenderWindow, RenderTexture
display -> draw
Comme pour les Drawable. C'est peut-être une mauvaise idée mais je suggère quand-même, on sait jamais.

52
Et voilà ! Notons quand-même qu'avec Haskell, par exemple, on écrirait simplement :
map draw group pour remplacer la méthode Draw().

53
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 :P.

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.

54
Désolé pour le titre. C'était pourtant un paragraphe sur l'accueil du wiki, mais peut-être pas assez visible. Il n'y a pas moyen d'afficher ce message sur la page d'édition ?
Voilà, j'ai précisé. En fait, qu'est-ce qui change, pour ce code, avec SFML 2.0 ? J'en déduis que je suis l'un des rares à encore utiliser la 1.6 :D. Je ferai bientôt le changement, alors.
Ca va mieux, pour le dtor ?

56
D'accord x). Pourrait-on au moins en proposer une version dans les tutoriels, afin que les débutants aient une base ?

57
Je vois. Pourtant, dans Pygame & cie., cette classe est bien présente et semble convenir à tous ! A vrai dire, les cas de figure qui seraient problématiques ne me viennent pas à l'esprit. On devrait les énumérer pour voir si une solution est possible. Par exemple, rendre Group abstraite pour que chacun l'implémente comme il veut ou fournir plusieurs Group qui couvrent toutes les utilisations.
En ce qui me concerne, je vois trois utilisations :
  • mettre ensemble les backgrounds, les tirs, ou les tiles ou autres éléments pour des calculs de collision sur leur ensemble par exemple ;
  • créer des couches pour l'ordre d'affichage ;
  • créer un objet complexe composé de parties articulées - des Sprite par exemple -, qui sont positionnées à partir des coordonnées de ce Group.
Dans le premier cas, le Group est sensé n'être détruit qu'à la fin du programme. Dans le deuxième, aussi. Dans le troisième, le Group est bien considéré comme un objet et pas comme un "tiroir", et ses éléments lui appartiennent. Donc, pour tous ces cas, il est normal que le Group détienne l'ownership.
On peut aussi très bien copier l'adresse d'un élément vers un autre endroit et faire un erase() pour que le Group n'ait plus cet ownership.

58
Ah, le problème est donc Group::~Group(). Dans ce cas, on peut ajouter une variable "hasOwnership" qui détermine si, à sa destruction, le groupe détruit ses items ou non.

59
Excuse-moi, que veux-tu dire par "ownership des éléments" ?

60
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.
#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
#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);
}
}

Pages: « Précédente 1 2 3 [4]
anything