L'affichage

[L01man]

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 ?

[Hiura]

1/ non, ce n'est pas à Draw de le faire (d'ailleurs, pourrait-il le faire sans rendre son implémentation dégeulasse ?). Si la partie logique de ton jeu est bien conçue tu devrais pouvoir faire ce test très facilement.

2/ non plus. Laurent l'a expliqué quelques fois sur le forum : les CG de nos jours sont prévue pour un réaffichage complet. Et au pire le gain serait minime dans bien des situations et nulle dans encore plus de cas.

3/ tu parles de Z-buffer ? Alors ce message de Laurent devrait répondre à ta question : http://en.sfml-dev.org/forums/index.php?topic=6817.msg44921#msg44921

[Laurent]

Je complète/paraphrase un peu.

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 ?

Très simplement : les choses les plus rapides à afficher sont celles que tu n'affiches pas. Et plus tu les élimines tôt, plus tu gagnes en performances.
-> OpenGL le fait très tard
-> SFML ne peut pas le faire avec l'API actuelle (aucune abstraction pour récupérer le rectangle englobant dans sf::Drawable)
-> comme l'a dit Hiura, si ton appli a besoin de le faire, c'est qu'elle est déjà assez conséquente, et donc il y a fort à parier que tu as déjà une structuration de tes entités qui permette facilement d'éliminer les invisibles

Ne serait-il pas intéressant de faire du dirty rectangle drawing comme la SDL ?

C'est un concept d'un autre temps, et ce ne serait pas vraiment applicable à la façon dont les choses fonctionnent

[L01man]

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 ?

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.

[Laurent]

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 ?

OpenGL coupe tout ce qui dépasse, tout simplement. Mais de toute façon pour dessiner en dehors de la fenêtre, faudrait être très fort ; l'OS ne nous laisse pas faire n'importe quoi.

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.

Dans une application complexe, il faudra très certainement une structure de partitionnement (quad tree, kd-tree, grille, ...) pour gérer efficacement l'affichage et les collisions.
Essaye de raisonner plus globalement, et ne pas t'arrêter à ce que SFML fournit. SFML n'est qu'un outil, elle ne t'empêchera jamais de mettre en oeuvre le design adéquat pour ton programme.

[L01man]

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.

[Laurent]

Il y a toujours moyen

Je t'ai déjà parlé de type erasure, par exemple.

[L01man]

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 .

[Laurent]

Qu'est-ce qui est compliqué ?

[L01man]

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

[Laurent]

class BoundableBase
{
public:

    virtual void getGlobalBounds() const = 0;
};

template <typename T>
class Boundable : public BoundableBase
{
public:

    Boundable(T entity) : m_entity(entity) {}
    virtual void getGlobalBounds() const {return m_entity.getGlobalBounds();}

private:

    T m_entity;
};

Boundable* b = new Boundable<sf::Sprite>(sprite);

Si toutes les classes n'avaient pas exactement la même fonction, il suffirait de créer une dérivée pour chaque, plutôt qu'une seule template qui marche pour tout le monde.

Et un tuto :
http://alp.developpez.com/tutoriels/type-erasure/

[L01man]

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