Voila je postes ici, car je travaille depuis maintenant 2 mois sur un pseudo moteur de jeu (mon premier grand projet), destinée dans un futur lointain à la réalisation d'un jeu de rôle dans un univers médiéval/réaliste.
Jusqu'à présent je n'ai pas eu trop de problème avec la mise en place de l'architecture (je me suis inspiré de tutos présent sur developpez.com), et mis à part quelques corrections à appliquer pour rendre le tout propre, je suis assez content de mon travail.
Pour le moment, je me concentre essentiellement sur le moteur (module est peut être plus adapté comme terme) graphique, qui est sujet principal de mon projet.
Je suis donc parvenu à partir de la SDL à me monter un module graphique assez simple d'utilisation (peut être certaines routines de syntaxe qui me paraissent un peu tordue cependant), et mis à part de nombreuses fonctionnalités que je n'ai pas encore intégré (notamment au niveau des déformations: rotation, redimensionnement; que j'aimerais reprogrammer entièrement, sans avoir recours à SDL_Gfx) le tout semble bien fonctionner.
J'y ai inclu jusqu'à présent la création, suppression de sprites, de manière dynamique et sans fuites de mémoire (plusieurs sprites utilisant les mêmes surface se les partagent, ce qui ne surcharge pas la mémoire inutilement), ainsi que l'animation (outre le fait que je n'ai pas encore mis en place une gestion des intervalles entre chaque image), ou encore un système de tri de sprites (je penses à la gestion de la "profondeur", sans avoir nécessairement besoin de préciser ce qui doit être affiché devant ou derrière tel ou tel objet de la scène).
Actuellement, je "martyrise" mon module , et essaye de le faire tourner à plein régime, de manière abusive, afin de tester les performances max.
Je postes en réalité ici, pour avoir des informations et avis sur les performances que j'ai actuellement avec mon moteur, et ce qui serait techniquement possible d'atteindre, ou ce que je devrais être capable d'obtenir de plus.
J'ai notamment essayé de charger 2500 sprites (classe perso qui prend en charge les animations, etc) à chaque boucle, pour constater que je descend à 1 image par seconde, voir moins.
Du haut... bas de mon AMD Athlon 1700+ 1.4Ghz (avoir un vieu pc a l'avantage de nous obliger à optimiser un maximum), je ne m'étonne pas trop des performances, mais je me demandais si devoir afficher 2500 sprites de manière fluide peut être considéré comme necessaire pour un module graphique.
Je pense par exemple à un jeu utilisant un dallage pour les niveaux : est-il plus intelligent de concatener toutes les dalles en un seul morceau (semble aller plus vite j'ai l'impression), ou garder la méthode de milliers de petites dalles (pour un niveau de 32*32, on arrive très vite à quelque chose d'énorme)?
Pour comparer, je peux actuellement afficher environ 250 sprites simultanément, et de manière relativement fluide (je rapelles que mon processeur reste un 1.4Ghz ...)
Voila, donc, si vous avez quoique ce soit comme conseil en ce qui concerne le "tweakage" de SDL, ou comment gagner en performances (c'est ce que j'essaye de faire, vu que la mémoire, qui était mon principal objectif, a été prise en charge).
J'ai le regret de t'annoncer que la SDL est bien incapable d'être synonyme de performances... Je te conseille d'utiliser OpenGL qui tire partie du hardware, contrairement à la SDL, ou si tu veux faire bien performant en C++ SFML.
Merci pour vos réponses rapide
J'ai en effet entendu parler de SFML, mais je me suis dit qu'il était inutile de passer à autre chose, alors qu'on pouvait se contenter de SDL simple (sans intervention de OpenGL).
Disons qu'il est possible de trouver pleins de projets fait avec SDL, genre les versions libre de civ, TTD, etc et tout semble fonctionner à merveille (cependant, vous pourrez confirmer cela, ils utilisent probablement OpenGL en même temps?)
Et puis le concept de faire de la 2D, à la base d'une API 3D me parait assez étrange, même si je conçois parfaitement le fonctionnement et les atouts.
En tout cas, à en voir les comparatifs, c'est sur que c'est assez hallucinant, et je devrait peut être envisager la reconversion de mon module (vu l'utilisation que je lui prévois) dés maintenant, plutôt que de "perdre" du temps en me rendant compte plus tard que je suis limité.
Je vais donc tester tout ça rapidement, en tout cas merci encore
N'hésitez par cependant si vous avez des conseils pour SDL, je n'ai pas encore changé d'avis
J'ai installé SFML il y a environ 2h (instantanément), et j'ai déjà procédé à la quasi totalité de la reconversion de mon module, et je dois dire que je ne vais pas revenir en arrière.
Je n'ai rien changé dans "l'algorythme" de mon module, et j'ai déjà affaire à une bête de course lol .
Du côté de la syntaxe de SFML, c'est du "pour les nuls" dans le sens où c'est très explicite, autant dans le fonctionnement que dans le code que l'on doit taper pour arriver à ses fins .
Je n'imagine même pas les perspectives que vont offir la rotation, cisaillement, etc, avec une telle prise en charge !!
Salut, je ne suis qu'un débutant en c++, mais j'ai une experience de 5ans avec game maker(le langage GML), je peux te proposer un truc qui fera travailler ton processeur a 20% et tu peux avoir plus de 7000 sprites sur la même scène, tu dois essayer de trouver un moin de rendre les sprites qui sont à l'exterieur de la vue inactifs, et tu peux par exemple sauvegarder les états de tes sprites sur un fichier temporaires que d'où tu chargeras tes sprites au furs et à mesure que tu en auras besoin, et ainsi supprimer tous ceux qui n'auront rien a faire.
c'est une technique très puissante dans le domaine de la 2D, si tu arrive à la réaliser en c++, fais-moi signe.
j'éspère que j'ai résolu ton problème de performences.
La maîtrise des fondamentaux est le fondamental de la Maîtrise.
Merci pour le conseil, en effet c'est quelque chose que j'avais déjà envisagé, mais ici les tests restaient bruts, dans le sens ou je cherchais simplement à connaître la limite directe (sans ajout d'optimisation externe, ou je ne sais quoi).
En tout cas, j'y penserais quand j'en arrive là .
Sinon après moultes essais, autant avec SFML que SDL, je constate bien la différence de perfos jusqu'à une certaine limite (ma config étant assez faible), et je dois dire que SFML me plait bien; cependant certains particularités de la SDL me manquent dans cette bibliothèque qui se veut simple (on peux pas tout avoir ^^).
Je penses nottament aux concept du blittage, d'une surface sur une autre et autres fonctions plus bas niveau présentes dans SDL et qui permettent de faire tout et n'importe quoi.
Etant donné l'avancement actuel, je penses que je vais conserver ce que j'ai, c'est à dire mon moteur avec SFML, et celui avec SDL, avec possibilité de choisir l'un des deux (les deux fonctionnant sans problème et étant interchangeable sans changement dans le jeu).
Je vais cependant plus me concentrer sur l'utilisation de SDL pour le challenge , et essayer d'y intégrer OpenGL auquel je n'ai pas encore touché, juste question de voir si je peux réussir à battre SFML (j'en doutes ).
En effet, comme je l'ai précisé dans mon premier message, mon projet est plus axé sur la conception d'un "moteur de jeu" que le jeu lui même, alors confectionner un semblant moteur à "partir de rien" fait parti du jeu (cela dit SFML reste une alternative très interressante)...
C'est un sacré projet dans lequel tu t'es lancé, bonne chance alors !
C'est juste pour savoir si c'est possible de récupérer ton code, pour voir comment tu procède (je connais le c et le c++, mais je manque de pratique et d'exemples).
Pas de problème , je peux mettre à disposition mon code, cependant, je suis aussi encore un novice du c++ , alors il ne faut pas s'attendre à quelque chose de très propre ou d'extrêmement clair pour le moment (cela doit faire 2-3 mois maintenant, sans compter la documentation, que je "travaille" sur mon projet).
Si tu me laisses le temps de commenter clairement chaque ligne de code (au début on le fait, et à force ... ), je l'uploaderait sur un ftp (plus pratique que de copier-coller tout mon code sur ce topic ).
Comme je l'ai dis dans mon premier message, je me suis tout d'abord inspiré d'un tutorial sur developpez , sur l'architecture d'un moteur de jeu:
En effet, bien que j'avais déjà une petite idée au départ sur l'architecture que je devais mettre en place, je n'avait aucune idée concrête sur "qu'est-ce qui doit être fait dans tel ou tel module?", "comment les lier entres eux, de façon à ce qu'ils restent entièrement autonome?" (j'avoue à avoir encore quelques problème avec ça, notamment au niveau des includes qui me paraissent assez maladroits ).
En tout cas, je te conseille de jeter un oeil sur cet article (il en existe d'ailleurs beaucoups d'autres sur le net et de tout genre: pour des moteurs spécifiques; cependant souvent en anglais, si ça peut poser problème à certains ), je suis sur que ça te seras d'une grande aide (je sais que ça l'a été pour moi).
Je penses que la difficulté où l'ampleur d'un tel sujet (aussi ce qui le rend interressant en soit) c'est de parvenir concevoir quelque chose qui doit être le plus exploitable et explicite possible: on pourrait citer la syntaxe, ou même tout simplement les noms des méthodes/fonctions/variables.
Disons qu'une fois que le moteur est codé, lors de la programmation du jeu, on ne devrait pas avoir à réfléchir plus que ça, ou consulter 2000 pages de doc pour retrouver une simple commande de routine.
J'ai constaté qu'une chose interressante à faire est de se monter un sorte de wiki (je trouve le système très rapide, et c'est souvent plus agréable à consulter que les 50 feuilles gribouillées au stylo et au stabylo), au fur et à mesure que tu avances sur le projet.
C'est ce que j'experimente actuellement, je me suis créé un serveur local où j'héberges mon propre mediawiki, et ça me permet de rédiger des articles divers, illustrer avec des schémas/graphiques, etc...
Même si ça peux paraître débile de rédiger de manière formelle une sorte de doc, uniquement pour une seule personne, cela permet tout de même d'anticiper grandement la suite, et/ou d'eviter des erreurs bêtes, pour lesquelles on aurait passé des heures à corriger parmis 5 lignes de code ...
---
Pour ce qui est de la fonction de blittage, j'ai en effet lu que c'était possible d'une manière ou d'une autre (via un écran provisoire, que l'on capture et reconverti en image il me semble? ), mais j'avoue n'avoir pas encore trop pris la peine de me renseigner à ce sujet .
Pour le blittage je ferrais comme ça :
-> Récupération de deux sf::Image (en paramètre de la fonction) : src et dst (source et destination);
-> Récupération de leurs contenus (via GetPixelsPtr) : srcPixels et dstPixels.
-> Acquisition de la hauteur maximale entre src et dst, idem pour la hauteur.
-> Création d'un tableau de pixels (pour la nouvelle surface) : newImagePixels.
-> Copie de dstPixels dans newImagePixels.
-> Copie (avec écrasement) de srcPixels dans newImagePixels.
-> Chargement de la nouvelle texture (newImagePixels) (via LoadFromMemory) dans dst.
Mais je n'en ai pas encore eu besoin, donc je ne l'ai pas fait.
Salut, je ne suis qu'un débutant en c++, mais j'ai une experience de 5ans avec game maker(le langage GML), je peux te proposer un truc qui fera travailler ton processeur a 20% et tu peux avoir plus de 7000 sprites sur la même scène, tu dois essayer de trouver un moin de rendre les sprites qui sont à l'exterieur de la vue inactifs, et tu peux par exemple sauvegarder les états de tes sprites sur un fichier temporaires que d'où tu chargeras tes sprites au furs et à mesure que tu en auras besoin, et ainsi supprimer tous ceux qui n'auront rien a faire.
c'est une technique très puissante dans le domaine de la 2D, si tu arrive à la réaliser en c++, fais-moi signe.
j'éspère que j'ai résolu ton problème de performences.
la fait de ne pas dessiner une image qui se trouve completement en dehors de l'ecran (vue en SFML) pour gagner du temps de calcul s'appelle le clipping et est assez simple à mettre en place
C'est gentil à toi Althar93. Je peut attendre c'est pas un problème.
Pour l'histoire de la doc personnalisé, je n'avais jamais pensé à utiliser un système basé sur wiki... Tu fait comment pour créer un système wiki (pour le FTP, je me débrouille).
Bon, je vais allez lire l'article sur l'achitecture d'un jeu 3D.
je realise depuis quelques temps des fonctions pour faire rapidement des menus en SDL, il y a peut je me suis attaqué au cadre de defilement, pour faire le lien directement avec ta question, chaque element à afficher était au final une surface, et j'ai eu une mauvaise surprise en entrant dans des rep contenant bcp de fichier, ca s'affichait dans un temps correct(pour un explorateur de fichier) mais lorsqu'il s'agit de faire defiler pfiou, mon proc éprouvé à 100%, toute les surface à créer ayant la meme hauteur, j'ai resolu ca en affichante seulement les surface ne sortant pas du cadre, pour les autres j'ai seulement leur position.
Ca me fait penser à ce que te dit fissal_houate, c'est pas le meme contexte mais le pb est le meme
Citation : Althar93
Je pense par exemple à un jeu utilisant un dallage pour les niveaux : est-il plus intelligent de concatener toutes les dalles en un seul morceau (semble aller plus vite j'ai l'impression), ou garder la méthode de milliers de petites dalles (pour un niveau de 32*32, on arrive très vite à quelque chose d'énorme)?
exactement le probleme que j'ai eu, trop de surface à blitter, la solution est là je crois et peut importe que tu change d'API le probleme restera, meme si il pourrait etre moins visible..
Je pense par exemple à un jeu utilisant un dallage pour les niveaux : est-il plus intelligent de concatener toutes les dalles en un seul morceau (semble aller plus vite j'ai l'impression), ou garder la méthode de milliers de petites dalles (pour un niveau de 32*32, on arrive très vite à quelque chose d'énorme)?
exactement le probleme que j'ai eu, trop de surface à blitter, la solution est là je crois et peut importe que tu change d'API le probleme restera, meme si il pourrait etre moins visible..
comme il a déjà été dit, la méthode du clipping serais préférable à "concaténer" toute les surfaces en une seul grosse.
juste pour info, je suis sur un projet avec SFML (voir 2e projet dans ma signature); j'en suis justement
à faire des "maps" composé de dalles Si en SDL le framerate ne dépassait pas 21 FP/s (sans limitage de framerate) en affichant un grillage de 20x15 remplissant pleinement l'écran à 1280x1024, en SFML, le framerate oscillait entre 190 et 230 FP/s (sans limitage de framerate)
(PS : mon ordi est situé dans le milieu de gamme, c'est à dire ni trop mauvais ni très bon)
Tout ça pour dire que quand ma map fait 400x360, mon FP/s est mort, sauf si je fait du clipping, ce qui le remet au galop à 190~230
(PS: j'ai tendance à limiter mon FP/s dans les environs de 25~30, sinon ça vas trop vite )
Altarapp.com - Applications, Code Snippets, API Wrappers et etc, le tout en C# le plus clair du temps!
ah c'est que j'ai pas encore mit en place la gestion du temps, du coup, les mouvements de la caméra (qui est présentement la seul chose d'animé) sont un peu trop vite
(mais inquiète-toi pas, j'aurai réglé ça bientôt )
Altarapp.com - Applications, Code Snippets, API Wrappers et etc, le tout en C# le plus clair du temps!
Concernant la notion de clipping, elle m'est familière; cependant quand je parlais d'un niveau de 32*32, je pensais aussi dans le cas de tiles de petite dimension.
En effet, je ne sais pas exactement le paramètre qui influe le plus sur la vitesse de blittage, s'il s'agit bien de la taille de la surface, ou du nombre de surfaces à blitter? Aprsès quelques test, j'ai l'impression déjà que rien qu'un Flip semble avoir une durée constante ( après coup, ça ne semble pas étonnant, vu qu'un pixel blanc prend autant de temps que n'importe quelle couleur).
Darkelfe, pour le mediawiki, j'ai tout simplement téléchargé les fichiers mediawiki à ce lien:
Et après avoir decompressé le dossier dans le dossier www de mon serveur PHP (J'utilise Easy Php), j'ai lancé la page d'assistant à la création d'un nouveau wiki.
Ensuite, il y a juste quelques infos à entrer et le wiki est automatiquement créé.
Tu auras cependant besoin de créer une base de données (c'est là où j'ai eu des problèmes). Via PHP admin, tu peux facilement créer une nouvelle base, puis changer les droits d'accès.
En effet, je ne sais pas exactement le paramètre qui influe le plus sur la vitesse de blittage, s'il s'agit bien de la taille de la surface, ou du nombre de surfaces à blitter? Aprsès quelques test, j'ai l'impression déjà que rien qu'un Flip semble avoir une durée constante ( après coup, ça ne semble pas étonnant, vu qu'un pixel blanc prend autant de temps que n'importe quelle couleur).
- imagine que tu as une carte qui fait 500x500 avec des tiles de 50x50, a chaque fois que tu dessines une image elle se met dans un buffer (video je crois), mettre une image dans un buffer prend du temps, de la place (memoire). Donc avec 250'000 images de 50x50 ca prend du temps a chaque tours de boucle, avec le clipping tu n'affiche que les images necessaires, donc tu gagne en performences.
- le clipping est tres utilisé en programmation 2D
- Sans clipping : O(n)
- Avec clipping : O(1)
Voila pour toi Darkelfe (ou pour ceux que ça interresserait).
J'ai uploadé mes sources, ainsi qu'un executable (dans "final/") qui te permettras de voir comment ça fonctionne (question perfos).
Le .rar ne contient pas que les fichiers du moteur, mais aussi d'autres fichiers correspondant au programme de test(affichage d'une map, animation, etc).
Il y a aussi quelques travaux en cours que je n'avais pas encore implémenté, vu leur état actuel, je penses notamment à mon "event manager" qui n'a pas grand intêret pour le moment.
Le code n'est certainement pas ce qu'il y a de plus propre (je commence à m'en rendre compte), ou dumoins pas assez exploitable à mon goût .
En effet, tu le constateras par toi même, le tout semble renfermé sur le moteur de jeu (qui correspond au jeu lui même). Or ce n'était pas l'intention initiale (je cherchai à faire un moteur de jeu générique, le plus ouvert possible, et non spécifique à un seul et unique fonctionnement comme ça risque de le devenir à ce rythme, vu les limitations que j'ai déjà semble-t'il fixé .
Je suis donc actuellement en train de reforger l'architecture du moteur (pas présent dans le fichier), avec notamment l'inclusion de namespaces, dont j'ai récemment découvert l'utilité ici et surtout les avantages (propreté du code et structure mieu définie).
Resultat des courses, le code est beaucoups plus clair et organisé, étant donné que le jeu exploite le moteur, et non l'inverse (comme ce que j'ai actuellement). En gros, j'ai redéfini l'architecture, en supprimant définitivement la notion de "moteur de jeu" qui deviens alors tout simplement le jeu, est n'a plus rien à voir avec le moteur, autre le fait qu'il doit l'exploiter.
De plus, tout les modules sont de cette manière vraiment indépendant entres eux.
Voila, bonne lecture (si on peux dire ça comme ça ), et si tu as une question, ou quelque chose que tu ne comprends pas dans mon code, n'hésites pas.
Alors, Althar93, où en est tu avec ton projet ?
Ca marche bien ?
[SDL] Performances et "limites" de SDL?
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
La maîtrise des fondamentaux est le fondamental de la Maîtrise.