Parlons optimisation ...

Ce thread est là pour parler des petits trucs que vous avez trouvé pour optimiser la vitesse d'exécution sous GM.

Quand j'aurais un peu de temps, je regrouperais, ici, en premier post, des stats sur les apels de fonctions pour savoir si repeat est plus rapide que for, ou si les tableaux sont plus lents que les ds_grids (ce sont des exemples bien entendu, les deux sont vrai ...)

Bah deja faire lengthdir_x(k,a) est beaucoup plus rapide que de faire cos(a*pi/180)*k ou cos( degtorad(a) )*k , bon ça c'est très connu.

Ensuite, par exemple pour afficher un cercle plus précis, au lieu d'utiliser les lignes user des primitives :

Non optimisé :

Code:

for(i=0 ; i<360 ; i+=10)
draw_line(x + lengthdir_x(64,i), y + lengthdir_y(64,i), x + lengthdir_x(64, i+10), y + lengthdir_y(64, i+10))

Optimisé (2x plus performant) :

Code:

draw_primitive_begin(pr_linestrip)
for(i=0 ; i<360+10 ; i+=10)
draw_vertex(x + lengthdir_x(64, i), y + lengthdir_y(64, i))
draw_primitive_end()

Autres choses :
-éviter de recalculer plusieurs fois la même chose, mieux vaux créer une variable plutôt qu'appeler plusieurs fois un même calcul.
-utiliser le moins possible les opérations / fonctions couteuses

Wep.
On pourrait rajouter les opérateur de décalage (>> et <<) au lieu des multiplications. Mais vue que GM utilise des doubles, je sais pas si c'est vraiment plus performant ...

oui pour gm je crois pas que les opérateurs de décalage soient plus rapides (d'ailleurs je vais essayer on verras bien).

edit : et ouai j'avais malheureusement raison ....
preuve :

Code:

boucle = 1000000

start_time = current_time
for(i=0 ; i<boucle ; i+=1)
    test = 12345 * 256

show_message( "temps avec multiplication : " + string(current_time-start_time) )
start_time = current_time

for(i=0 ; i<boucle ; i+=1)
    test = 12345 << 8

show_message( "temps avec decalage binaire : " + string(current_time-start_time) )

Ce qu'il faut savoir :

-Les commentaires ne ralentissent pas le programme, quel que soit leurs taille
J'ai effectué plusieurs tests qui le certifient (parce qu'avec GM on sait jamais, son interpréteur et bizarre)

-Les appels de script doublent presque le temps pris par du code a s'exécuter.
Test : 10^6 itérations sur draw_circle(x, y, 240, 1)
Temp : entre 4400 et 4500 ms

Test2 : 10^6 itérations sur script0() , script0 contenant draw_circle(x, y, 240, 1)
Temp : entre 7000 et 9000ms

Test2 : 10^6 itérations sur script0() , script0 contenant script1() qui contient lui draw_circle(x, y, 240, 1)
Temp : entre 11500 et 12000 ms

-Les boucles repeat, for, et while sont aussi rapide (contrairement a ce que disais TDT?)
Test : 10^6 itération sur un code simple
résultat avec :
-repeat : ~12 000 ms
-for : ~12 000 ms
-while : ~12 000 ms

-/!\ Un appel de script vide prend un peu de temps
Test : 10^6 itération sur un script vide
temp : 3500ms

J'ai lu que en C# la fonction math.Pow est plus lente que de le faire à la main (T*T*T*T*T*T)
à tester par contre si c'est pareil sous GM

Je viens de tester et sou GM c'est l'inverse. power(n, 10) est deux fois plus rapide que de faire n*n*...*n 10x
En même temps ça peut sembler logique si power est une fonction compilée, donc n*n*...*n seras interprété est donc plus lent.
Bon a savoir.

Oui mais aussi car pow(x,n) utilise un algorythme plus rapide que de faire une simple multiplication plusieur fois

au lieu de faire simplement x*x*x*x*x*x*x*x*x (8 operation)
ont fait
x*x -> x²
x²*x² ->x^4
x^4*x^4 ->x^8
x^8*x ->x^9

(4 operation) +(test parité)

