Parlons optimisation ...

Et comment tu fait quand tu fait de la programmation pour gba ? Faut penser aux anciens systèmes quoi !

Moi franchement la ram j'évite de trop l'utiliser, déjà c'est un défis , puis aussi mon deuxième pc n'as plus qu'un Go de ram, donc j'économise x)

lol ouai ça dépend toujours de sur quoi on programme, c'est vrai. Mais même avec ton pc 1Go de ram, 1Go c'est énorme. et je dit pas que il faut allouer pour le plaisir justement qu'il faut allouer en prévoyant ce qu'il va ce passer.

onilink a raison : si tu veux adapter sur un autre systeme (la GBA convient parfaitement), vaut mieux faire gaffe a la ram ! que ce soit en 3D ou en 2D.
je suis sur que vous avez deja réussi a faire ramé votre PC en 2D (avec GM OU le C++)

Oui, j'ai développé un réel talent pour ça.

Suffi de jouer a un jeu indi pour faire ramer son pc avec un jeu 2D, pas besoin de chercher loin.
Le flash, le java, le gml ca bouffe tellement de perf pour un rien.
en c++ même avec une boucle infinie ca fait moins rammer le pc que un jeu flash de *****

lol wargamer, mais c'est bien vrai, c'est pour ça : METTEZ VOUS AU C++ !

Bast a écrit:

Oui, j'ai développé un réel talent pour ça.

Le petit scarabée que je suis arrive sans soucis à faire plier un dualcore2.2Ghz avec bonne carte graphique juste avec un jeu Mario alors s'il vous plait, respect aussi


Vivicool a bien raison, sauf si vous avez des tonnes de temps à perdre et que vous êtes maniaco dépressif, les ram ne vous feront pas gagner la moindre perfs sur les images par secondes constantes. Après, si vous avez l'intention de présenter vos codes pour trouver du boulo, ou que vous êtes vraiment un pro, pourquoi pas faire un peu attention tout de même ^^

Je pense qui si, faut faire attention a pas bouffer trop de ram car faut penser aux gens qui on de vieux pc, et un jeu 2D s'il vous plait devrait tourner sur n'importe quel pc pas trop trop vieux. Après pour moi un jeu 2D qui bouffe plus de 100Mo de ram c'est qu'y a un gros problème de gestion de la mémoire, ou que le jeu doit avoir une qualité vraiment exceptionnelle !
Après libre a vous de faire ce que vous voulez, mais n'oubliez pas que plein de personne on encore de vieux pc qui feraient bugger GM s'il prend trop de ram (bug de textures).

Quand j'aurai fini mon projet j'aimerais bien le filer à un certain onilink ou autre pour de l'opti

C'est pas que j'aie la flemme, c'est que j'ai sûrement pas assez de bonnes idées...

Moi y a pas de problèmes en tout cas

