Recherche programmeur [système d'optimisation act/desactiv

Bonjours tout le monde !
Je recherche quelqu'un qui réaliserait un système permettant d'optimiser mon jeu de plateforme.
https://cbna.forumactif.com/vos-projets-f11/projet-mario-second-topique-big-news-du-22-juin-ok-t7468.htm
Ce système serait open source pour qui veut l’utiliser. Remerciements non obligatoire, juste souhaités.

Les faits : Sur GameMaker, dans une room, plus on met d'objet, même si ce n'est pas dans le cadre de ce que l'on voit, ça consomme des performances. (même si l'on désactive tout puis réactive ce qui est dans le cadre de la vue car dans ce cas, GM est obligé de regarder et de comparer toutes les positions x et y par rapport au cadre de la vue).

L'idée : lors du premier step de la room, supprimer toutes les instances puis les recréer de façon à ce que leur ID soient en ordre croisant si l'on regarde de la gauche vers la droite.

Donc les ID faibles seraient à gauche et les ID de droite seraient de plus en plus élevées.


Qu'elle est l'intérêt ?

Au lieu de se servir de la fonction interne de GM pour activer ou désactiver une région, il suffirait de connaitre l'ID la plus faible et l'ID la plus élevée [grâce à un objet contrôleur possédant ce genre d’information dans un tableau ordonné astucieusement... Plus besoin de regarder toutes les instances existantes (activées et désactivées). Donc en théorie, on pourrait avoir une infinité d'instance hors du cadre de la room, ça ne couterait absolument rien en terme de performance pompées inutilement.


Contrainte : Se faire le projet en entier contenant absolument tout ce qu'il faut, sans cela, il servirait à rien. Il faut donc quelqu'un de solide, de fiable, d'expérimenter. Débutant, merci, mais passez votre chemin ^^
Les fonctions à manier n'étant pas compliquées, celui qui fait ce projet devrait se débrouiller seul. N'espérez pas finir ceci si vous êtes sur que vous aurez des questions à poser sans cesse sur la programmation.

Les candidats :
Moi : Déjà saturé par le boulo sous GM, je préfère déléguer cette tâche à quelqu'un d'autre.
TheDarkTiger : Déjà bien exploité par moi, donc temps qu'il n'a pas finis la "Néomatrice de TheDarkTiger" et plusieurs autres choses... Bref. Pas lui. [quoique]
M@d_Doc : Idem. J'attends son système de lumière. Bref. Pas lui. [quoique]
Edi9999 : Idem, avec le "Théâtre flashy d'Edi9999". Bref. Pas lui. [quoique]


Donc il va falloir que j'avertisse tout le monde et que je me décide à qui confier ce projet. Je n'interdis à personne de réaliser ce système, juste que si vous le commencez avant que je vous en ai donné le feu vert, il se peux que de mon coté, je préfère accorder ma confiance en quelqu'un d'autre et dans ce cas, ce serait dommage que plusieurs personnes du CBNA réalisent le même projet.


Bon, dans le cas ou personne ne répondrait à mon appelle, sois j'attendrais de finir d'autre système avant d'essayer de le faire, sois je prierais pour que quelqu'un se libère et accepte ce projet.


Les problèmes : les objets qui se déplacent devront avoir une ID plus élevée que l’obj de type fixe ayant l’ID la plus élevé,e afin de ne jamais être désactivés par ce système. La gestion de leur désactivation se fait par eux même, mais en ce qui concerne leur activation... Hum... Il faudra mettre au point un système dynamique qui gère cela. Du genre, dans le step de ces objets mobiles, on met une fonction qui les désactivent et les mets à la queue dans un tableau dans un objet contrôleur qui serait toujours actif... Bref, seul ce point me semble assez difficile à gérer, et il me/nous reste à réfléchir sur ce point.


Je ne suis pas totalement sûr que ce système soit réellement réalisable du problème cité précédemment au sujet des objets mobiles.

Je sais que mon explication ci-dessus est peu être un peu rapide… Mais je peux approfondir un point si vous le souhaitez.


A savoir que dans mon projet, toute les tuiles peuvent être facilement transformées en objet automatiquement [et passer en 3D par la même occasion [merci au Tigre du CBNA]]. Donc qui dit objet illimité, dit aussi tuile illimité pour moi.


Qui est intéressé ?

Bon et bien, je vais encore patienter un peu et sinon, je vais tenter une idée beaucoup plus simple qui pourrait permettre d'obtenir d'excellent résultat extrêmement simplement. Mais cette seconde idée, bien que très simple ne pourra pas égaler la technique expliquer ci dessus (et il va falloir que je regarde les performances pour savoir si le gain est vraiment à la hauteur de mes espérances).

mais si ça se trouve faire le système que tu as expliqué au-dessus consomme autant de performances que faire un simple instance_deactivate :gniah:

(enfin bon ça m'étonnerait mais y'a quand même pas mal de trucs à checker)

Moi j'ai pas vraiment le temps en ce moment, mais je m'intéresses pas mal a cette idée. J'ai réfléchi au probleme que tu cites. Il y aura en fait plusieurs différentes possibilités d'activer des instances. On pourra activer les instances en les rendant visibles, et en les laissant actionner tous les events, et on pourra aussi activer les instances sans que ils prennent de la mémoire en testant a chaque step tous les évenements, mais il y aura un objet controlleur, qui controllera juste les collisions pour tous les objets amovibles. Et donc, cela n'utilisera que tres peu d'espace puisque juste la position des objets et le spr_ind sera enregistré.

nicoulas a écrit:

mais si ça se trouve faire le système que tu as expliqué au-dessus consomme autant de performances que faire un simple instance_deactivate :gniah:

(enfin bon ça m'étonnerait mais y'a quand même pas mal de trucs à checker)

Justement, il n'y a que forcément moins de chose à checker. Et celon la philosophie du truc, il pourrait même n'y avoir rien à checker.

Si l'on se sert d'un tableau pour indexer la première et la dernière IA de tuile (ou d'obj fixe) par "1024" en x.


Et pour répondre à Edi9999 : Je n'ai pas saisi ton astuce, mais quand tu auras du temps libre, si ça te dit, on en rediscutera pour savoir quel algorythm on essait.

Deplus, j'ai tet trouvé le moyen d'optimiser grandement l'activation/désactivation des objets de façon très simple. Donc si ça marche vraiment bien, le plus urgent serait alors de s'occuper d'optimiser les masses de tuiles (et pour cela, je connais déjà la philosophie parfaite).

On en reparlera plus tard. Pour l'instant, occupes toi déjà du théâtre ^^

Le problème en soi est qu'il faut enregistrer toutes les variables d'un objet quand on le supprime. Cela risque de prendre pas mal de temps et donc au final je ne sais pas trop si cela serait tellement plus rapide.

Cependant si il ne s'agit que d'éléments de décor on ne doit qu'enregistrer les variables x, y donc tecntiquement ce serait possible.

Donc je pense que la fonction instance_deactivate risque d'être quand même plus rapide.

Edit : je crois que j'ai mal compris..

Tu voudrais créer les instances avec la progression du perso dans la room ?

Non, on ne les recrées juste qu'au début une fois.
Ensuite, on active ce qu'il faut et on désactive tout






Pour faire simple pour l'optimisation d'act/desact d'objets disons :
- supprimer toutes les instances fixes
- les recréer de gauche à droite (donc les ID seront rangés)

- avoir un tableau qui contient l'information de découpe des IA [de 1024 en x à 1024 en x] de telle façon qu'il n'y a rien à checker... On rentre un x et toutes les ID compris de façon continuent entre ... et ... sont activées. Rien a checker du tout car dans le tableau, on sait que de ... à ... il y a les bons objets.

Donc, dans ce tableau, deux nombres situés dans des cases colées contiendraient l'IA la plus petite et la plus grande



Exemple du contenu du tableau :
10000-10010-10500-11042-12050


traduction :
entre 10000 et 10010 il y a toutes les instances compris entre la position x=0 et x=1024.

entre 10010 et 10500 il y a toutes les instances compris entre la position x=1024 et x=2048.

entre 10500 et 11042 il y a toutes les instances compris entre la position x=3072 et x=4096.

ect...


Compris ?

A relire plusieurs foi pour comprendre ^^

Oui je comprend bien mais tes IA elles bougent et certaines risquent de se retrouver dans une autre case que celle dans laquelle elles étaient donc tu risques de desactiver des IAS visibles ect..

Cependant alors pas besoin de faire un classement des ias et blablabla

Un petit ds_map contenant l'id de l'ia et la case dans laquelle celle-ci est compris suffirait.

Moi je veux le faire, je veux le faire !!
Comment ca je sort? Mais... Mais... mais...
Bon :'( bah je sort alors.

lol Rem

master47 a écrit:

Oui je comprend bien mais tes IA elles bougent et certaines risquent de se retrouver dans une autre case que celle dans laquelle elles étaient donc tu risques de desactiver des IAS visibles ect..

Cependant alors pas besoin de faire un classement des ias et blablabla

Un petit ds_map contenant l'id de l'ia et la case dans laquelle celle-ci est compris suffirait.

On ne s'occupe que des instances fixes j'ai annoncé.
Les instances mobiles, on s'en occupe à coté.

Et je ne sais pas ce que c'est qu'un ds_map. C'est un plan à deux écrans ? Je sors :gniah:


Je ne m'y connais pas du tout en jeu de fonction. Coté vitesse, je ne sais pas trop ce que ça vaut et quel en est l'interret.

Je pensais que d'après l'algo , un banal tableau suffisait

un ds_map c'est une double liste, c'est à dire une liste de clés et de leurs valeurs, c'est très pratique pour des classements de scores et tout

Ha ok! Mais je pense qu'un système par clef, ce serait beaucoup plus lent qu'utiliser un simple tableau à une dimension

Bah pas du tout, ce n'est pas plus lent que d'utiliser un ds_list donc faut pas s'inquièter pour ca

oui mais un ds_list ca prend moins de place qu'un ds_map, parce que si tes noms de cles prennent deja la moitie de la place.

La différence est minime.

Puis on pourrait essayer de faire un ds_map en ds_list de noms de variables dont on obtiendrait la valeur par variable_local_get() mais je ne suis pas certain que cela changera grand chose..

Loooool! mettez vous d'accord! Les DS_list ou map, c'est pas ma tasse de thée. Je continue à pensé qu'il n'y a pas plus rapide qu'un tableau à une ou deux dimensions

disons DS_MAP alors

Non un systeme en ds_list.

Me voila bien avancé
Il va falloir que je trouve quelqu'un pour vous trancher

j'aurais peut être une solution...
1)Tu met tes maps en externes pour pouvoir les manipuler facilement :
c'est à dire il faut un fichier contenant les instances et leur position de départ.

2)Tu prend tout ça, tu te contentes de les classer dans l'ordre voulu

