Bonjour tout le monde,

je voulais poser qq questions :
Actuellement j´ai ma boucle principal du jeu qui contient un appel à une fonction. Cette fonction est en fait tout le déroulement du jeu. En réfléchissant je me suis dit que c´était peut etre pas l´idéal car l´appel à la fonction répété doit surement faire ralentir le programme.
Devrais je donc par conséquent plutot appeler ma fonction UNE fois et intégrer la boucle de jeu à l´intérieur de celle ci?

Une autre question. Puis-je déclarer une variable (genre "char test;") dans une fonction qui pourrait etre appelée plusieurs fois dans mon programme (de lordre d´une dizaine de fois) ou dois je la déclarer AVANT ?
Eventuellement, est il possible de savoir si la variable existe déja ?

Voila pour les questions que je me pose a cet instant meme
Merci à ceux qui sauront m´aider

Au fait j´y pense, il y a une fonction intégrée à la SDL pour afficher le fps ou je dois le faire moi meme (juste pour pas perdre un peu de temps au cas ou...)

pour ton char : déclare le avant : ça évite qu´il soit recréé a chaque itération. Mais cependant, pour un char, tu ne perdras pas tant de temps que ça, sauf si tu es en zone tres tres critique (genre une fonction appelée plusieurs millions de fois par seconde)

Sinon, pour optimiser ton appel, si ta fonction n´est appelé qu´une fois par frame, tu ne gagneras rien.
En effet, meme si tu perds 1 nanoseconde (je dis ça au hasard) lorsque tu appelles une fonction, c´est parfaitement négligeable comparé a plusieurs milliemes de secondes que le calcul de ta frame fera.

Néanmoins, si un jour tu veux réduire les appeles de fonction, soit tu copies le corps de ta fonction brutalement a chaque fois qu´elle est appelée, soit tu demandes au compilo de le faire (pour cela, tu déclares "inline" devant tes fonctions)
Attention : les inline peuvent faire monstrueusement grossir un programme.
Sinon, jamais d´appel récursif dans une fonction inline

Ok pour le char, je pense que je vais le laisser dans ma fonction, car c´est une fonction de chargement de niveaux qui est appelée que très rarement pdt le déroulement du prog.
Par contre pour la fonction dans la boucle, le nombre d´appel à la fonction dans la boucle correspond au fps donc ca peut atteindre entre 50-100 appels par images...
Pour le inline j´y ai pensé mais je pense pas que ce soit possible (ou du moins que j´y gagne)...

Merci

sachant que les compilo savent faire des appels récursif dans les fonction inline pourvu que la profondeur de récursions soit assez faible (il y a un paramètre du genre max_inline_depth aussi bien pour VC++ que pour gcc).

Et au pire, si tu veux absolument déclarer le char dans ta fonction, tu peut toujours le mettre static

"Néanmoins, si un jour tu veux réduire les appeles de fonction, soit tu copies le corps de ta fonction brutalement a chaque fois qu´elle est appelée, soit tu demandes au compilo de le faire (pour cela, tu déclares "inline" devant tes fonctions)
Attention : les inline peuvent faire monstrueusement grossir un programme.
Sinon, jamais d´appel récursif dans une fonction inline"

fichier de taille infinie? Plantage du compilo?

Une regle importante sur l´optimisation a savoir c´est : "20% du code prends 80% du temps"
Ca veut dire que tout ton temps de calcul est bouffé souvent par une petite partie de ton code. La strategie d´un programmeur c´est de faire tout son code (sans se soucier de l´optimisation) et a la fin de detecter les 20% de code "lent" et de les optimiser.
La conclusion c´est qu´il est inutile d´optimiser tout le code qui est pas "lent", c´est a dire ce qui est appellé peu de fois. La boucle de jeu principale est un bon exemple. Comme a dit JyyFVirtman, tu gagneras rien du tout.

Pour le car test, c´est pareil, inutile de chercher a le generaliser, tu va rien gagner du tout. Declarer une variable globale, au niveau langage machine, ca va decrementer un pointeur sur ta pile memoire, ce qui prends rien en temps.

Au contraire, utiliser un static, va mettre ta données plus loin en memoire et donc casser le cache de données du processeur, ca risque de rien faire gagner voir meme d´etre plus lent.

je rajouterai qu´avant de taper dans les finesses, et rendre le code moins lisible, de mauvais algos sont la premiere source de temps perdu ! Qqun disait je ne sais plus ou :
"1 - make it work
2 - make it right
3 - make it fast"

d´abord, arriver au resultat souhaite, ensuite s´assurer que ses structures de donnees et algos sont bien penses dans la bonne optique, et optimaux pour le pb traite ; ensuite, si c´est une section critique, alors la optimiser en finesse.
Dans tous les cas la lisibilite du code est TRES importante. S´il faut reecrire des portions de code de maniere peu intuitive pour optimiser (vectorisation pour du SSE, asm, approx tordues, etc.), garder une version "propre" du code non optimise faisant la meme chose en commentaire peut etre une bonne idee.

Merci pour vos conseils, c´est vrai que pour le moment, I try to make it work^^ mais je me posais déjà qq questions d´optimisation, mais je vais les remettre à plus tard une fois que j´ai une vue d´ensemble.
A bientot