Responsabilité de l'affichage.

[valefor]

Bonjour.

Je n'ai pas réussi à aboutir à un résultat de recherche sur le forum, faute d'avoir les bon termes et mots clés.

Je bricole un petit jeux en C. Et je cherche des articles, discussions, points de vue, exemples d'implémentation sur la façon de rendre (afficher) les objets d'une scène.

Par exemple j'utilise opengl pour l'affichage, et je ne veux pas mettre du code opengl dans mes objets. Donc actuellement mon jeux peut tourner sans affichage.

Pour l'affichage je passe ensuite à une "classe" "renderer" un pointeur qui lui permet de parcourir la liste de mes objets. Donc cette classe "renderer" connaît les attributs des objets constituants la scène et peut les afficher.

Je n'aime pas trop cela, et j'aimerai le faire évoluer. J'ai lu par ci par là (http://gamedev.stackexchange.com/que...ing-themselves et http://gamedev.stackexchange.com/que...-render-itself) qu'on pouvait passer au "renderer" une liste décrivant les objets.

Bref, je me demandais si ce genre de discussion n'avait pas déjà eu lieu sur ce forum ? Et j'aurai aimé vos avis.

Cordialement.

Paul.

[Djakisback]

Bonjour,
peux-tu être plus clair sur ce que tu n'aimes pas trop dans :

Donc cette classe "renderer" connaît les attributs des objets constituants la scène et peut les afficher.

A priori, si on cherche la performance, je pense que cela peut-être pas mal de gérer quand même le tracé des objets directement à l'intérieur de ceux-ci. Cela implique de recréer un bon nombre de classes lors d'une évolution du code ou lorsque l'on veut différentes implémentations d'un même moteur mais en contrepartie je pense que ça résout les problèmes de fortes abstractions lors de l'implémentation d'API multiples.

Si on cherche plus l'évolution et surtout la facilité d'implémentations multiples, il me semble que de centraliser les fonctionnalités de tracé et autres dans un "Renderer" est plus efficace.

Dans les 2 cas, je pense qu'il te faut un "Renderer" mais également des classes pour définir différents objets graphique et je me demandais si c'est ce que tu as fais car je ne comprends la phrase que tu as postée et que j'ai citée

Personnellement, j'utilise la deuxième solution dans un moteur Java que j'ai développé dont voici le modèle simplifié :

Une classe "Moteur" avec des méthodes abstraites draw(Shape2d), draw(AnimatedShape2d), etc.

Des classes étendant le "Moteur", par exemple "MoteurJOGL", "MoteurJava2D", etc. implémentant les méthodes draw(Shape2d), etc. en utilisant les fonctions propres à l'API utilisée.

Des classes d'objets graphiques Shape2d, AnimatedShape2d, etc. qui elles, appellent les méthodes draw() du moteur, ex :

Code :