3)tu utilise ce fichier pour recréer les objets de la room. Au final, ça les crées dans le bon sens et SURTOUT, avec une ID croissante!

c'est tout con, trouve juste quelqu'un pour le faire :p

EDIT :
pour la création du fichier contenant la map tu met dans le create de la room :

Code:

a=file_text_open_write("level1")
with(all)
{
file_text_write_string(other.a,string(x)+"|"+string(y)+"|"+string(object_index))
file_text_writeln(other.a)
}
file_text_close(a)

au final, tu as un fichier du style :
32|6|10034
12|87|10082

x|y|object_index

etc. etc.

OUVRIR dans excel :
pour cela, essaye d'ouvrir tont fichier (sans etension)= avec excel. Il demande confirmation, puis après tu dis qu'il est délimité (pas de largeur fixe) puis OK, puis tu met le caractère séparateur sur autre, et tu choisit '|'
puis ok, et après t'as plus qu'à reclasser tout ça et c'est gagné!

Ouais c pas terrible ca..
Le plus simple serait de faire un ini au lei d'un fichier avec des séparateurs

Sinon, c'est une bonne idée

Non, je me joins a Mad_Doc, un fichier est beaucoup plus parametrable qu'un pauvre ini de m****. On en a marre des .ini !

lol la guerre de l'extension à commencé
ben... disons que mon système... on se tape du boulot une fois et c'est réglé... l'autre, l'organisation est faite à chaque fois, non?

