Discussion :

[TheDrev]

Bonjour !

Je développe un moteur de jeu 2D en C++,
J'utilise fortement les classes abstraites pure pour faciliter l'abstraction entre le jeu et le moteur de jeu.
Cependant il n'est compatible qu'avec SDL, puisque je doit utiliser des structures propre à cette API (SDL_Surface, SDL_Rect).

Ce que je voudrai, c'est pouvoir le rendre vraiment indépendant de l'API graphique. (pour pouvoir l'utiliser avec par exemple GDI, ou d'autres plus intéressante comme GRRLIB pour développer sur Wii).

Je vois a peu près comment m'y prendre, mais cela demande tellement de travail que je préfère demander avant !

Je pense qu'il faudrait définir des structures opaque au dessus de chaque API (Par exemple, une structure Rectangle qui utilise en interne un RECT de l'API windows pour GDI ou un SDL_Rect pour SDL, idem
pour les surfaces, mon interface IGameEngine pourrai avoir une fonction getRender qui renvoi une structure Surface utilisant soit SDL_Surface, soit un Device Contexe HDC)

Cette technique à deux inconvénients :
- On ne peut réaliser ces structures abstraits qu'avec les possibilités communes aux API utilisés.
- Cela demande beaucoup de temps

Es-ce une bonne méthode ? y a t il plus simple ?

[Laurent Gomila]

Tu n'as pas besoin d'abstraire tout à ce point. Seuls les concepts importants doivent être abstraits : un renderer, des images, et des opérations pour les afficher (en gros). Il est important de n'abstraire que ce qui est vraiment nécessaire.

Pour les rectangles, couleurs et autres classes utilitaires, tu peux simplement redévelopper les tiennes sans utiliser aucune API. Ca ne sert à rien d'abstraire SDL_Rect, ce n'est qu'un structure de 4 entiers. Et les fonctions qui demandent un SDL_Rect seront celles de ton renderer SDL, donc déjà cachées par ton abstraction.

[Mat.M]

Je vois a peu près comment m'y prendre, mais cela demande tellement de travail que je préfère demander avant !

....
Cette technique à deux inconvénients :
- On ne peut réaliser ces structures abstraits qu'avec les possibilités communes aux API utilisés.
- Cela demande beaucoup de temps

Es-ce une bonne méthode ? y a t il plus simple ?

Je n'arrive pas à piger ta démarche ;déjà des "cross-libraries" pour jeux il y en a plusieurs ( Allegro,SDL..)
Et puis tu vas faire du code au-dessus d'une API qui se veut la plus indépendante possible en l'occurence SDL.

Déjà que SDL c'est lent tu vas faire une surcouche qui risque de ralentir et obscurcir encore plus les choses..
Si tu te lances dans ce genre de de projet tu vas avoir un code avec des tonnes de #ifdef #define...
Sans compter que c'est ardu de faire du code "cross-plateform" vu que d'un OS à un autre c'est différent; sous Linux c'est X Window, sous Windows c'est le GDI que tu cites ou bien Direct X...

Cependant il n'est compatible qu'avec SDL, puisque je doit utiliser des structures propre à cette API (SDL_Surface, SDL_Rect).

Mais qu'est ce que tu vas faire de plus que SDL ne fait ?
Des moteurs de jeu il y a en déjà même Laurent en a fait un , donc donne-lui un coup de main pour l'améliorer


Pourquoi ne fait-tu pas un véritable jeu au lieu d'un énieme moteur ?

[LeGreg]

SDL étant déjà une surcouche pour rendre le jeu indépendant de la plateforme, il y a une certaine redondance à rajouter une couche dessus.
Ceci dit on pourrait faire l'analogie avec OpenGL à ceci près qu'il y a des implémentations natives d'OpenGL.

Le multiplateforme est consommateur de temps, si c'est ton principal souci, il faut peut-etre mieux te replier sur une plateforme. Si ton principal souci est le multiplateforme alors il faut y passer du temps ou penser à embaucher d'autres personnes.