1
2
3
4
5
6
7
class Shape2d {
...
 
public void draw() {
...
this.engine.draw(this);
}

Code :

1
2
3
4
5
6
7
class AnimatedShape2d extends Shape2d {
...
 
public void draw() {
...
this.engine.draw(this);
}

Ca permet de tout centraliser dans une seule liste de Shape2d (classe graphique root) dans la classe root "Moteur" et d'effectuer le tracé, les updates, etc. des objets graphiques dans la classe "Moteur" et non pas dans les implémentations, en profitant du polymorphisme et sans se soucier du type réel, ex. dans "Moteur" :

Code :

1
2
3
4
5
6
7
8
9
10
public void draw(float elapsedTime) {
...
for(int i = 0; i < this.shapes.size(); i++) {
...
this.shapes.get(i).update(elapsedTime);
this.shapes.get(i).draw();
...
}
...
}

Ensuite dans le cadre d'un jeu, en général, j'étends les classes graphiques qui m'intéressent pour ajouter tout ce qui est propre au jeu, ex :

Code :

1
2
3
4
5
6
class Shot extends AnimatedShape2d {
 
int damage;
boolean busy;
...
}

Dans ce cas le jeu ne peut pas fonctionner sans moteur graphique mais rien n'empêche d'utiliser plutôt la notion de conteneur, ce qui simplifie aussi l'intégration de moteurs physique, audio, etc. par exemple :

Code :

1
2
3
4
5
6
class Shot {
 
int damage;
boolean busy;
...
}

Code :

1
2
3
4
class ShotSprite extends Shot {
Shape2d sprite;
PhysicSolid solid;
}

Pas sûr d'être très clair :/
C'est une méthode parmi d'autres, en tout cas celle-ci a fonctionner assez bien, pour moi, pour faciliter les implémentations multiples du moteur graphique et centraliser au maximum certaines partie du code.

Il y a par ailleurs un tuto sur DVP sur la création d'un moteur 3D par Loulou http://loulou.developpez.com/tutoriels/moteur3d/ mais je ne crois pas qu'il traite des objets graphiques, je ne l'ai que "traversé" quelques fois.

Mon but quand j'ai commencé le moteur était de partir pratiquement de 0 et de voir comment je pouvais répondre aux besoins et résoudre les différents problèmes que je rencontrais. (Si quelqu'un a des avis sur ma conception, je suis preneur )

[Mat.M]

Envoyé par valefor

Par exemple j'utilise opengl pour l'affichage, et je ne veux pas mettre du code opengl dans mes objets. Donc actuellement mon jeux peut tourner sans affichage.

est-ce que c'est un jeu 2d ou 3d ?
Tu ne le précises pas dans le fil de discussion...
pour un jeu 2d c'est possible de faire du code totalement abstrait il suffit de passer la zone rectangulaire à une fonction qui elle comprend du code Open GL et la dessiner.
Par contre en 3d ça me semble difficile,il faut appeler toutes les commandes Open GL pour dessiner des polygones


Attention aussi avec la 3d c'est qu'il faut ce poser la question : quelle stratégie,quel algorithme adopter pour afficher tous les objets de la liste ?
La problématique majeure lorsqu'on gère l'affichage d'une scène avec des objets 3d c'est d'optimiser le rendu parce sinon tu vas sacrément perdre en fluidité..
supposons que ta liste contienne des instances d'objet de plus de 1000 polygones chacun , si tu as 1000 objets 3D comme cela ça fait énormément de polygones à afficher sans compter les transformations pour les éclairages et le placage des textures.

[valefor]

Envoyé par Djakisback

peux-tu être plus clair sur ce que tu n'aimes pas trop dans :
[...]
Dans les 2 cas, je pense qu'il te faut un "Renderer" mais également des classes pour définir différents objets graphique et je me demandais si c'est ce que tu as fais car je ne comprends la phrase que tu as postée et que j'ai citée

Bonjour.

Merci pour ta réponse.

J'ai effectivement un renderer. J'ai aussi un "monde" dans lequel j'ai des "objets". Voici comment se présente le (pseudo) code du renderer :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
 
#include <monde.h>
#include <objet.h>
 
void render(monde)
{
  pour chaque monde->objet faire
    se placer en objet-> objet->y 
    suivant objet->type faire
      affiche cercle / carré / etc
    fin suivant
  fin pour
}

Ce que je n'aime pas là dedans c'est les include monde et objet et l’accès aux "membres" de monde et objet.

Du coup, comme tu sembles le faire aussi, il en ressort que beaucoup de gens utilisent une représentation intermédiaire des objets à rendre (tes shapes 2D par exemple).

La question est donc maintenant, où doit-on gérer la transformation des objets de la scene en objets "graphique" ?

J'ai l'impression qu'il faudra bien un "contrôleur" qui a connaissance des objets physiques ET de leur représentation graphique. Si ce contrôleur n'a rien d'autre à faire j'aime autant laisser mon code en l'état... et ne pas le compliquer en multipliant les classes/délégations.

Voila.

P.S : je code en C.

[valefor]

Envoyé par Mat.M

pour un jeu 2d c'est possible de faire du code totalement abstrait il suffit de passer la zone rectangulaire à une fonction qui elle comprend du code Open GL et la dessiner.
Par contre en 3d ça me semble difficile,il faut appeler toutes les commandes Open GL pour dessiner des polygones

Je ne vois pas du tout ce que tu entends par "il suffit de passer la zone rectangulaire" ... Il me semble que c'est plus la philo SDL ça... OpenGL n'a pas la notion de "morceau" d'écran !?

Pour la 3D ça n'a rien de compliqué d'appeler les commandes OpenGL dans des sous fonctions...

Enfin, je dirai que OpenGL vaut n'importe quel bibliothèque 2D. Je dirai même que je préfère encore OpenGL à SDL pour l'affichage... Et si j'utilise SDL c'est uniquement pour les inputs et le fenêtrage...

[Mat.M]

Envoyé par valefor

Je ne vois pas du tout ce que tu entends par "il suffit de passer la zone rectangulaire" ... Il me semble que c'est plus la philo SDL ça... OpenGL n'a pas la notion de "morceau" d'écran !?
...

tu ne réponds pas à ma question : tu fais un jeu 2d ou 3d ?
Sinon oui justement il faut se fier à l'architecture de SDL si tu fais un jeu 2d !
Parce que si du jour au lendemain tu passes à Direct X eh bien tu vas devoir réecrire pas mal de code.
D'ailleur le concepteur de la SFML utilise le concept de Sprite ou Displayable Zone
C'est exact Openg GL ne gère pas de morceau d'écran; mais comme dans un jeu 2d on gère essentiellemnent des bitmaps il faut créer une structure de sprite qui englobe une bitmap

[valefor]

Sinon oui justement il faut se fier à l'architecture de SDL si tu fais un jeu 2d !

Je fais un jeu 2D.

Mais je ne suis pas d'accord avec toi. Je ne vois aucune différence entre SDL et OpenGL.
Il suffit de voir un sprite comme un objet 3D.
Il suffit de voir la surface de ton écran 2D comme un monde 3D vu de dessus en projection orthogonale.
Il suffit de créer des objets (et ses coordonnées de textures, shaders etc) en plus de charger leurs images.

Bref, je n'ai aucun mal à passer mon renderer de SDL à OpenGL et vice versa.

Je ne connais pas DirectX par contre.

[Djakisback]

Je suis tout à fait d'accord, il me semble que ta question de base est conceptuelle et la réponse indépendante de l'API finale. (n'a rien à voir également avec le calcul de l'éclairage, des ombres, partitionnement, etc.)

Ok, pour ta phrase du début, je comprends mieux ce que tu voulais dire et effectivement, selon les principes de la POO, le pseudo-code posté ne semble pas terrible.

La question est donc maintenant, où doit-on gérer la transformation des objets de la scene en objets "graphique" ?

J'ai l'impression qu'il faudra bien un "contrôleur" qui a connaissance des objets physiques ET de leur représentation graphique. Si ce contrôleur n'a rien d'autre à faire j'aime autant laisser mon code en l'état... et ne pas le compliquer en multipliant les classes/délégations.

Non justement, si tu fais étendre tes objets de jeu (Perso, Ennemy, etc.) de l'un des objets graphiques ou que tu utilises la notion de conteneur (ou d'héritage multiple), comme dans mes exemples (dans ton cas ce serait plutôt la notion de conteneur). Il n'y a pas de transformation des objets du jeu en objets graphique à proprement dite.