autre exemple :
x^68 (68 operation par iteration)
x^68 (8 operation par l'algorythme)

bref doubler la puissance ne fait qu'augmenter que de 1 (a peu près) le nombre d'opération


d'où le gain de vitesse

____________________________________________________________________________________________________________________________________

Utiliser les fonctions d'activation des objets


On y pense pas mais ces fonctions permettent de gagner un temps fou dans certains jeux

Code:

instance_deactivate_region(view_xview[0], view_wview[0], view_hview[0], false, true);
instance_activate_region(view_xview[0], view_yview[0], view_wview[0], view_hview[0], true

);


dessiner d'abord sur une surface puis dessiner la surface sur l'ecran

les fonctions comme draw_line, draw_rectangle, draw_circle , on peux gagner du temps en n'en dessinant plusieurs en passant par une surface puis dessinant la surface ensuite (c'est plus rapide)

Optimisation vraiment bête, mais ne sait t'on jamais...
1) Utiliser des tuiles au lieu d'utiliser des objets, ça permet d'avoir plus d'image par seconde.
2) Ceux qui ont besoins de la collision peuvent poser des objets solides qui "fusionnent"
entre eux lors du premier step de la room. Par exemple, on a des blocs de 32x32 transparent mais solide [parcequ'on les a poser sur des tuiles] sont aligner sur l'horizontal et sur la vertical comme une croix, au final il me restera 3 blocs solides. De même, une très très longue ligne droite ne me coutera que 1 objet solide (même si lorsque j'ai édité ma room, j'en ai posé une centaine de 32x32 pour ne pas me fatiguer).

Je vous promets que ces deux petits trucs combinés donnent un très gros coup de boost aux performances dans les jeux de plateformes, surtout si la room est énorme. J'ai jamais entendu quoi que ce soit sur ce sujet, ça fait un an que je l'ai intégré dans mon Mario. J'ai fais plein de teste et ça ne fait aucun doute que le gain est énorme.

Perso, une foi que mes obj_solide_24x24VD ont mangé leur copains d'à coté, ils deviennent des obj_bloc_repos [dans lesquels il n'y a aucun code, juste un sprite de 32x32 qui n'est pas affiché, mais que je peux quand même afficher pour voir comment les blocs se sont mangés].



CODE :

Spoiler:

obj_solide_24x24VD est solid=1 ; obj_solide_32x32_repos est aussi solid=1 ;
obj_solide_24x24VD est visible=0 ; obj_solide_32x32_repos est visible=0 aussi;




Remarquez les carrés de 32x32 qui se sont étirés pour manger leur voisins :

Spoiler:

PS : le premier qui me dit que je n'ai pas choisi le bon topique pour faire la promo de mon jeu, je lui réponds que je vois pas comment j'aurais pu prendre une autre capture d'écran puisque je n'ai mis ce système que dans ce projet.

C'est vrai qu'avec ça on peut gagner pas mal de perfs, je l'avais fait dans un vieux zelda, mais maintenant je fait une détection des tiles directement. Beaucoup plus pratique dans des jeux genre a la pokémon (déplacement case par case) ou les collisions ne demandent que peu de tests. C'est utilisable dans tous les domaines d'ailleurs, mais plus une map a de tiles, plus le système est lent. Pour les collisions on peu aussi (pour des map pas trop géantes) , si elles sont seulement avec des bloc de même taille s'aider d'un tableau. Le gain de perf est énorme, mais ça bouffe pas mal en mémoire si on utilise pas d'opérateurs binaires pour compresser le tableau.

uh? opérateur binaires pour compresser le tableau?

bah un tableau de booléen sous gm ça n'existe pas, mais tu peut, au lieu de ne stocker qu'une valeur par case en stocker plusieurs avec les opérateurs binaires. Je dirais qu'avec une seule variable tu peut au moins stocker une 30 aine de booléens, ce qui n'est pas négligeable.
On peut même creer ses propres types et ainsi optimiser la mémoire. Genre si t'as une structure qui ne prendrais que des valeurs de 0 à 3 bah tu n'utilise que 2 bits et ainsi de suite.

ah ok!

onilink_ a écrit:

bah un tableau de booléen sous gm ça n'existe pas, mais tu peut, au lieu de ne stocker qu'une valeur par case en stocker plusieurs avec les opérateurs binaires. Je dirais qu'avec une seule variable tu peut au moins stocker une 30 aine de booléens, ce qui n'est pas négligeable.
On peut même creer ses propres types et ainsi optimiser la mémoire. Genre si t'as une structure qui ne prendrais que des valeurs de 0 à 3 bah tu n'utilise que 2 bits et ainsi de suite.

j'en étais sur

onilink_ a écrit:

C'est vrai qu'avec ça on peut gagner pas mal de perfs, je l'avais fait dans un vieux zelda, mais maintenant je fait une détection des tiles directement. Beaucoup plus pratique dans des jeux genre a la pokémon (déplacement case par case) ou les collisions ne demandent que peu de tests. C'est utilisable dans tous les domaines d'ailleurs, mais plus une map a de tiles, plus le système est lent. Pour les collisions on peu aussi (pour des map pas trop géantes) , si elles sont seulement avec des bloc de même taille s'aider d'un tableau. Le gain de perf est énorme, mais ça bouffe pas mal en mémoire si on utilise pas d'opérateurs binaires pour compresser le tableau.

J'y avais pensé.

Mais trop long à mettre en place pour moi ^^
Puis, lorsque les processeurs auront plus de Ghz, [seul truc utile sous GM], en s'y prenant assez simplement, on pourrait avoir une map infini sans pomper trop trop de perf.
Il suffirait d'activer/désactiver les obj_solide qu'une foi par seconde, et de charger/décharger les tuiles et les objet dès qu'on s'est déplacé d'une certaines longueurs. M'enfin, les jeux seraient alors limités à ceux qui ont un pc avec un processeur suffisant [genre 4Ghz]. Mais ça suffirait pour faire un système simple de room infini. Déjà avec deux ghz on pourrait, mais la marge de perf laisser pour le reste est trop faible pour moi [car je tourne en 1080x1920]

j'ai un processeur pas terrible et pourtant j'ai déjà fait des map infinies. C'est juste une histoire d'optimisation, et surtout de ce résoudre a ne pas utiliser le système de cartes de GM, qui a l'air super au premier abord, mais qui en fait est vraiment daubé en perfs et en mémoire :/

Les maps infinis, c'est facile si tu es dans une faible résolution avec des graphismes pauvres.
Essais en 1920x1200 avec des blocs de 32x32 et quelques systèmes pompeux derrières et là, jpense que tu te rangeras de mon coté XD

Sauf tet si on utilise bien les tableaux, tet oui. j'attends qu'on me trouve une solution pour mon projet alors si c'est fesable !!!

Une map infinie faut se la jouer à la gta, quand on se déplace dans la map, on ne charge en mémoire que ce dont on a besoin : images, instances, etc... et pas seulement activer/désactiver, mais plutôt créer et détruire en s'occupant soigneusement de la mémoire. Enfin je n'ai pas testé mais c'est mon point de vue là dessus...

Un truc qui m'a toujours fait marrer dans gta, c'est les bugs du genre quand on va trop vite et que les textures ne se sont pas chargées encore, après on se croirait dans la ville de bug de pokémon bleu... (je sais j'ai des références de malade)

lol, en tout cas elle était assez impressionnante cette ville bug. Je me suis toujours demandé comment de tels bugs peuvent se produire lorsque l'on développe un jeu. On a tellement l'impression d'avoir le contrôle partout.

Le truc des blocs qui se mangent, j'y ai toujours pensé sans jamais avoir sérieusement planché dessus !

Ca va m'optimiser aussi des draws pour mes ombres ça, j'temprunterai le squelette le code à l'avenir Topaze. :lng:


Je me suis aussi toujours demandé comment ils arrivent à faire des glitch etc dans des jeux pro, alors que sous Gm et autre on a aucun problème.
Je crois que c'est une histoire de mémoire si petite qu'ils stockent des trucs sur les même cases en permanence sans forcément les vider,
et donc que si c'est pas vidé et réinitialisé y'a facilement des transferts de données pas voulues dans les trucs testés à ce moment précis...



Sinon ; comment optimiser l'affichage de 1000 tiles à depts indépendants ?

L'optimisation des tiles c'est GM qui s'en occupe normalement.
Pour les glitch faut pas oublier une chose, c'est toujours dans des jeux professionnels qu'on en trouve, et c'est donc de très gros projet, avec une gestion de la mémoire super optimisée, et surtout, ce n'est jamais fait dans un langage interprété, donc la moindre erreur s'avère beaucoup plus fatale. Après, je vois pas beaucoup de jeux 2d avec des glitch, mais c'est plutôt dans des jeux en 3d (souvent du a un problème de valeurs qui finissent par s'arrondir, les valeurs parfaites ça n'existe qu'en maths), et des jeux 3d fait avec GM y en a pas des masses, et encore moins avec une gestion des collisions 3d (la bête noire des programmeurs :p )

onilink_ a écrit:

L'optimisation des tiles c'est GM qui s'en occupe normalement.
Pour les glitch faut pas oublier une chose, c'est toujours dans des jeux professionnels qu'on en trouve, et c'est donc de très gros projet, avec une gestion de la mémoire super optimisée, et surtout, ce n'est jamais fait dans un langage interprété, donc la moindre erreur s'avère beaucoup plus fatale. Après, je vois pas beaucoup de jeux 2d avec des glitch, mais c'est plutôt dans des jeux en 3d (souvent du a un problème de valeurs qui finissent par s'arrondir, les valeurs parfaites ça n'existe qu'en maths), et des jeux 3d fait avec GM y en a pas des masses, et encore moins avec une gestion des collisions 3d (la bête noire des programmeurs :p )

C'est clair, sachant qu'un float ou un double aura très souvent une valeur approchée et non exacte d'un nombre a virgule..

Salut.
J'ai quelques question sur les optimisation (de base surtout)
-est ce qu'il faut mieux créer 50 objets différent tous parent avec le même, ou créer un seul objet avec 50 propriété différentes?
-les ressources externes font-elles mieux ramer un jeux?

(si vous préférez que j'innonde la section débutant avec ce genre de question c'est pas un probléme )

Les ressources externes sont obligatoires lorsque tu t'attaque a un gros projet. Au moins tu a le contrôle sur la mémoire ram qu'elle prennent en chargeant/libérant les ressources.

Pour la première question je pense que les parent sont plus adaptés, mais niveau perfs j'ai jamais testé donc je peut pas te dire, mais a mon avis c'est la même chose.

Chulien a écrit:

Une map infinie faut se la jouer à la gta, quand on se déplace dans la map, on ne charge en mémoire que ce dont on a besoin : images, instances, etc... et pas seulement activer/désactiver, mais plutôt créer et détruire en s'occupant soigneusement de la mémoire. Enfin je n'ai pas testé mais c'est mon point de vue là dessus...

En effet, c'est bien comme ça que l'on fait des maps infinit, sauf que créer et détruire, ça met des coups de lags, donc il vaut mieux au niveau des perfs avoir de quoi tenir une zone assez large.

Et en 1920x1200, les zones que tu dois activer/desactiver doivent être un brin plus grande que l'écran, si en plus tu perds des perfs ou te prends un coup de lague à chaque foi que tu franchis 3 écrans, c'est embêtant. M'enfin, c'est faisable, je compte essayer un de ces quatre, il me suffit de me servir des scripts que j'ai vu traîner dans le coin pour charger/décharger des tuiles.


M'enfin, c'est faisable, à condition d'avoir un dual core à 3Ghz sous le capo, et moi, je souhaitais qu'un dualcore à 1.7ghz suffise et avec un 1.7Ghz, il ne reste plus beaucoup de marge pour le reste avec un système d'affichage en 1920x1200 et trop de ressource objet et tuiles à vérifier constamment.

Sinon il reste GMAPI

nimp pour la mémoire, c'est mieux de tout charger genre gros chargement ensuite pour genre gta et les map infinie c'est du LOD (level of detail) on a un gros terrain bien défini (beaucoups de poly) et on calcule un terrain optimisé pour la position courante genre ce qui est proche est plus détaillé que ce qui est loin, en 3D le seul moyen d'optimiser c'est d'afficher moins de triangle (et pas de charger moins de texture où je sais pas quoi), la ram on s'en fou un max (la vram aussi ) d’ailleurs des system très lourd comme un octree 3D sont plus rapide que de rien faire ou je ne sais quoi. Sinon pour les ressources externe ouai, c'est histoire de charger que ce qu'il faut pour un niveau donc vaut mieux faire un gros chargement avant chaque niveau plutot que pendant le jeu, l'allocation mémoire c'est très lent d'où 'ça ram' (c'est plus la pagination mais bon soit) je veux dire on a tellement de ram de nos jours que ça sert a rien de rechinier pour un ou deux octets.
Soit si quelqu'un trouve que je raconte n'importe quoi ; je m'en fou

Un ou deux octets ok, mais 100 ou 200 mo non !

En tout cas pour les jeux en 2d le chargement de quelques ko, même pendant le jeu ça fait aucun lag (enfin avec un langage bas niveau) , et c'est super pratique.

bin ouai justement il vaut mieux faire de grosse allocation plutôt que des petites, ensuite pour les 200 Mo limite ça me semble pas exagéré et ça reste largement inférieur à la taille des rams. L'optimisation en ram c'est d'allouer le moins de fois possible (peux importe la taille, c'est plus au moins constant).