Salut tout le monde,

J´aimerais savoir comment réduire au maximum le ralentissement de mon projet. C´est à dire quelles sont les règles de programmation à respecter pour qu´un jeu... avec du graphisme, de grandes cartes, plusieurs personnages... ne ralentit pas.
- Doit-on détruire les bitmap qui ne sont pas affiché et les recharger que lorsqu´ils sont à l´écran ?
- Doit-on réduire les calculs ?
. ..

Ce que j´ai fais pour l´instant, et ça a accéléré la vitesse de mon jeu, c´est d´effacer les dessins qui ne sont pas à l´écran et les dessiner que lorsque le joueur doit le voir. L´ordinateur prend en compte de simples valeurs numériques de positions, d´actions... mais ne dessine rien en mémoire tant que les éléments en questions sont endehors de l´écran. Que puis-je faire encore pour réduire le ralentissement au maximum ?

la plus grosse cause de ralentissement probable, c´est des algos bancals, avec des complexité ignobles, ou encore des structure de données mal adaptées.
On ne connait pas assez ton projet et ton niveau de programmation pour t´aider spécifiquement, mais qq conseils généraux quand meme :

- avant de chercher à optimiser à optimiser, cherche à évaluer ce que " coute" chaque partie du jeu, en terme de calculs et rapidité.
- desactive successivement certains modules de ton projet, pour voir si cela améliore les choses : si tu desactives la gestion des ennemis et que tu gagnes quasiment rien en performances, ça ne vient pas de là, par contre si tu desactive tout l´affichage et que là tu multiplies par 10 tes résultats, c´est que ton affichage est TRES bancal

Il est evident que tout ce dont le jeu peut se passer pour continuer à tourner, il ne faut PAS le gérer, et réduire les calculs au strict minimum de ce qui est utile ( genre, gérer les ennemis qui sont à 10km sur la carte ne sert pas à grand chose)
Donc, en qq étapes :
- désactiver la gestion de ce qui n´est pas utile
- identifier les bottleneck
- changer les algos ou les structures de données
- changer de modele mathématique ou approximer pour obtenir grossierement les meme résultats en moins de temps
- changer la méthode de code pour un algo donné

Quand tu as fait tout ça, et que tu n´es toujours pas satisfait, il faut revoir à la baisse les spécifications. Mais étant donné les machines actuelles, si tu fais ramer une bécane c´est que qqch cloche...

Dis nous en plus sur ton projet qu´on sache un peu de quoi tu parles.

J´en dis plus sur mon projet :
C´est un jeu en vue isométrique tout en 2d. C´est le genre de Age of Empire mais poussant le genre vers Caesar III. Il y a une difficulté supplémentaire, mais au point où j´en suis je ne sais pas si j´irais jusque là. La difficulté supplémentaire est que chaque personnage doit vivre sa vie comme dans les Sims, ce qui les rend presque totalement indépendant.

Pour l´instant, je ne suis qu´au développement de l´éditeur de carte, et avec une carte composé que de cases de terre, de 60x60 cases, sans personnage, bâtiment... l´éditeur ralentit. Le programme a donc sacrément besoin d´optimisation.

Mon niveau de programmation, je ne sais pas le determiner, je me considère toujours comme débutant. Je suis un autodidacte.

Voilà, j´espère que ça peut vous aider.
PS : Sinon sur mon blog, j´en parle de temps en temps, j´ai mis une image de la version actuelle de l´éditeur de carte. Mais, je ne fais pas de pub, ça serais manquer de respect au forum.

premiere chose, quelle lib utilises tu ? ( il est préférable de mettre tes blocs en VRAM si tu peux)
Evite de les détruire pour les réallouer juste apres : ça, ça fait lagger a mort...

Affiche uniquement, bien entendu, les blocs que tu vois a l´écran ( un clipping)

Apres, point de vue technique, il nous faudra + de détails sur ta lib ( je me répete) les fonctions que tu utilises, etc !

Une optimisation également ( je parle peut etre dans le vent car je ne sais pas ou tu en es)

tu travailles en double-buffering ?
Si c´est le cas, surtout, ne fait pas de CLS ( comprendre clear screen) quand tu récuperes une surface :
un écran de 1024*768 est composé de ~ 1 000 000 de pixels : évite tous les CLS que tu peux
l´astuce des jeux 2d est de ne pas faire de CLS, et s´assurer qu´on redessine de partout, pour bien écraser l´écran d´avant dans sa totalité.

ne pas locker 15 fois la texture en Vram ^^

Si l´API utilisee n´est pas en bois, un clearscreen ne changera pas grand chose, dans la mesure ou ca deleguera au hardware ; mais c´est en effet une bonne piste a explorer si l´API fait pas correctement son boulot ( a titre informatif, en DX un ClearBuffer - hardware - est plusieurs centaines de fois plus rapide qu´un FillColor - qui lui passe en software - )

Je n´efface pas l´ecran, puisque je ne dessine pas directement sur lui, mais un buffer où est dessiné la matrice avec tout ce qui va dessus en dehors de l´interface. Puis il y a un deuzième buffer qui est dessiné dessus et contenant l´interface. J´ai fait comme-ça parce que ma matrice avec ce qui se trouve dessus doit pouvoir défiller à l´écran en déplaçant le curseur sur les bord de l´écran. Mais l´intreface devant rester en place à l´écran, j´ai réussi comme-ça. C´est peut-être pas correcte comme méthode, qu´en pensez-vous ?