Le fait d'ajouter des classes d'objets graphiques permet également la réutilisabilité du code de ton moteur graphique. Mais si tu n'as ni besoin de la réutilisabilté, ni du portage, ni d'évolution alors j'aurais tendance à dire que le plus simple est de laisser en l'état. Tu pourrais aussi utiliser des interfaces mais je pense que ça alourdirait le code pour rien.

(Après je ne suis pas forcément très objectif comme j'utilise ce modèle depuis des années mais comme tu demandais des points de vue ce serait bien d'ailleurs d'en avoir d'autres )

Edit :
Oops, j'ai oublié que tu étais en C, après avoir lu les 2 liens que tu citais et qui parlait de C++, JS et Java je pensais que tu cherchais à faire de la POO, désolé.

[valefor]

Envoyé par Djakisback

Il n'y a pas de transformation des objets du jeu en objets graphique à proprement dite.

Ce que j’entends par transformation, c'est, à partir d'une liste d'objets "physiques", obtenir une liste de descripteurs "graphiques" à passer au renderer.

Avec le C++ tu hérites de "Shot" (dans ton exemple) ou de "AnimatedShape2D". La magie du c++ fait le reste.

Ta solution d'un objet composé des deux parties (physique et graphique) me semble déjà plus viable pour le C. Mais j'ai l'impression qu'il va y avoir duplication (coordonnées, taille par exple).

