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

31
EDIT : grillé
C'est ça. Mais on peut appeler Draw dessus, puisque c'est un Drawable lui-même. Ca permet de faire des
layers, de faire des corps articulés, des calculs de collisions sur un groupe précis d'objets en évitant de parcourir une liste entière d'objets, etc.

32
Je vais utiliser ton code, Koryushin :).
Yeah, une de mes propositions a été acceptée. Qu'en est-il de ma proposition d'enlever les méthodes de type set(x, y) au profit des set(vector) ?

33
Suggestions de nouvelles fonctionnalités / Re : L'affichage
« le: Mai 01, 2012, 10:07:03 pm »
C'est compliqué ???. Peu importe, je vais juste faire un Group par classe, et comme ça je saurais quelle conversion de type appliquer à quel groupe. Ce sera un peu sale, mais je le cacherai dans un draw() et y'aura pas de problème :D.

34
Oui, pardon, j'ai mélangé avec Sprite. Maintenant que flip n'est plus dans Sprite, il sera impossible d'avoir deux Sprites se partageant la même texture de deux côtés différents ?

Ah, je n'avais pas compris cet enjeu de la SFML. Maintenant, je ne sais plus trop quoi dire, mais en tant qu'utilisateur, je trouve le design de Sprite et du reste très bien pensé, et je regrette - juste un peu, la SFML est quand-même géniale - que ce design ne soit pas mené au bout du bout et soit bloqué à mi-chemin. Sprite et les autres pourraient rester des classes utilitaires, même si certaines de leurs opérations étaient remontées dans Drawable, afin de permettre à ceux qui préfèrent une SFML nickel de l'utiliser plus au centre, et pour ceux qui ne le veulent pas, il ne sont pas obligés de s'en servir comme d'un framework. Encore une fois, remonter des méthodes ne changera pas le design d'un projet écrit en SFML 2.0, il permettra par contre d'utiliser de nouveaux design, et d'être plus ouvert.
Pour être sûr que l'utilisateur créera son propre design, on peut, en tenant ou pas en compte de ce que j'ai déjà proposé, taper un plus grand coup, et séparer les Drawable des Transformable. Sprite, Text, etc. seront juste des Drawable, et l'utilisateur devra créer sa classe Player, Spaceship, etc. héritant de Transformable et ayant un attribut Sprite ou Drawable, etc. De cette façon, on sépare totalement les graphismes du reste, et c'est l'utilisateur qui les arrange comme bon lui semble.

35
Quand je voulais dire qu'il n'avait pas de rotation, etc. je voulais dire que leur valeur était à 0, ce qui est aussi le cas pour la taille. Est-ce que les agrandissements et les réductions sont des transformations ?

36
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 :
Citer
toi tu voudrais du minimalisme (pourquoi faire ?) alors que moi je privilégie les noms explicites et qui s'auto-documentent.

37
D'accord ^^.