Derp, je fait que lancer mon jeu et il prend 45mo en partant(c'est que le menu)

C'est parce que GM décompresse toutes les ressources de l'exe et les mets dans la ram.
D'ou l'importance des ressources externes.

mouai je vois, je pensait pas que mes sprite prendraient autant de place, mais bon comme elles sont utilisé tout le temps ca dérange pas trop
par contre chaud comment je charge 500ko d'image et que GM monte de 13mo de ram

En fait pour savoir combien une image prend dans la ram en octets, le poid théorique est

taille = longeur*largeur*4 octets
(format 32bits rgba)

Une image de 640 par 480 prend donc 1228800 octets, soit 1,2Mo
Et encore des fois j'ai l'impression que GM en prend plus que nécessaire :/

Edit : ouai, ça en prend 2x plus...

Aussi un truc que j'ai remarqué dans GM , utiliser des sprite sheet ou des sprites multiframes donne des résultats différents

Sprite sheet au lieux de sprite multi frames :
(+) Prend un peu moins de ram (négligeable).
(+) Éditable plus légère, donc exe + légère
(+) Chargement moins long pour éditer le sprite
( - ) Chargement plus long au lancement de l'exe

Ram et poid de l'éditable :

Exe vide : ~ 11 460 Ko
Exe + sprite 64*64 avec 225 frames ~ 19 850 Ko de Ram et 6.7 Ko le gm6
Exe + sprite (64*15)² soit 1600*1600 ~ 19 450 ko de Ram et 20.2 Ko le gm6

Poids théorique de l'exe vide 11 460 + 3600 = 15 060 Ko de RAM

Donc si vous utilisez des sprites multiframe avec des frames de petites taille, préférez un sprite sheet (il ne faut pas que l'assemblage donne un sprite trop grand ou on perd les avantages) , sinon restez au multiframe.

Maintenant quelque chose d'étrange , le poids obtenu et le poids théorique que doit prendre un sprite/background dans la ram n'est pas égale.

Les ressources graphiques de GM etant codé au format rgba , donc 32bits, la taille d'une de ces ressources devrait prendre largeur*hauteur*4 octets.
Hors ce n'est pas le cas...

Tests d'une ressource graphique :

Largeur	Hauteur	Poids Théorique (Ko)	Poids Réel (Ko)
640	480	1200	2500
1000	1000	3900	8700
2000	2000	15625	35240
1024	1024	4096	9100

D'après ces tests effectués sous GM6 on en déduit que GM prend un peu plus de deux fois de Ram qu'il ne devrait en prendre ....

onilink_ a écrit:

Les ressources graphiques de GM etant codé au format rgba , donc 32bits, la taille d'une de ces ressources devrait prendre largeur*hauteur*32.
Hors ce n'est pas le cas...

*4, c'est ce que t'as utilisé dans tes calculs et ce que t'avais dit quelques posts plus haut, t'as fait un mélange entre le nombre de bits et le coefficient

lol ouai bien vu, je corrige ça. Enfin c'etait pas vraiment faux mais j'aurais du mettre bits quoi :p

Gm serait assez con pour charger l'image puis un array list de chaque pixel pour y avoir accès?

lol aucune idée, mais c'est peut être un truc pour les collisions. Faut demander a mark x)

Wargamer a écrit:

Gm serait assez con pour charger l'image puis un array list de chaque pixel pour y avoir accès?

Gm est ?

T'as raison oni, un sprite pour l'image un tableau de couleur de int de ce qui constitu l'image
ensuite avec un algo de collision tu aditionne les couleurs pour savoir si ya collision ou pas(et comme c'est GM il va pas prendre que 1 byte pour l'alpha, ca serait trop bien)
Enfin, en XNA c'est ce que j'utilise

Je me copie colle du topique de Mario de jbg77, pour une optimisation très très facile, et vraiment efficace qui est très facilement applicable dans tout type de jeu :

Spoiler:

Très simple, et de souvenir, très efficace.
Surtout que GM8 utilise le png, donc stocker un motif répéter, ça ne pompe quasiment rien du tout [sauf quand il est décompresser dans la Vram].

Pas bête, je me souviens avoir fait ca pour mon jeu en C# pour créer le background sinon ca pompais énormément(avant de connaitre les texture brush qui copie automatiquement le psrite pour remplire une surface)

Euuuuh, j'ai rien compris à l'optimisation de Topaze.

Tu agrandis des textures en *2 ? Tu poses 500000 tiles ?

Je n'agrandi pas les texture, heu, plus ou moins. Au lieu d'avoir une tuile de 32x32 poser par exemple 100 fois dans ma room, je vais créer une "background tiled" où je pourrait sélectionner par exemple la même tile, mais plusieurs foi. Comme ça j'en pose moins (moi de 40 % au minimum généralement). Effet et résultat garanti.

Tu as compris cette foi Segiko ? j'avoue que ce n'est pas simple pour moi à exprimer XD sorry ^^

sinon je me suis toujours demander
quand on sélectionne un tile.
il me semble qu'on peut appuyer sur shift et sélectionner plusieurs carreau, et les poser donc par plusieurs blocs (1*1, 1*2, 2*1 , 16*2 par exemple)
Quand on les supprime, sa supprime bien tous les carreaux supprimer
GM ne stockerais pas non plus le nombre de carreaux pris en vertical et horizontal ?
Ainsi, il serais possible de faire la même optimisation que tu parle, sans devoir faire un seconde tileset, pouvoir ainsi profiter des petites tiles et des grandes.

Enfin, c'est juste des supposition

Si arthuro, ça marche aussi comme ça ^^

Arthuro, ce que tu dis, c'est ce que j'ai dis de faire, juste que je n'ai pas très bien expliqué ^^.
Perso, j'ai par exemple changer certaines tileset pour avoir des répétions de textures de mozaic en 4x4. Comme ça je peux poser des 4x1, 1x4, 2x3 et ce que je veux pour économiser le nombre de poses. Car c'est ce nombres de pose qu'il faut chercher à limité avec mon optimisation. Le nombre coût vraiment. C'est aussi pour cela que j'ai parler avant de l'optimisation ou les blocs solides se cannibalisent et s étirent. c'est pour économiser du nombre. Ces deux techniques permettent de gagner très gros sur le nombre d'image par seconde et donc sur les perfs constantes du jeux.

Citation :

Arthuro, ce que tu dis, c'est ce que j'ai dis de faire, juste que je n'ai pas très bien expliqué ^^.

ha d'accord ^^