Il n'y a pas de règles vraiment pour le multiplateforme en général. C'est au cas par cas. Envelopper un objet "device" par un wrapper non typé en copiant toutes les méthodes et en leur donnant des noms perso, est une possibilité mais pas forcément la seule ou la meilleure. Par exemple certaines personnes préfèreront créer des objets plus haut niveau qui représenteront les concepts manipulés dans le jeu : entité, ui, système de particule, scene graph etc. Avec chacun de ces objets qui a une implémentation spécifique qui elle-même fait directement appel aux méthodes plus simples de la SDL, gdi etc. Tu peux aussi dissimuler des choses comme la boucle d'évènement windows, ou SDL etc, en mettant tout dans une fonction de boucle générique multiplateforme (onUpdate(), on frameRender(), onIdle() etc.), de même la gestion du passage des messages, la synchro entre threads etc. S'il y a du code commun dans les implémentations spécifiques rien ne t'empeche de partager le code dans des fonctions "helper". De même si on parle de SDL (c'est open source, non ?) il est peut-etre plus simple de porter la SDL sur la plateforme qui ne la supporte pas ou même chercher quelqu'un qui l'a déjà fait.

Dans tous les cas il est certainement important si tu fais du multiplateforme d'essayer de séparer les parties de code "commun" et des parties spécifiques (donc essayer de ne pas faire appel aux spécificités du GDI rect dans le code commun par exemple). Ce n'est pas toujours évident, surtout dès lors où l'on se préoccupe de performance en plus de la portabilité.

Les interfaces et classes abstraites ont aussi un coût à l'exécution (appel de fonctions virtuelles, multiples indirections, localité des données, aliasing, fragmentation mémoire), ce qui fait que si tu vises la performance (sur certaines consoles ce genre de problème devient critique contrairement au PC qui est assez flexible comparativement) fait qu'il est devient assez couteux par exemple de passer par une interface pour mettre à jour "un seul pixel" (ou tout autre donnée qui est manipulée par millions chaque seconde). Le choix de la granularité des appels virtuels dans ce cas peut être importante. Si tu es constamment en dessous de ton budget CPU, alors ce ne sera pas forcément un problème et il vaut peut-etre mieux privilégier la rapidité d'écriture du code..

LeGreg

[TheDrev]

J'ai déjà développé des fonctions qui cachent l'initialisation et les boucles de jeu. (Mon moteur de jeu attend une interface jeu, avec les fonctions type paint, cyle...)

Je crois que je vais plutot faire une version du moteur pour chaque API.

[HanLee]

Les interfaces et classes abstraites ont aussi un coût à l'exécution (appel de fonctions virtuelles, multiples indirections, localité des données, aliasing, fragmentation mémoire), ce qui fait que si tu vises la performance (sur certaines consoles ce genre de problème devient critique contrairement au PC qui est assez flexible comparativement) fait qu'il est devient assez couteux par exemple de passer par une interface pour mettre à jour "un seul pixel" (ou tout autre donnée qui est manipulée par millions chaque seconde). Le choix de la granularité des appels virtuels dans ce cas peut être importante. Si tu es constamment en dessous de ton budget CPU, alors ce ne sera pas forcément un problème et il vaut peut-etre mieux privilégier la rapidité d'écriture du code..

LeGreg

A la limite, l'abstraction n'est pas vraiment un problème avec les templates paramétré par un enum, sachant qu'a priori, on ne change pas dynamiquement la bibliothèque sous-jacente utilisée.

[drcd]

J
Mais qu'est ce que tu vas faire de plus que SDL ne fait ?
Des moteurs de jeu il y a en déjà même Laurent en a fait un , donc donne-lui un coup de main pour l'améliorer


Pourquoi ne fait-tu pas un véritable jeu au lieu d'un énieme moteur ?

Perso je trouve ca chiant de faire un jeu. lol

[Mat.M]

Perso je trouve ca chiant de faire un jeu. lol

Très singulière comme réponse je m'attendais à tout sauf à celle-ci.
Alors si c'est chiant de faire un jeu quel est l'intérêt de perdre son temps à faire un "moteur de jeu" ?

Moi je veux bien te croire mais quel intérêt d'écrire du code de concevoir quelque chose qui ne servira jamais à rien et restera quelque part sur ton disque dur ?
Tu aurais plus intérêt à faire un logiciel de compta au moins tu le vendrais et tu gagnerais de l'argent avec...