surface_free "out of memory"

Salut les gens ,j'ai un problème que je ne comprends pas vraiment ,j'ai des surfaces dans mon jeux ,le problèmes c'est qu'entre les rooms j'aimerais bien vider ces surfaces (surfaces de taches de sang ,donc oui ça s'accumule et c'est vraiment pas beau).

Et très bizarrement quand j'utilise surface_free(surfBlood) par exemple ,et ben je me mange un jolie "out of memory" ,qui arrive a tout les coups et d'ailleurs je me tape souvent des "out of memory" ,je tourne sur game maker studio ,et il y a le moteur de lumière smartlight ,qui a l'air de bouffé a mort la consommation de ram ,vu qu'un de mes pc qui fais tourner gta 5 n'assume pas DU TOUT le moteur smartlight ,donc j'ai aussi mis un "moteur de lumière de secours " avec des surfaces qui forcement bug de ouf avec des "out of memory" toutes les deux secondes ,j'ai quand même un bon gros pc ,donc ça deviens *Embêtant* parce que c'est qu'un petit shooter en 2D.

J'ai aussi essayé de mettre des surface_reset_target un peu partout mais rien y fais ,help plz ^^

Je n'y connais rien. Mais tu est absolument certain que OUT_OF_MEMORY arrive quand tu utilise surface_free(..) ?
Ce pourrais être plutôt à cause des surface_create qui sont fait lors de l'ouverture d'une nouvelle room non ? La fin et le début d'une room étant deux événement arrivant au même moment à peu près.

salut ,merci d’essayer de m'aider ,mais c'est sur et certains c'est bien le surface_free ,car j'ai essayer plein de solution différentes et j'en reviens tjrs a la même choses ,soit je suis obligé de laisser les taches de sang sur le sol ,et c'est très moche et en plus ça bouffe pas mal de mémoire ,surtout que j'ai essayer avec trois script différent ,a chaque fois on en reviens au même problème ,et pareil avec d'autres surfaces ,impossible de les vidé ,par contre trop bizarre ,si je fais ALT+ENTRE (réduction de page) les graphismes deviennent un peu sale , mais les taches de sang disparaissent ,des fois je comprends rien a game maker studio ^^'

Et j'ai essayé avec l'objet en persistant ,donc pas de create au debut de la room ,et tjrs pareil .

Smart light est très bien optimisé, c'est toi qui n'a pas cherché a comprendre comment il marche.
Tout d'abord le nombre de surface crées dépend du nombre de lumières en jeu. Il faut donc faire attention, surtout quand certaines lights sont in game mais pas forcement visibles.
Ensuite la taille des surfaces peut être contrôlé via des variables, ce qui permet de diminuer drastiquement la consommation ram et vram. Par contre le rendu est forcement moins précis.

J'ai un ordi qu'a dans les 10 ans et j'arrive a faire tourner des trucs en realtime avec smart light, donc si un ordi qui fait tourner GTA V s'en sort pas, le problème ne viens ni du PC, ni de smart light.


Quand a surface_free ça sert a détruire la surface, pas a la clear.
Je suppose que le out of memory interviens quand tu essayes d'utiliser une surface inexistante.

J'ai jamais utilisé SmartLight, c'est le moteur de Bast il me semble?

Bref, ouai sinon avec les surfaces vaut mieux être très méthodique dans la façon de les gérer.

Pour le coup du resize, c'est normal, les surfaces sont volatiles, si tu veux les conserver il faut les sauvegarder. Sinon, il se peut qu'elles disparaissent et c'est surement ce qui se produit avec tes taches de sang.

Généralement, dans mes projets, je fais un controleur qui va s'occuper de gérer les surfaces:

- Dessiner sur une surface.
- Redonner la main à la surface application.
- Dessiner sur la surface application.

Comme l'a dit oni:

surface_free détruit la surface en mémoire, c'est surement de là que viennent tes erreurs out of memory. (draw_clear pour effacer le contenu d'une surface).

Coucou les gens ,bah écoute onilink ,j'ai chercher ,et encore chercher ,j'ai réussi a rendre le moteur le moins gourmand possible ,en baissant toutes les ombres ,leur fréquence de rafraîchissement ,aux sous minimum ,enlevé même touts les objets avec des ombres ,tout aux minimum avec juste le système jour nuit et lumière (aussi au minimum) ,et ben sur des ordis "moyen" ça tourne a tout juste 30 fps ,c'est acceptable ,mais comparé a mes 180/300 fps sur mon pc ça reste faible.

Je suis presque sur que finalement c'est le processeur ,j'ai fais mes petits test ,et du coup je penses que c'est bien le processeur ,le moteur sans rien derrière sur le même ordi (a 30 fps) ça tourne a 45 fps sous le même réglage ce qui reste léger (et j'ai tester d'autre ordi "moyen" et pareil) ,et vu tout ce que j'ai mis dans le jeu je penses que c'est logique ET OUI je tourne sur game maker studio,et j'ai lu a plusieurs endroit que sur game maker studio ça bouffais pas mal ,et je critique pas le travail de blitz ,c'est un SUPER moteur ,mais juste je penses qu'il est pas super opti pour game maker studio ou alors je peut aussi me tromper et y a une solution miracle ,mais j'ai déjà regarder tout le code en large et en travers et je vois pas ce que je pourrais baisser de plus et après oui je suis pas pro ,je ne saurais pas changer le code entier du script pour l'opti ,enfin voila ,j'ai je penses fais tout ce que je pouvais et c'est déjà pas mal (avec un petit compensateur pour augmenter la vitesse des objets selon les fps ça parais presque bon ^^)

Et pour les surface_texture ,ça m'as rendu fou ,bug inexplicable ,j'ai pas trop compris ce coup ci ,donc je fais ça avec des particles et des sprites ,ont ce prends plus la tête mais en tout cas j'ai plu mes bugs ^^'

Et par contre Rem_101 non mes surfaces je n'arrivais pas a les clear entre les zones ,justement je ne voulais pas les conserver , je veux qu'a chaque room je les clear (tache de sang ,empreinte de pas) mais soit ça faisais crasher le jeux direct ,ou ramer de fou ,alors que je faisais bien comme dans les tuto ,soit ça faisais rien ,et les taches de sang s'accumulais ,et question il faut forcément resize les surfaces a chaque room ? je réessayerais un peu plus tard ,merci pour vos réponses les gens !

GM:S est nettement plus performant que ses prédécesseurs. Mais ça reste incroyablement plus lent que du natif, et Smartlight est impressionnant pour pouvoir tourner aussi bien sur un langage clairement lent.