Ah oui, ma librairie est Allegro.
J´ai préféré limiter la taille de l´écran à 800*600, plus grand je trouvais que c´était délicat, plus petit c´est délicat à jouer, on ne verrait pas très bien ( En tant que joueur invétéré de jeux de gestion/strategie en vue isométrique, je m´y connais ) ) .

A y est, mon problème est réglé. Merci de vos conseils, ils m´ont été très utiles et le seront encore à l´avenir.

Inscrivez vous à la noire furie.
Trop de la balle.

Hier, j´ai songé à une technique pour acceléré encore plus mon jeu. Je ne sais pas si ça porte un nom, et si c´est valable.
Voilà, je regarde chaque équation que doit calculer mon ordinateur pendant le jeu. Je repère toutes les parties qui sont similaire entre différentes équations et qui ne change jamais ou pas souvent. Je l´ai remplace par des variables contenant le résultat de ces parties pour que les équations demande moins de calculs à faire, pendant la partie.
Seulement voilà, Ces variables sont calculés avant le lancement du jeu, pendant le chargement des données. Et donc ça ajoute plus de variables enregistrés dans la mémoire.

Donc d´un côté les calculs pendant la partie sont moins conséquents, ce qui est avantageux en terme de vitesse. Mais d´un autre côté, mon programme possède plus de ligne de code, donc l´exe est plus lourd et l´ordinateur doit enregistrer plus de variable pendant son execution, donc besoin d´une capacité de mémoire ram plus étendu. Là, je ne sais pas si c´est vraiment gênant.

Pour des ordinateurs récents, ce n´est peut-être pas problématique, mais des ordinateurs moins récents, avec moins de place sur disque dur et en RAM, c´est peut-être plus embêtant.

Qu´en pensez-vous ?

Bonjour, je suis pas programmeur ( dans un language technique) mais a mon avis c´est pas 150 lignes de plus dans ton exe qui vont rajouter 1 Mo non?

il faut clarifier un peu les choses, pour pouvoir dire si c´est bien ou pas. Evidemment, il FAUT minimiser la complexité des calculs, en précalculant plus ou moins, mais voilà qq grandes lignes :

- un algo est généralement qqch qui traite en ensemble de données, en une ou plusieurs boucles dessus. Il FAUT sortir des boucles tout ce qui reste constant ! Sans pour autant les foutre globales cela dit, qq var sur la pile avant d´entrer dans les boucles, et ça roule. Mais surtout, ne pas aller foutre en variable globale, qq résultats de multiplications de constantes ( sauf si utilisé partout, bien sur)
- pour les algos qui ont besoin de resultats de calculs complexes, on peut faire une LUT ( look-up table). Par ex. un algo qui a besoin de logarithmes, on peut faire une table contenant un certain nombre de valeurs précalculées. Il faut alors trouver le bon compromis entre taille de la table ( = mémoire allouée), et l´erreur qu´on introduit. La, c´est au programmeur de savoir quelle plage d´erreur est acceptable pour son algo. Sur un modele mathématique pour de la physique de collisions par ex. une tres petite erreur peut aboutir à des calculs completment faux, alors que pour de l´affichage, la perte de précision peut etre plus important.
- il faut simplifier les modeles mathématiques ! là encore, en tenant compte de l´erreur introduite. Par ex. pour calculer des racines carrées, on n´hésite pas à faire des développements limités à un ordre relativement faible.
- ne calculer que ce sont on a besoin ; ex : tu veux les longueurs de deux vecteurs, compares leurs normes au carrées, le resultat sera le meme que si tu le fais avec les racines. Sauf que tu évites de calculer les sqrtf(), donc tu gagnes un temps précieux.
- linéariser les modeles. C´est surtout vrai pour les boucles imbriquées, où une valeur dépend des indices qui changent : en général on peut transformer des opérations complexes en de simples incréments d´une itération à l´autre
- en dernier point, connaitre l´archi matérielle peut aider à grater encore qq µs ici ou là ( changer les méthodes d´adressage par ex.)

voilà, tout ça pour dire qu´il FAUT limiter les calculs et virer tout ce qui est compliqué, qu´il ne faut pas surcharger la mémoire si c´est inutile mais si c´est interessant, qq LUTs peuvent etre salvatrices.
Au passage, la taille d´un exe ne veut pas dire grand chose, ça dépasse rarement les qq Mo d´ailleurs, par contre c´est bcp plus interessant de voir la taille de mémoire dont il a besoin.

qq conseils finaux : 1) écrire du code paramétrable ! la tailles des LUT par ex. doit pouvoir etre facilement changée à coup de constantes qui apparaissent clairement dans le code, de meme que les marges d´erreurs, etc. C´est un peu plus long a écrire, mais c´est un gain de temps a final quand il faut " tuner" l´appli. Une fois l´algo écrit, tu joues aves le jeu de valeurs qui le parametres pour trouver le bon compromis : trop de précision ? trop de mémoire ? pas assez rapide ? change les valeurs, jusqu´à trouver la combinaison adéquate et etre satisfait.
2) garder une version claire et naive de l´algo, en commentaires ; c´est bcp plus facile de comprendre ce que fait le code

pour conclure, qq exemples concrets :

- un cas d´approximation de modele mathématique http://www.flipcode.com/articles/article_fastdistance.shtml
- un exemple de linéarisation http://wall.cours-info.net/?id=384 ( ce code date, je faisais ça sur Cyrix 120+ LOOOL :/ . .. 2 add/mul par pixel, au lieu de 4 cos/sin, pour une rotozoom. Je dois encore la version ASM qui traine qqpart :-? . .)
- un exemple de LUT http://www.saccade.com/wr/writing/graphics/RE-PARAM.PDF ( pour l´avoir implementé recemment, je confirme que ça marche :D )