Citer
plus les gens se sentaient obligé d'en dériver. Je veux éradiquer ces comportements. sf::Drawable ne devrait même pas exister, à vrai dire.
Au détriment des possibilités offertes :( ? Ca complexifie le problème global :s ! Quelles classes font généralement les utilisateurs qui dérivent Drawable ? Et à vrai dur, ajouter des méthodes virtuelles pures à Drawable empêcherait d'une certaine façon les utilisateurs à implémenter un enfant qui fonctionne :D.
Remonter ces méthodes fait un beau parallèle avec sf::Transformable : chacun possède des méthodes de transformation, de filtre.
Citer
sf::Drawable ne devrait même pas exister
Vraiment ? C'est l'une des classes qui rend SFML très pratique !

Citer
Par exemple sf::Shape ne pourrait pas avoir setColor : il gère deux couleurs bien distinctes (fillColor et outlineColor).
De la même façon, Texture possède plein de couleurs différentes : une par pixel, ce qui ne l'empêche pas d'avoir une méthode setColor() qui teint toutes ces couleurs.

Citer
il n'y a pas de fonction OpenGL magique qui fonctionne indépendamment de ce que l'entité est. Par exemple, regarde l'implémentation de setColor.
D'accord, il faut des fonctions virtuelles pures dans Drawable à ce moment-là. Mais peut-être pas... Comment les transformations de Transformable fonctionnent ? Les méthodes définies dans cette classe éditent simplement des attributs, je suppose. La vraie utilisation se fait dans le Draw. De la même façon, on peut avoir de bêtes accesseurs et mutateurs dans Drawable et leur utilisation se ferait dans les héritières.

Citer
C'est même un peu contre-productif d'en discuter maintenant.
Je vais arrêter, alors ^^.

38
Suggestions de nouvelles fonctionnalités / Re : L'affichage
« le: Mai 01, 2012, 08:33:26 pm »
En ce qui concerne mon problème, la solution est bien getGlobalBounds(), mais comme elle n'est pas une méthode virtuelle et que je n'ai qu'une collection hétérogène de Drawable, pas moyen de laisser le C++ faire le boulot pour moi ou de faire une conversion de type.

39
Citer
un sf::Transformable instancié directement n'aurait aucune taille, l'information et donc la fonction seraient inutiles, voire hors de propos dans ce cas.
Un sf::Transformable instancié directement n'a aussi aucune position, aucune rotation, etc. En fait, un sf::Transformable vide, quels que soient ses attributs, n'a aucun sens : il faut le remplir d'information. Qu'est-ce qui est gênant ? De la même manière qu'on indique l'échelle, on indique la place prise par l'objet. C'est une information utile, et tous les dignes héritiers de Transformable peuvent la remplir. Une réduction de la surface, de bounds, est aussi une transformation.
Citer
Mauvaise approche. SFML aborde les choses autrement, mais ça n'empêche que quelque soit ton cas d'utilisation, tu peux toujours reproduire un équivalent avec SFML.
Oui, je propose juste en complément. La fonction existe sous le même nom dans  toutes les classes filles, mais pas dans la classe mère ! Ca me paraît une excellente occasion de "remonter", et sinon ça pourrait indiquer une autre faiblesse.
Les Rendering Masks ne pourraient-ils justement pas être ce paramètre de transformation, sous un nom différent ?

40
OK, j'ai compris pour Image et Texture.

Par contre, je ne comprends pas pour la partie sur le "remontage". En fait, j'ai l'impression que mettre setColor uniquement dans Sprite et Text et les flip et setSmooth uniquement dans Sprite, c'est limiter leur utilisation. Pourquoi tous les Drawable ne pourraient pas être retournés, teintés, etc. ? Théoriquement, ça me semble juste et techniquement, j'imagine que c'est exécuté par OpenGL et qu'avec un peu de chance ça peut se faire pour tous les Drawable de la même manière. Je pars du principe que, lorsque je vois deux fois la même méthode dans deux classes qui héritent du même parent, et que cette méthode n'est pas définie chez le parent, alors elle devrait l'être. Ensuite, setSmooth, flip, etc. sont des transformations qui ne sont pas spécifiques à Sprite, de même que Draw n'est pas spécifique à Sprite. Disons que chaque enfant de Drawable permet de faire un dessin spécial, mais que tous doivent pouvoir être transformés de la même manière. Par exemple, ils peuvent tous utiliser setScale(), setRotation(), alors pourquoi pas flip() ?
Je ne comprends pas le problème d'ajouter des fonctions virtuelles pures. Drawable en possède déjà une, donc ça ne change rien pour elle. Normalement, l'utilisateur n'a pas besoin d'hériter Drawable, donc ça ne gène toujours pas. En plus, j'imagine, mais je me trompe peut-être lourdement, que la nouvelle classe Drawable pourrait ressembler à ça (je n'écris que les ajouts et les changements) :
class Drawable {
  public:
    Drawable(), my_isSmooth(false), /* etc. */ {
    }

    void setColor(sf::Color NewColor) {
      my_Color = NewColor
    }
    //etc. que des mutateurs et des accesseurs de base en fait

    //une nouvelle fonction Draw pour utiliser tous les paramètres

    void Draw() {
      if(my_isSmooth) {
        //fonction openGL pour activer le smooth
      }
      //fonction openGL pour passer un filtre de la couleur sur ce qui va etre dessine
      MainDraw();
    }

