eviter la confusion des actifs

bonjour a tous

dans le mfa joint, qurlqu'un aurait il la solution pour eviter la confusion des actif quand on le compare avec "lui meme" (en doublon)

j'ai une solution qui fonctionne en creant un actif 2 qui est en permanence a la meme mosition que son actif 1 correspondant et en comparant actif 1 a actif 2 mais ça fait créer le double d'actif...

dans l'exemple joint, activer / desactiver la ligne "dessous" ou "dessus" pour bien comprendre ce que je veux dire.

Merci !!!

Salut !

Je pense que pour arrivé au résultat souhaité, il faudra tout revoir à 0.

Avant tout, peux-tu me confirmer ceci:
Tu souhaite faire en sorte que des actifs tombent à la verticale, mais s'arrête si ce dernier touche un autre actif ?
J'imagine aussi, que tu ne souhaite pas utilisé la physique proposé par Clickteam ?
Et finalement le tout avec comme préférence que tu ne sois pas obligé de créer des actifs en trop.

Sinon voilà ce que j'ai pu faire:

hello

en fait c'est pas vraiment ce que je veux faire, le faire s'arreter est simple, ce que je veux c'est pouvoir cibler un des deux actif qui rentre en collision precisement , mon exemple est juste un exemple basique pour resoudre mon probleme plus complexe dans mon jeu

pour faire simple

si "actif 1" est en collision au dessus de "actif 1"

"actif 1" : echelle a 0.5

MAIS que seul le deuxieme soit concerné

Okay...

Oui donc c'est bien plus complexe. J'essayais bêtement de résoudre ton test :/.

Personnellement; j'arrive à faire:
Si "Actif" (A) est dessus de "Actif" (B),
alors "Actif" (A): échelle= 0.5.

Ca marche sans d'actif en plus, mais ça dépend ce que tu souhaite faire réellement. Et le problème c'est que pour avoir "Actif" (B), ça risque d'être encore plus dur.
Mais tout dépendra si ton objectif c'est juste que ça tombe ou que sa peux retomber, si il peut y avoir d'autres effets...

Je pense que t'es un peu obligé d'utilisé tout le temps un deuxième actif, pour faire ça plus simplement.

Salut salut,

Tu peux peut être donner des valeurs différentes ou voire avec la vitesse de l’objet.

Comme ça ?

@Patrice,
Je pense que c'est ce qu'il faisait, Mais il souhaite éviter:
"j'ai une solution qui fonctionne en creant un actif 2 [...], mais ça fait créer le double d'actif..."

Ok :)

@Patrice, J'ai fais pareille, mais sans boucle. J'ai cru remarquer qu'il y avait des problèmes quand le nombre est trop grand.

merci pour votre aide

en fait je ne cherche pas un combine qui fonctionne pour mon exemple précis mais plutot pour un cas general de confusion d'actifs mais effectivement je pense qu'il faut plutot trouver une combine pour mon cas a moi car il ne doit pas y avoir de possibilité autrement.

