Utilisation de l'UC

Bonjour !

Voilà : comment optimiser l'utilisation de l'UC (et de la mémoire) par un jeu GM ?

En effet, je me suis rendu compte que mon jeu consomme énormement : 50 Mo pour la mémoire, et par rapport à mon Core2Duo, utilisation à 40% de l'UC.

Le jeu est en 60 fps.
Dans mes objets, j'ai beaucoup de lignes de codes, mais la plupart du temps, seulement une partie est exécutée avec un switch.
De plus, je n'ai pas encore de musiques, pas beaucoup de ressources (320 ko le .gmk).
Pour un ordinateur récent ce n'est pas trop un problème, mais pour une "vielle" machine, ça rame ...
Donc que faire ?!

Et par la même occasion : j'ai un moteur de texte qui utilise une surface, ça fonctionne très bien. Cependant sur W7 x64 le texte est coupé, quel est le problème ?!
De plus, est-ce que les surfaces consomment beaucoup de mémoire vidéo ?

Merci !

une surface consomme largeur*hauter*32 octets de mémoire

je sais que les rooms consomment pas mal de mémoire, après je sais pas, tu charge des ressources externes ?

Non aucunes ressources externes ...

y a ça dans la doc

Citation :

Si vous projetez de réaliser des jeux complexes, vous voudrez probablement les rendre aussi rapides que possible. Bien que Game Maker fera le maximum pour que les jeux soient rapides, cela dépendra beaucoup de la manière à laquelle vous avez conçu votre jeu. Bien entendu, il est vrai qu'il est plus facile de créer un jeu qui consomme trop de mémoire que l'inverse. Dans ce chapître, je vous indiquerai certaines astuces qui pourront contribuer à rendre vos jeux plus rapides et plus petits en taille.
Premièrement, soyez attentif en ce qui concerne les sprites et les arrière-plans (backgrounds) utilisés. Les sprites animés prennent beaucoup de mémoire et dessiner de nombreux sprites prend beaucoup de temps. Aussi, créez vos sprites aussi petits que possible. Supprimez toutes les zones invisibles autour de ces derniers (la commande crop de l'éditeur de sprites le fait automatiquement). C'est la même chose en ce qui concerne les images d'arrière-plan. Si vous avez un arrière-plan plein, vérifiez que vous avez désactivé l'utilisation de la couleur d'arrière-plan.

Si vous êtes en mode plein écran, soyez sûr que la taille de la room (ou la fenêtre) ne soit jamais plus large que la taille de l'écran. La plupart des cartes graphiques savent efficacement mettre à l'échelle les images mais la mise à l'échelle de ces images ralentira cependant l'affichage ! Autant que possible, désactivez l'affichage du curseur. Lui aussi ralentit l'affichage des graphiques.

Soyez également prudent lors de l'utilisation des vues (views). Pour chaque vue, la room sera redessinée.

En plus des graphiques, il y a aussi d'autres aspects qui peuvent influencer la vitesse du jeu. Veillez pour qu'il y ait le moins possible d'instances. En particulier, détruisez les instances qui ne sont plus nécessaires (ex: lorsque vous quittez la room). Evitez de placer beaucoup d'actions dans l'événement step ou dans l'événement d'affichage (drawing event) des instances. Souvent, il n'est pas indispensable de les placer à chaque step. L'interprétation du code est assez rapide mais c'est tout de même du code interprété. De plus, certaines fonctions et actions prennent beaucoup de temps; en particulier celles qui doivent vérifier toutes les instances (comme par exemple l'action de rebondissement (bounce action)).

Réfléchissez sur la façon de gérer les événements de collision. Vous devriez avoir normalement deux options. Les objets qui n'ont pas d'événement de collision seront exécutés plus rapidement, aussi il est préférable de traiter les collisions avec les objets qui possédent peu d'instances.

Soyez également attentif lors de l'utilisation de gros fichiers sons. Ils consomment beaucoup de mémoire et se compressent assez mal. Vous devriez analyser davantage vos sons afin de voir s'ils ne peuvent pas être mieux échantillonnés.

Enfin, si vous voulez réaliser un jeu avec lequel la plupart des gens puissent jouer, testez-le sur les plus vieilles machines.

Oui, j'avais déjà lu ça mais bon ...

mais bon que veux tu qu'on te dise de plus :p

Enfin peut etre que tu utilise trop de gros tableaux.
Il faut savoir que chaque variable de GM tient sur 8 octets, donc selon la taille de certains tableaux ça peut faire lourd.

Ensuite les chaines de caracteres prennent un octet par caractere.

Perso, en créant un personnage qui tirait des balles avec une arme, chaque tir occasionnait une augmentation de ~2Mo de RAM.
Alors je vous dis pas qu'on se retrouve en 30 secondes avec 200Mo de RAM...

Surtout que le son de cette dernière était de 20 octets. >.<"

GM = mal optimisé ?

si tu prog bien ton jeu normalement y a pas de soucis quand meme.
Et puis pour les sons vaux mieux utiliser une dll parce que Gm ....

Randal a écrit:

Perso, en créant un personnage qui tirait des balles avec une arme, chaque tir occasionnait une augmentation de ~2Mo de RAM.
Alors je vous dis pas qu'on se retrouve en 30 secondes avec 200Mo de RAM...

Surtout que le son de cette dernière était de 20 octets. >.<"

GM = mal optimisé ?

mais ton systeme est inferieur a XP, c'est un peut normal, c'est mal optimisé (a mon avis)

Merci.

Bon, j'ai réussi à faire (un peu) baisser l'utilisation de l'UC en utilisant des surfaces, plutôt que de tout redessiner à chaque step ... maintenant, ça monte à 30% max.
J'espère que ça ne consomme pas trop de mémoire vidéo maintenant ...

Je vais donc essayer d'utiliser le moins de code (et calculs) possible, je pense que c'est la seule solution. Et puis pour les systèmes trop vieux, bah tant pis ...

c'est pas le code qui fait ramer l'ordi, qu'il soit gros ou pas, c'est son optimisation, de faire des bonnes methodes plutot que celle qui font ramer l'ordi (comme les boucle qui n'ont pas d'utilité)

Non mais quand je dis "le moins de code", ce n'est pas en écrire moins, mais de l'utiliser que quand c'est utile.
Ce qui me fait beaucoup de calcul, ce sont les for, j'en utilise souvent ...

une boucle vide ca prend presque 0 sec pour faire de 0 à 1milion
après ca dépend de ce que tu met dedans

+1 pour wargamer.
Et après, il faut voir les opérations dedans, il y a des trucs qui prennent beaucoup plus de temps que d'autres (ne serait-ce que les accès fichiers et les draw_getpixel() ...)

Je sais que ce post commence a dater, mais au cas ou :
niveau optimisation dans gm, évite le switch. Ensuite si tu utilise pas mal d'objets, faut éviter aussi .

Ça serait tlmt bien si gm supportait les types de variables; histoire d'éviter d'utiliser 8 octets pour un boolean..

Gm est en effet extrement mal optimise.

Ah oui, les switch c'est mauvais ?!
Je n'utilise que ça ... en effet, ça évite de lancer des lignes de code inutiles, non ?

idem, ou alors un else if mais quand t'a plusieur truc ca vient vite le bordel

lol mon projet actuel consommait 100 Mo de RAM =)

lol mon projet actuel consomme 9 Mo de RAM =)

