Parlons optimisation ...

Il serait aussi bon de savoir si, même si ça délaisse "un peu" le côté programmation, une action est plus longue à s'exécuter si elle est faite avec une action GML ou avec l'action Drag and Drop qui lui est dédiée et si cela à une impacte avec plusieurs élément D&D.

Edit: J'ai appris plein de bon truc dans ce topique comme le truc des tuiles et le truc des blocs qui se mangent mérite que je m'y attarde, c'est intéressant! Je dois avouer malgré tout que je suis un peu perdu dans ce que vous dites, n'étant pas un programmeur du même niveau que vous, mais ça me donne plus le goût de m'y atteler ^^.

Edit 2: Ton truc de bloc qui se mangent c'est géniale! Ça te dérange si je l'utilise dans mes futures jeux?

Biensur que non !
C'est parce que les autres ont partagés leur systèmes avec moi, que maintenant, je peux parfois partager quelques codes intéressants ^^

Je ne suis vraiment pas calé en optimisation, j'espère donc que cette question ne sera pas trop mal reçue

Vaut-il mieux gérer ses variables directement depuis l'exe (comme on a l'habitude de faire lorsque l'on débute) ou les stocker dans un fichier texte (ou ini) que l'on lit au moment d'utiliser la variable ?

J'imagine que pour les variables utilisées très régulièrement cela ne vaut pas le coup... Mais pour certaines rarement utilisées, le processus est-il plus ou moins rapide ?

Sinon, merci pour le topic, c'est une excellente idée que de rassembler tout ce savoir

Surtout ne pas stocker les variables sur un fichier.

cf wikpédia:
La mémoire vive a un temps d'accès de quelques dizaines ou centaines de nanosecondes tandis que celui du disque dur est de quelques millisecondes (dix mille à cent mille fois plus).

Donc en gros tu multiplie par 10 000 le temps perdu a cause de l'accès aux variable (ordre de grandeur)

Non dans un fichier tu peux stocker tous ce qui doit rester après fermeture du programme (sauvegarde).
Ensuite, il n'y a pas vraiment d'application pour des jeux avec Gm, et le peu de donnée que l'on manipule avec Gm pour stocker l'état de variables dans un fichier.

arthuro a écrit:

Surtout ne pas stocker les variables sur un fichier.

Justement c'est plus des variables si c'est dans un fichier x)

[TheDarkTiger] a écrit:

Parlons optimisation

parlons d'autre chose que GM alors ._.

('nuff said)

lol sup

Mais c'est pas fô x)

Non, au contraire.
Il faut justement parler de GM pour essayer de l'optimiser.
Certains voudront peut être faire des trucs qui rament pas sans passer au C/C++, Java ou autre.
Donc, il peut être utilise de savoir quoi faire pour assurer un minimum de performances.

Je viens de gagner quelques FPS en supprimant les tiles invisibles, et en annulant des draws qui se faisaient hors de la vue dans une longue boucle.

(Bon en même temps j'ai un décor remplis de tiles mouvantes donc je suis juste au dessus de 30fps)


En général, un test de position avant un draw permet de gagner un peu de temps... En se baladant dans un tableau à partir de la position qui nous intéresse seulement et pas depuis son début par exemple.
Même si il faut préférer désactiver les objets hors de la vue ou carrément supprimer des tiles si elles ne seront jamais visibles...
Mais pour les objets que l'on ne peut pas désactiver, et les éléments qui n'existent qu'en draw, un petit test rapide avant leur affichage fait pas de mal.


Attention aussi, une tile consomme à l'affichage, mais aussi à la création !
Ici aussi, faites les tests avant de créer une tile inutile, au lieu de les détruire par après. Le gain de temps au chargement est phénoménal. (je dois créer environs 40% de tiles en moins, quelques secondes sauvées sur une map géante)

En plus que GM prend du temps pour créer et initialiser vos tiles après que l'évènement les aie créées (dans un espèce d'évènement "afther"). Donc plus vous créez de tiles d'un coup, plus le "vide" qui suit suit (pendant lequel vous ne pourrez même pas afficher un écran de chargement puisque ça ne se trouve pas dans votre évènement à vous) sera long.



Bref, faire des tests avant d'effectuer une action inutile (surtout pour vos grosses boucles).

onilink_ a écrit:

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

Pourquoi tant de peine il suffit d'appeler la fonction draw_circle_precision(segments).
Il est vraie que cette fonction est peut connue mais elle fonctionne très bien coupler avec un draw_circle...

La plupart du temps il est plus rapide d'exexuter une fonction de game maker plutôt que d'en utiliser plusieurs la reproduisant (quelques cas particulier quand même.)

T’inquiète c’était juste pour un exemple, montrer qu'il faut utiliser des primitives :

Citation :

par exemple pour afficher un cercle plus précis

Sinon cette fonction n'est pas présente dans gm 6.1 a ce que je sache, hors ben moi j'y suis toujours :p

Il me semble quelle n'est pas présente dans le manuel et la liste des fonction lorsque tu écrit du code met essay, il me semble quelle fonctionne quand même (elle se met en couleur).
C'est entre autre pour sa quelle est peut connue.

Enfin bref on s'en fou.

y a pas draw_circle_precision mais y a bien draw_set_circle_precision.
Bref je savais pas qu'elle était dans gm6, mais je la connaissais, je l'ai même mis dans µdev :p
D'ailleurs j'avais listé pas mal de fonctions de ce genre, mais je sais plus ou j'ai mis ça :/

Autre sujet sur les optimisation :

La dll de cryptage de fichier la pluis rapide est :
Xor Crypt dll v2.0
LA dll pour compresser des ressource la plus rapide est :
Tar Dll [78ms pour extraire 10mb]
suivie de GMZip dll [~380ms pour extraire 10mb]

Par contre le cryptage xor c'est vraiment la protection minimale quoi...
Et y a pleins de moyens simple pour récupérer la clé.

Comme c'est le plus rapide tu peut l'appliquer deux voir trois fois et avec une grosse clef, sa commence a être dur a décrypter.

Non parce qu'appliquer plusieurs clé reviens a appliquer une seule clé qui est la combinaison des 3.
Enfin bref xor c'est le truc qui empêche juste les noobs de toucher au ressources, mais pas plus.