En fait tout marche bien sur pc (j'ai trouvé une solution)mais sur android la multiplication d'actif fais ramer.

en realité j'ai 100 actifs,chacun a son detecteur dessous, ça fait deja 200 actifs... donc pour android, je fais une boucle et je positionne l'unique detecteur sous chaque actif rouge consecituvement  et je test si y'a un obstacle dessous ça me fait que 100 + 1 actif

les carré rouge doivent pouvoir tomber vers la droite si il sont au dessus d'un autre carré rouge, d'ou le besoin de tester "detecteur au dessus d'un autre carré rouge" mais de recibler dans la foulé le carré du dessus alors qu'en ayant testé grace a un detectuer la collision fusion prends par defaut celui du dessous. 

je ferais un exemple plus precis ce soir

Et si tu faisais l’inverse ? Tu mes le détecteur au dessus pour tester si l’actif est percuté par un autre.

oui je viens d'y pensé, mais de toute facon il faut un detecteur dessous pour verifier si il peuvent tomber, cela dit peut etre qu'en faisant la meme chose (boucle avec un seul detecteur dessus )... a creuser ! merci !

C'est sur que pour 100 actifs, dire: Faire une boucle pour chacun.
Sans compter que t'en fais plusieurs à la fois, aie pour la performance !

Une méthode "générale" est plus complexe à mettre en place, pendant ou après ça confection.
Donc oui pense plus à quelque chose pour seulement ton projet.

Sinon, essaye de ne pas faire de boucle, surtout si t'as 100 actifs à la fois, et que tu les fassent à la suite.
Et pour qu'on puisse mieux t'aider dis-nous comment ta physique doit fonctionner précisément. Pour tout de suite penser à un résultat.

Sinon bonne chance.

concernant la performance, je ne vois aucune difference pour pc evidemment, mais ce qui est certain c'est que sur android c'est l'affichage de pleins d'actifs qui pose probleme, afficher 100 actifs de 32x32 est enormement plus gourmand qu'afficher un seul de 2000 x 2000. j'ai un jeu ou j'utilise 3 actifs de 6000 x 6000 et ça passe sans probleme sur un vieux telephone alors que 200 de 32*32 et ça rame...

En fait ce qu'il cherche à faire sur sa ligne 9 c'est de cibler le carré rouge correspondant à son capteur bleu pour le rétrécir sauf qu'il peut pas car il a "scopé" uniquement les carrés rouges en superposition avec son capteur (dans son exemple, le carré rouge du bas).

Du coup la seule solution à laquelle je pense ici, c'est de le faire en 2 temps, par exemple en mettant la variable B du capteur à 1 et de lancer une autre boucle pour chaque capteur. Si B==1 alors tu cibles ton carré rouge via ta variable A comme tu le fais et tu le rétrécie en remettant B à 0.

Après ouais ça fait encore une boucle...

Une petite astuce pour soulager les perfs quand on fait des boucles à laquelle on pense pas trop, serait de ne pas lancer tes boucles à chaque frame mais seulement je sais pas une frame sur 5 ? Tu perds un peu en réactivité mais tu n'as peut-être pas forcément besoin d'avoir autant de réactivité dans ton gameplay.

merci tazador, effectivement je lance les boucles a chaque frame mais je met une contition en premier qui ne cible que certain carré concerné, cela dit la boucle se lance effectivement a chaque fps 

voila la réalité de mon probleme dans le mfa joint.

il n'y a qu'un seul detecteur qui pointe sur chaque carré

la solution existe mais j'aimerais me passer du doublage de chaque carré

Ah oui ok le truc c'est que dans ta ligne 12, quand tu fais ton test de superposition entre ton objet "détecteur sous pierre" et ton "groupe obstacle", vu que "rocher" est un "groupe obstacle", on dirait qu'il ne sait plus quel objet "rocher" prendre pour fixer la variable "droite" à 16, surtout que tu fais ça dans une boucle qui itère sur toutes les instances de "rocher". Petit casse-tête d'object scoping... Je n'ai pas encore de solution, mais je vois bien le problème...

Sinon par curiosité, tout ça c'est pour faire glisser tes jewels quand y'aura de la place en dessous ? :D

oui voila c'est pour ça, et effectivement c'est un probleme de scoping, resolu par la methode que j'utilise mais qui genere le double d'actifs (chiant pour android)

Si tu n'affiche pas ton deuxième actif logiquement il devrais moins ralentir l'app.

effectivement j'e n'affiche pas tout ce qui n'est pas necessaire, d'ailleur une methode ultra simple pour accelerer enormement  c'est de rendre invisible tout les actifs qui ne sont pas dans le cade de l'ecran (par une methode ou une autre) et ne les rendre visible que si il y sont,c'est effectivement tres efficace, cela dit ce ne l'est pas suffisement dans mon cas, mais en optimisant toute les boucles possibles grace aux evenements enfants / parents j'ai reussi a gagner 20 fps! c'est énorme!