edi9999 a écrit:

Non, je me joins a Mad_Doc, un fichier est beaucoup plus parametrable qu'un pauvre ini de m****. On en a marre des .ini !

XD

ben je m'y connais pas trop désolé

M@d_Doc a écrit:

j'aurais peut être une solution...
1)Tu met tes maps en externes pour pouvoir les manipuler facilement :
c'est à dire il faut un fichier contenant les instances et leur position de départ.

2)Tu prend tout ça, tu te contentes de les classer dans l'ordre voulu

3)tu utilise ce fichier pour recréer les objets de la room. Au final, ça les crées dans le bon sens et SURTOUT, avec une ID croissante!

c'est tout con, trouve juste quelqu'un pour le faire :p

EDIT :
pour la création du fichier contenant la map tu met dans le create de la room :

Code:

a=file_text_open_write("level1")
with(all)
{
file_text_write_string(other.a,string(x)+"|"+string(y)+"|"+string(object_index))
file_text_writeln(other.a)
}
file_text_close(a)

au final, tu as un fichier du style :
32|6|10034
12|87|10082

x|y|object_index

etc. etc.

OUVRIR dans excel :
pour cela, essaye d'ouvrir tont fichier (sans etension)= avec excel. Il demande confirmation, puis après tu dis qu'il est délimité (pas de largeur fixe) puis OK, puis tu met le caractère séparateur sur autre, et tu choisit '|'
puis ok, et après t'as plus qu'à reclasser tout ça et c'est gagné!

C'est pas mal du tout, mais à ce moment, ce serait mieux de créer le fichier externe à chaque foi [à chaque room start] et de le reclasser tout de suite puis de recharger.

Mais avant de trop vous prendre la tête la dessus, laissez moi le temps de tester une autre idée qui m'a l'air peut être suffisante coté optimisation.

Je vous referais signe quand il le faudra, pour vous tenir informer.

edi9999 a écrit:

Non, je me joins a Mad_Doc, un fichier est beaucoup plus parametrable qu'un pauvre ini de m****. On en a marre des .ini !

Ouais mais ya pas de string split sous gm, tu dois le faire toi-même et c'est horriblement lent !!!!!!!!!!!!!!!!!!!!!!!!!

Bon mettons nous d'accord : faisons une DLL pour le XML et ce sera bien mieux

tout à fait

ok pour la dll, mais bon le xml,c'est pas un super systeme, autant un inventer un plus specialise.