     //cest la fonction qui est redefinie dans les classes filles. comme ca pas besoin pour elles de toucher aux my_isColor, etc.
     void MainDraw() = 0;

  private:
    sf::Color my_Color;
    bool my_isSmooth;
    bool my_isFlipHorizontally, my_isFlipVertically;
}
En quoi ajouter plus de fonctions, à usage facultatif forcerait l'utilisateur à changer de concept ? En effet, remonter ces classes ne demanderaient même aucun changement de code du côté utilisateur, mais il pourrait faire plus de choses.

41
Suggestions de nouvelles fonctionnalités / Re : L'affichage
« le: Mai 01, 2012, 07:58:28 pm »
D'accord. On efface tout et on recommence ; c'est plus simple. Merci pour vos explications.
J'ai encore quelques questions pour le 1. Dans ce cas, comment ça se passe, techniquement, quand on dessine hors de la fenêtre sans que ça ne s'affiche au final ?
Citer
Si la partie logique de ton jeu est bien conçue tu devrais pouvoir faire ce test très facilement.
C'est très simple avec un tableau à deux dimensions de Sprite dont les indices déterminent la position. Ca l'est un peu moins quand on a un niveau dont les indices n'indiquent en rien cette position. Et c'est encore plus compliqué quand on a des objets autres que de type Sprite ! C'est pour ça que je rêve d'un attribut Rect chez les Transformable.

42
Citer
Et on peut changer leur position locale via setOrigin, donc ça pourrait très bien devenir le coin bas-gauche.
Ah, j'ai compris.

Je capitule. Merci à toi de m'avoir expliqué ces choix ;D.
@Hiura : oui, il y a toujours la solution de la regex quand on pas du tout d'accord ^^.

43
Citer
sf::Drawable n'a aucune notion de géometrie ni de transformation, donc elle n'a a priori aucun rapport avec le rectangle englobant
Oui, ces méthodes : getLocal/GlobalRect/Bounds, setRect/Bounds auraient plus leur place dans Transformable, puisque cette classe possède déjà l'attribut de position, soit le premier point de ce Rect.
En fait, ces méthodes ne seraient pas virtuelles pures : elles retourneraient simplement l'attribut Transformable.bounds de type Rect. Elles ne seraient même pas virtuelles du tout : c'est à chaque classe de faire un setBounds : quand on fait un setTexture(Texture, true) dans Sprite, quand on ajoute un point dans ConvexShape. Dans certains cas, comme getSize(), qui serait directement implémenté dans Transformable, car il correspond au deuxième point de l'attribut Transformable.bounds, les classes enfant n'auraient même rien à faire. Donc on pourrait instancier Transformable.
En bref, je propose d'implémenter la Surface présente dans SDL. Elle est déjà à moitié présente : setTextureRect() par exemple réduit la surface d'affichage, ou create() pour Image/Texture/Sprite, et ce utile qu'elle le soit partout : ça permettrait de réduire la taille d'affichage d'un Text, ou d'appliquer des méthodes d'alignement en fonction de son attribut bounds comme je l'ai vu proposé sur le forum anglais. Ca permet aussi de conditionner l'affichage de Drawable autres que Sprite en vérifiant si leur bounds intersects() avec le bounds de la View.

EDIT : Je viens de voir que les méthodes getLocal/GlobalBounds sont implémentées partout, désolé, je ne l'avais pas bien compris. Est-ce qu'il serait possible de la déclarer dans Transformable pour les collections hétérogènes.

Je vais voir ce qu'offre le type erasure, mais peut-être que cette suggestion est assez bonne pour être implémentée.

44
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 ?

45
Discussions générales / Re : Blog de développement - sfml
« le: Mai 01, 2012, 04:17:58 pm »
Ces tutos sont complets, bien illustés, aussi bien en codes qu'en couverture, proposent même d'aller au-delà et sont simples. En bref, c'est très intéressant. Mais pourquoi ne pas les mettre sur le wiki de la SFML ? M'autorises-tu au moins à ajouter un lien vers ton blog sur la partie "projets" et "ressources" du wiki ?

anything