Le truc que tu m'as montré lol ? x)

onilink_ a écrit:

lol mon projet actuel consomme 9 Mo de RAM =)

Un pong en noir et blanc ? >:P

Un zelda style oracles of seasons >:p

De toutes façon il peut consommer 9 ou 100Mo de RAM ça change rien puisque quand on joue, on lance qu'un jeu.

Pas forcément tu peut mettre un lecteur multimédia a coté.
De plus certains ordi n'ont pas plus de 250Mo de ram, donc si ton jeu en prend 100 , il tourneras pas.
Enfin.... performances + GM = Fail

En même temps, ceux qui n'ont que 256 Mo de RAM ne jouent pas ensuite le jeu tournera quand même, Windows switchera automatiquement sur le fichier d'échange.

Enfin je disais ça parce que le probleme avec GM, c'est que ok, le jeux tourneras, mais toutes les images ne seront pas chargés.
C'est ce qui ce passe avec mon entrainement Kanji, qui ne prend pourtant que 15Mo de ram quand je le fait passer sur l'ordi de ma soeur (qui n'est pas une bete de performance mais qui n'est tout de même pas pourris)

onilink_ a écrit:

Enfin je disais ça parce que le probleme avec GM, c'est que ok, le jeux tourneras, mais toutes les images ne seront pas chargés.

C'est pas le manque de mémoire vidéo qui cause ça ?

Aucune iddée en fait. Vu que les images sont chargés dans la ram.
Ma soeur a 512Mo de ram pour info. Pour la carte graphique je sais pas.

Si c'est à cause du manque de VRAM, baisse le nombre de couleurs de l'écran (met le en 16 bpp)

jamais compris comment un jeu qui fait moins de 30 mo peut utilisé 100mo de ram