Salut.

J'ai commencé à coder un moteur graphique en C++, à l'aide de SFML.
Je suis au courant qu'il existe déjà bon nombre de moteurs graphiques 2D, mais j'en apprendrai plus si j'en fais moi-même un.

Voici comment il s'utilise, grossièrement :
(Je ne poste pas sur un Wall l'utilisation car le code n'est pas trop long et su un Wall, au bout d'un moment, c'est effacé)

mGraphicEngine = new cGraphicEngine (800, 600, "Nom Fenetre");
mGraphicEngine->setBackgroundColor (10, 50, 100);
int stringHello = mGraphicEngine->addString ("Hello World !!!", "DS-DIGIB.TTF", 100);
int spriteBalle = mGraphicEngine->addSprite ("balle.png");
mGraphicEngine->moveSurface (spriteBalle, 1.f, 0.f);
mGraphicEngine->frame (); // Affiche les images et textes
delete mGraphicEngine;

Je n'ai pas affiché la boucle principale.
Mon but est donc de proposer un outil permettant de gérer l'affichage sans s'apercevoir qu'il est question de SFML.
De cette facon, si j'implémente ce moteur avec d'autres outils, par exemple libnds, je pourrai obtenir une application tournant sur DS sans modifier le code de l'application.
J'ai aussi commencer à coder en anglais, j'espere ne pas faire de faute de langue. Mais du coup, je suis plus rétissant à utiliser des commentaires.

Voici mes interrogations :
Je me demande s'il ne serais pas plus intéressant de coder une classe cImage par exemple, au lieu ici de conserver les références à mes images par des entiers ?
Sinon, pour l'instant, j'ai une classe cEventHandler qui est contenu dans ma classe cGraphicEngine. En effet, les évènements dépendent de la fenêtre.
Mais je pense séparer ces deux classes, je trouve pas ca super logique de lier le moteur graphique au gestionnaire d'évènements ; le moteur graphique ne sert pour moi qu'à gérer le fenetrâge, les images et textes, l'affichage.
Vous en pensez quoi ?

Voici le code de la classe cGraphicEngine :
http://www.codeswall.info/source-136.html
http://www.codeswall.info/source-137.html

Merci !

Je ne vois pas l'intérêt de ce que tu fais (au moins sur l'exemple que tu nous montre). En effet, écrire un moteur graphique sert à abstraire l'interface sous jacente.

Mais l'exemple que tu nous montre est juste une réécriture de SFML, sans abstraction supplémentaire. En quoi est-ce plus simple d'utiliser ton "int stringHello" (en passant, si tu fait du C++, ça serait pas mal d'utiliser des classes), plutôt qu'un objet sf::String ?

L'aspect "portabilité", tu peut réécrire ton interface pour d'autre bibliothèque n'est pas valable. Car c'est aussi possible pour SFML (qui tourne déjà sur plusieurs plateforme), et que tu peut étendre pour d'autre système si tu en avais besoin. Ça ne sera pas plus compliqué que de porter ta propre bibliothèque vers cette autre système, mais ça sera plus utile.

Je ne dis pas qu'il ne faut pas faire ce que tu fait. Mais pas à ce niveau là. J'avais par exemple écrit une bibliothèque graphique à une époque. Mais l'interface était du niveau de SFML (qui n'existait pas à l'époque), et reposait sur GDI ou X. Il y avait donc un niveau d'abstraction supplémentaire introduit par cette bibliothèque. C'est là que réside l'intérêt d'un tel projet.

Hum, j'ai oublier de préciser quelques détails.
Mais tu n'as pas tord, tell qu'il se présente ici, il n'a pas grand interêt.

Je ne compte pas faire ce pseudo-moteur juste pour en faire un, mais pour faire un jeu au final. Et abstraire la SFML du code du jeu permet de rendre le jeu portable sur la DS par exemple, a moins de coder une autre version du moteur graphique.

La SFML n'est pas portable sur DS !?

Je m'inspire de ce tuto :
http ://khayyam.developpez.com
/articles/cpp/jeux/architecture/?page=sommaire
Il est surement plus utile de créer un moteur graphique 3D plutot qu'un moteur graphique 2D.

Je suis plus venu chercher des conseils quand à gérer mon code.
Et en effet, je n'ai pas encore le reflexe d'utiliser suffisemment de classes.

de ce que j'ai vu de SFML, ca ne vas pas etre bien difficile d'ecrire un port DS si il n'existe pas.

Ce que je voulais dire c'est que comme tu te trouve au même niveau d'abstraction que la SFML, il n'est pas plus difficile de porter la SFML sur DS que ta bibliothèque. Donc, il vaut mieux que tu utilise ton énergie pour quelque chose "d'utile" à plus de gens. Mais en fait, tu fait ce que tu veux de toutes manières, et si tu préfère réécrire ce genre de bibliothèque, mon conseil serait de te baser sur quelque chose de plus bas niveau que la SFML. Comme ça, c'est plus intéressant, tu aura plus de liberté pour ce que tu fais et ce sera plus facile à porter sur une autre plateforme.

Merci pour vos conseils.

Hum, faut que j'y réfléchisse.
Pour écrire un port DS pour SFML, je dois recréer toutes les classes et fonctions de manières identiques à utiliser, mais en utilisant des outils tels libnds ou autre pour DS dans ceux ci ?

Ca reste plus difficile je pense de porter la SFML sur DS plutot qu'une propre bibliotèque perso, mais en effet c'est surement plus utile.

Mais il risque d'y avoir des problèmes, lors de mises a jours de la SFML par exemple, il y aura des problèmes d'incompatibilités.

Et je ne sais pas encore utiliser libnds, j'avais juste ecrit un pong avec PAlib sur Windows. La il faut déjà que j'installe libnds/devkit* sur Ubuntu.

Je vais y réfléchir.

Si la SFML est bien écrites (et c'est à peu près le cas), il n'y a pas grand chose à réécrire. Seulement les fonctions qui traitent vraiment d'affichage doivent être touché (et non pas toutes les classes, qui vont rester en grandes partie identique).

C'est vraiment le même travail que de porter ta future bibliothèque.

De plus, si tu fait quelque chose de complet et propre , tu pourra probablement l'incorporer dans le code officiel de SFML et ça sera pris en compte pour les versions ultérieures.