PolySnd - Page 9

Bon j'ai corrigé un bug mais il m'en reste encore beaucoups....

Je te signale que la source est très difficile à lire (chose que Vertyos n'a pas remarquée parce que les siennes sont pire ).

Je ne trouve pas que la source soit longue, mais par contre elle est assez indigeste.

Ça fait depuis la 2eme version de gbs que je n'écrit plus des horreurs comme ça

Pour la source, il faut me comprendre un peu, ce n'est pas facile de faire la gestion de collision sans des conditions de cette longeur là. En effet je trouve que c'est la méthode la plus rapide et la plus puissante mais il y a toujours quelques erreur dedans.

Pour la source Ball[i] représente la balle qui a provoquée la collision avec la Ball[i2] considérée comme statique.



Le rectangle rouge représente la Ball[i2] considérée comme statique.
Le rectangle bleu repréente la Ball[i] considérée comme mobile.

Les rectangle vert représente des zones de collision si la zone violet de la Ball[i] se trouve dans un rectangle vert alors collision et en fonction de l'endroit de collision les 2 balles se repousse.

A savoir que le rectangle violet tourne au centre de la Ball[i] en fonction du côtée de la BAll[i2] ou se trouve Ball[i].

Cette algo est très puissant puisque qu'il permet de gérer tout les cas de collisions et tout les angles de Ball mais le mien comporte quelque erreur de l'ordre de 1 pixel environ.

La source est assez difficile a comprendre sans ce schéma mais j'avoue quelle est indigeste mais comme je l'ai déjà dit c'est la seule à être précis et rapide à gérer.

Pourquoi tu utilises des rectangles alors que les balles sont ronde ?
Ton algo fera que tu n'auras que 4 réactions différentes, non ?

Mais comment veut-tu que je face un algo en prenant les balles comme ronde, ça complique les choses pour un résultat identique, je doit faire une condition pour chaque point de la balle.
Oui en effet on a 4 possibilitée de collision mais en fonction des positions des balles on a 16 réactions différente ce qui est enorme.

Quelles méthode collision semblerait vous le mieux?

Mais avec ton algo, est-ce que tu peux gérer des directions quelconques, ou bien il ne permet d'utiliser que 8 directions ?

Et au fait, tu n'es pas obligé de faire un algo pour chaque "point" de la balle si tu veux un algo qui gère des balles et non des rectangles.

Je peux gérer des directions quelconque en fonction des déplacement des balles avant collision, mais là je sens que je vais faire un autre algo car je croye avoir compris mon erreur, en effet les balles se dirige avec un xdir et ydir mais dans mes conditions certaine ne passe pas car il suffit qu'il y est un pas de 2 lors du déplacement des balles pour que ça foire, mais je sais comment corriger ce PB et je vais mis mettre.

C'est plus complexe que je ne le pensé mais ce n'est pas impossible, comme on peut le voir sur le screen, les collisions ne sont pas précise et donc je vais corriger tout ça.

Je sais bien mais j'ai regardé partout sur internet et les algo de collisions sont toujours fait avec des carrés ou rectangle car je pense que mes balles seront variable en taille et je préfére faire du général mais bon les collision seront moins précise mais je ne pense pas que ça se verras.

J'ai mieux : Tu regardes si la différence des abscisses des balles ou la différence de leurs ordonnées sont inférieures au rayon de tes balles. Si c'est le cas, il y a un risque de collision. Tu calcules alors la vraie distance qui sépare les balles, si cette distance est inférieure au rayon des balles, il y a effectivement collision.
Pourquoi ne pas calculer la distance tout de suite ? A mon avis ce serait moins rapide, puisque ça impliquerait deux multiplications. Tandis que de comparer les différences d'abscisses et d'ordonnées ne prend aucune multiplication, seulement des soutractions et comparaisons. Donc de cette façon, tu passes les cas où les balles sont trop éloignées, puis quand on arrive dans une zone trop proche, tu calcules la distance précise.

Bon, pour la réponse à la collision, c'est un petit peu plus mathématique. Il faut que tu imagines qu'il y ait une ligne qui relie les deux balles entre elles. Tu prend la médiatrice de ce segment et tu t'en sers d'axe pour faire rebondir tes balles (ça paraît peut-être simple, mais c'est en fait assez compliqué de trouver les calculs qui te permettront de faire ça).
Avec ça, ton code ne prendra que quelques courtes lignes et sera précis.

Ton idée n'est pas mal du tout mais je pense à un truc que tu as mentionné, si je calculé directement la distance entre le le centre de la balle1 et de la balle2 et que je conclus que cette distance est égale au rayon de la balle alors il y a collision puis après je détermine la position de la balle1 par rapport à la balle2 et je peux donc effectuer un angle de déplacement?

A ton avis cette méthode pourrais fonctionner?

Pour résumer ta méthode tu vérifie si la balle1 se trouve autour de balle2 à une distance du rayon de balle, si c'est le cas tu calcule précisément cette distance et si inférieur au rayon alors collision. En effet la condition de début peut être enlevée.

Merci beaucoup, je vais mis mettre.

Attention, il ne faut pas comparer la distance entre les 2 centres avec le rayon d'une seule balle, mais avec la somme des 2 rayons pour voir s'il y a collision.

geogeo a écrit :
Ton idée n'est pas mal du tout mais je pense à un truc que tu as mentionné, si je calculé directement la distance entre le le centre de la balle1 et de la balle2 et que je conclus que cette distance est égale au rayon de la balle alors il y a collision puis après je détermine la position de la balle1 par rapport à la balle2 et je peux donc effectuer un angle de déplacement?
A ton avis cette méthode pourrais fonctionner?

Ben je ne vois pas trop comment tu calcules la réponse à la collision, là...
Et sinon, c'est plus rapide à mon avis de comparer simplement les différences d'abscisses et d'ordonnées avant de calculer la distance.
Et en effet, comme l'a précisé Kevin, il y aura collision si la distance entre les deux balles est inférieure ou égale à la somme des 2 rayons.

Pour résumer ta méthode tu vérifie si la balle1 se trouve autour de balle2 à une distance du rayon de balle, si c'est le cas tu calcule précisément cette distance et si inférieur au rayon alors collision. En effet la condition de début peut être enlevée.

Euh quelle condition ?

En effet j'y avait pensé lors de mon premier test et j'ai passé l'après midi à programmer les collisions et ça fonctionne niquel, encore merci jackiechan.

Par contre il y a un bug graphique et non dû au collision car les balles ne se touches pas. C'est mon premier jeux donc peut être que ma méthode de sauvegarde des zones ou il y a la balle et de restauration des sprites et mauvaise. Voici le principe.

J'utilise une structure pour gérer les balles et elle est alloué dans la mémoire via un block. Au total il y a 10 balles, dans chaque structure de balle je possède une matrice de 18 octets donc matrice[9][2], mes balles font du 10x9. J'utilise Extgraph 1.02

Pour sauvegarder une zones:
Sprite16Get(Ball[i2]->x,Ball[i2]->y,BALL_HEIGHT,GetPlane(0),(void *)Ball[i2]->buffer0);

Sprite16Get(Ball[i2]->x,Ball[i2]->y,BALL_HEIGHT,GetPlane(1),(void *)Ball[i2]->buffer1);


Pour afficher les zones:
GraySprite16_MASK(Ball[i2]->x,Ball[i2]->y,BALL_HEIGHT,(void *)Ball[i2]->buffer0,(void *)Ball[i2]->buffer1,(void *)Ball[i2]->buffer0,(void *)Ball[i2]->buffer1,GetPlane(0),GetPlane(1));

Ta technique de sauvegarder les zones n'est pas pratique du tout !
Je te conseille de tout effacer et tout réafficher à chaque image.
Et sinon, je ne suis pas sûr que tu utilises ce que j'ai dit, parce qu'apparemment, tes collisions ne permettent que 4 directions...

Si tu veux une Sprite16Get un peu plus rapide, je peux te l'envoyer. Peut-être que je te l'ai déjà envoyée...
Il y a un truc du même type que ton programme dans ExtGraph 1.02, justement: une de mes démos préférées, demo11. Pas dit que ça soit exactement ce que tu veux, mais ça t'aidera peut-être déjà.

Pour le Sprite16Get en effet j'ai la nouvelle version et j'aurais dû y penser, merci beaucoup XDanger, je vais tout de suite regarder demos11.

est-ce que qd une balle arrive de gauche (horizontale) et une autre du haut (vrticale descendante), elles ne devraient pas toutes les deux, ou au moins une des deux, partir en bas ? (parce que là, elles feront demi tour, si g bien pigé)

Dans mon exemple en effet les balles font demi-tours selon leurs positions mais il est possible de faire comme tu dit squale92, dans ce cas tu pense que quelle méthode serait le mieux adaptée?

heu...
ça c la question que j'aurai préféré eviter
il faudrait travailler avec les deux balles, plutôt qu'avec une à la fois... cela dit, pas simple

Comment ça je dois travailler avec les 2 balles?
Pour la demo11, elle ne fait pas ce que je veut puisque quelle efface l'écran et affiche les balles hors moi je n'efface pas l'écran juste les balles, ce qui est plus rapide.

Est-ce que je doit utiliser le double buffering pour mon jeux et dans ce cas comme ça fonctionne et comment l'intégrer?

effacer tout l'écran et tout redessiner est souvent plus rapide que d'effacer juste ce que tu veux et ne redessiner que ça...
(et en plus, ça permet d'éviter les bugs graphiques )

travailler avec deux balles...
ben, je suppose que pr le moment tu as une balle qui entre en colision, tu inverse ses facteurs de déplacement ?
*travailler avec deux balles signifierai que, qd deux balles entrent en colision, tu modifie les facteurs de déplacement de ces deux balles à la fois en fonction de leurs facteurs de déplacement initiaux, mais aussi en fonctions de ceux de l'autre balle...

si une balle bient de gauche e tune autre du haut, pour changer les facteurs de déplacement de celle qui vient de gauche, il faut que tu sache que l'autre venait du haut...

C'est ce que je fait, je m'occupe des 2 balles et je pense qu'on le voit très bien sur le screen, le comportement des 2 balles qui sont entré en collision résulte de la direction de la balle1 et de la balle2.

Par contre pour le bug graphique, je n'arrive pas à le corriger et je suis sûr à 100% que d'effacer tout l'écran ralentiras les choses car ici il y a 10 balles mais dans le jeux ce serat variable et bien plus souvent il en aurat qu'une, surtout que je doit redessiner le décors, les briques, les bonus, les raquettes, les balles et pourquoi pas les ennemis donc très long.

Pour le bug graphique je ne comprend toujours pas, une trainée s'affiche s'en que les 2 balles se touche, peut être que je doit utiliser spriteX8 au lieu de sprite16 car mes balles font du 10x9?

Pour la trainsée, ca vient surement de ce que tu effaces par un sprite, il peut manquer un pixel qq fois ...

Ton problème, c'est qu'il faut restaurer les fonds dans l'ordre inverse à celui dans lequel tu les as sauvegardés!

Comment ça?