Effectivement, nos points de vue manquent de confrontation.

Souvent le silence me fait dire que c'est un sujet maintes fois abordés et que les gens en ont marre de répondre

[LittleWhite]

Bonjour,

Depuis le début je lis attentivement la discussion.

Je dois dire qu'il n'existe pas une seule et unique solution. Chacun à un peu sa façon de faire.
De plus, le faire en C, me semble un poids (à cause de son manquement de constructeur / destructeur, et autre particularité des langages orientée objets). Toutefois, ce n'est pas parce que vous êtes en C que cela doit être crade, il est tout à fait possible de faire propre et de faire comme si nous avions des objets (l'aide sera d'utiliser une bibliothèque telle que GLib, par exemple).

Maintenant, personnellement, j'ai bien avoir une classe Renderer qui s'occupe simplement de faire le rendu (car, je pense que l'on doit respecter la responsabilité unique. J'utilise aussi une classe Sprite, qui, bien entendu garde les données de l'image.
Si vous voulez savoir comment je fais, récemment, vous pouvez jeter un coup d'oeil sur le NEngine ( http://www.developpez.net/forums/d96...nce-wars-like/ )
On peut aussi imaginer un système entièrement basé un système de message (chaque élément voulant être affiché envoie un message qui sera lu par le Renderer).

[Kannagi]

On est pas obligé de faire de la Poo , la paradigme procédurale/fonctionnel est très efficace si bien utilisé, une fonction affichage peut suffire largement .

Enfin pour le 2d c'est largement suffisant , il suffit juste de faire un ordre affichage généralement c'est background,Decor,perso et Hud.
Bah ça suit la logique de la SDL avec son blit.

[screetch]

hmmmmm pourquoi toujours l'héritage :-/

utilisez l'aggrégation (bordel)

une entité "n'est" pas renderable, elle "a" un renderable.

ensuite tu pourrais donner au monde la résponsabilité de lister toutes les "shapes" a tracer (et leurs positions)
et le monde demanderait au renderer de les dessiner.


en gros:

Code :

1
2
3
4
5
6
7
8
9
10
class Entity
{
  IRenderable* renderable;
  ...
};
 
class Enemy: public Entity
{
  Enemy() : Entity(new AnimatedShape());
};

chaque entité "a" un IRenderable.
IRenderable te retourne par exemple a chaque frame un Sprite; et tu sais dessiner les Sprite.
le monde ferait donc:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
std::vector<Sprite> World::getDrawables()
{
  std::vector<Sprite> result;
  for( entity in all_entities)
  {
    if (isVisible(entity))
    {
        result.push_back(entity->renderable->getFrameSprite());
    }
  }
  return result;
}

et le renderer n'a plus qu'a afficher tous ces sprites. Le renderer ne connait donc rien du Monde, il ne sait que afficher une bête liste de sprites!
(il faut sans doute associer la position aux sprites, c'est que du pseudo code hein)

[Djakisback]

Envoyé par valefor

Ta solution d'un objet composé des deux parties (physique et graphique) me semble déjà plus viable pour le C. Mais j'ai l'impression qu'il va y avoir duplication (coordonnées, taille par exple).

Je pense que ça dépend ici aussi de l'optique et des outils utilisés, dans le cas d'une composition, si tes entités graphiques et physiques utilisent par exemple le même type de données pour définir leurs positions (matrices, vecteur, ...) et que tu définis la position de l'entité graphique en tant que pointeur sur la position de l'entité physique, la position de l'entité graphique sera automatiquement mise à jour à chaque pas de simulation du moteur physique. Si les types de données ne sont pas les mêmes pour les 2 API, les données seront effectivement stockées en double et il faudra faire une mise à jour de l'entité graphique. J'ai déjà utilisé les 2 solutions et cela fonctionne très bien, en tous cas dans le cadre d'un moteur 2D complexe et d'un moteur 3D simple.


@screetch : je pense que les 2 solutions peuvent être viables, et d'ailleurs pour moi une entité Ennemi ou autre "est" renderable. Sinon j'aurais parlé de composition plutôt que d’agrégation, mais de toute façon la demande est en C .

[screetch]

un ennemi "a" un sprite/une représentation graphique, un ennemi n'"est" pas une représentation graphique.
sinon tu introduit un couplage trés fort.

comme souvent, en plus, un ennemi "est" d'autres choses, on se retrouve avec des classes a responsabilités multiples, et en plus avec des couplages entre classes que l'on ne souhaitait pas avoir: si une entité est renderable, on a un couplage entre toutes les entités et le renderer; et un couplage entre le renderer et les entités.

Désolé d'être si catégorique, c'est juste que l'héritage c'est la solution de facilité, le côté obscur de la force, et que l'on se doit de penser a autre chose parfois. Sinon, des problèmes tu auras, lorsque le code tu refactoriseras.

[Kannagi]

Pour les position j'en ai qu'un seul pour la physique et l'affichage , mais je possèdes des variable vecteur(x et y) qui modifie les positions (et je fais les calcul de physique sur ces vecteurs).
Je me pose la question si c'est vraiment utile ce render par liste pour un jeu 2D ?
Sur le nombre de mes projets , l'affichage 2D ne tient pas sur beaucoup de ligne , le plus gros reste souvent algo derrière.
A la limite pour l'ordre affichage s'il doit changer constamment , mais c'est plutôt rare , si les fonctions sont bien faite , on aura pour affichage qu'une boucle for.

[Mat.M]

Envoyé par valefor

Je fais un jeu 2D.

Mais je ne suis pas d'accord avec toi. Je ne vois aucune différence entre SDL et OpenGL.
Il suffit de voir un sprite comme un objet 3D.

Pour la 3d, un sprite c'est 2 triangles liés par un côté
Mais apparemment tu n'as pas compris ce que j'ai écris

Envoyé par LittleWhite

Bonjour,

Depuis le début je lis attentivement la discussion.

Je dois dire qu'il n'existe pas une seule et unique solution. Chacun à un peu sa façon de faire.

je suis tout à fait d'accord

[valefor]

ensuite tu pourrais donner au monde la résponsabilité de lister toutes les "shapes" a tracer (et leurs positions)

Envoyé par Kannagi

Je me pose la question si c'est vraiment utile ce render par liste pour un jeu 2D ?

Moi, j'aime bien cette idée.

Après, effectivement l'utilité se discute... cela commence à devenir inutile au moment où on s'embête plus à coder qu'à en tirer des avantages...

Mais je cherchais des "pattern" desquels m'inspirer.

Merci pour vos réponses en tout cas.