Test de collision - Page 1

J'ai un petit problème d'optimisation que certains ont peut-être rencontré, mais les jeux c'est pas mon domaine alors je suis un peu perdu...

J'ai un petit prog où on dirige un perso vu de dessus, mais ça ne fonctionne pas en déplacement case par case, on peut très bien en chevaucher plusieurs. Le problème est alors de tester les collisions...
Je pensais donc tester les 4 coins du sprite de mon perso, qui fait 4 pixels de moins que les murs en largeur et en hauteur.

Voici donc comment tester les 4 coins, en ayant une matrice et les positions X et Y du perso (qui sont des positions sur L'ECRAN, pas sur la matrice) :
map[((pos_x+2)>>4)][((pos_y+2)>>4)] (>>4 parceque les cases font 16x16 pixels)
map[((pos_x+13)>>4)][((pos_y+13)>>4)]
map[((pos_x+2)>>4)][((pos_y+13)>>4)]
map[((pos_x+13)>>4)][((pos_y+2)>>4)]

Mais pour tout tester ça donne une ligne monstrueuse, d'autant plus que mon tableau est à une seule dimention et que donc il faut convertir. Voilà la ligne fort sympatique :

if(!(tbl_val[((int_nwx+2)>>4)+((tbl_pos[1]+2)>>4)*tbl_num[1]] || tbl_val[((int_nwx+13)>>4)+((tbl_pos[1]+13)>>4)*tbl_num[1]] || tbl_val[((int_nwx+2)>>4)+((tbl_pos[1]+13)>>4)*tbl_num[1]] || tbl_val[((int_nwx+13)>>4)+((tbl_pos[1]+2)>>4)*tbl_num[1]])) tbl_pos[0]=int_nwx;

N'y a-t-il pas des moyens d'optimiser ça (voire de changer completement de méthode) ?

ce serait pas mieux de tester par secteur ?

Heu... C'est à dire ?

ça me rapelle toi cette merveilleuse ligne de code

cette ligne serait même à mettre dans le topic sur "Vos codes les plus illisibles"

Bob 64 a écrit :
if(!(tbl_val[((int_nwx+2)>>4)+((tbl_pos[1]+2)>>4)*tbl_num[1]] || tbl_val[((int_nwx+13)>>4)+((tbl_pos[1]+13)>>4)*tbl_num[1]] || tbl_val[((int_nwx+2)>>4)+((tbl_pos[1]+13)>>4)*tbl_num[1]] || tbl_val[((int_nwx+13)>>4)+((tbl_pos[1]+2)>>4)*tbl_num[1]])) tbl_pos[0]=int_nwx;
N'y a-t-il pas des moyens d'optimiser ça (voire de changer completement de méthode) ?

Commence déjà par couper ça en plusieurs lignes. Une instruction en C peut très bien faire plus d'une ligne, et on y verrait déjà plus clair. Après, quand je pourrai lire ce que tu as mis, je pourrai peut-être t'aider à l'optimiser.

1 || condition2 || condition3)Et fais un découpage censé (par exemple:if (condition), pas un découpage au hasard, sinon ça ne sert à rien.

je vais essayer de faire ça, je vous promet rien

if(!(   tbl_val[ ((int_nwx + 2)>>4) + ((tbl_pos[1] + 2)>>4) * tbl_num[1] ] 
     || tbl_val[ ((int_nwx + 13)>>4) + ((tbl_pos[1] + 13)>>4) * tbl_num[1] ] 
     || tbl_val[ ((int_nwx + 2)>>4) + ((tbl_pos[1] + 13)>>4) * tbl_num[1] ] 
     || tbl_val[ ((int_nwx + 13)>>4) + ((tbl_pos[1] + 2)>>4) * tbl_num[1] ]  ))
{
  tbl_pos[0]=int_nwx; 
}
  

int_nwx

et pis t'as pas donné des noms intuitifs aussi, comme en BASIC !

ps : ds ce genre de cas, la coloration syntaxique serait bien essais avec l'éditeur de source si ça donne qq chose

Rahhh vous me saoulez... C'est ma façon de programmer, j'y peux rien j'aime les lignes optimisées à fond, même si elles son énormes (mais bon avec mon niveau en C on peut pas encore appeller ça "optimisé à fond" )

Découpage : if(!(   tbl_val[ ((int_nwx + 2)>>4) + ((tbl_pos[1] + 2)>>4) * tbl_num[1] ]       || tbl_val[ ((int_nwx + 13)>>4) + ((tbl_pos[1] + 13)>>4) * tbl_num[1] ]       || tbl_val[ ((int_nwx + 2)>>4) + ((tbl_pos[1] + 13)>>4) * tbl_num[1] ]       || tbl_val[ ((int_nwx + 13)>>4) + ((tbl_pos[1] + 2)>>4) * tbl_num[1] ]  ))
(Il n'y a qu'un seul test sur 2, l'autre étant le même mais pour la position int_nwy)

tbl_val : tableau valeurs (les données du terrain, obstacle ou non)
tbl_pos[0] : position X actuelle
tbl_pos[1] : position X actuelle
int_nwx : position X ou l'on va essayer de se déplacer (new X position)
int_nwy : position X ou l'on va essayer de se déplacer (new Y position)

J'ajoute 2 et je retire 13 à la position car le sprite du perso est plus petit de 4 pixels en X et en Y. Ce qui nous donne comme extremités non pas 0 et 15 mais 0+2 et 15-2, c'est à dire 2 et 13. Les décalages de bit sont là pour convertir ces coordonnées en position sur la matrice (16 pixels -> un element du tableau).

Ce test fonctionne parfaitement sans aucun bug (Pim89 peut témoigner). Son seul problème c'est qu'il est un peu lent.

Voilà je peux pas faire mieux

C'est quoi tbl_num[1]?

La dimention X qu'aurait mon tableau si il était à 2 dimentions. Comme il n'en a qu'une mais que j'ai besoin d'une matrice, je transcrit :

tbl_val[x+y*rowdim]

pkoi tu f pas un tableau a 2 dim ?

Parce qu'il passe par un pointeur pour pointer vers sa matrice dans un fichier externe je pense.

Et puis je trouve plus logique de faire pour acceder à un element *(map + x+ y*x_size_map) ⁽¹⁾ que map[y][x]
Car en mémoire tous les octets sont à la suite, comme pour un tableau à une dimension, et pas "superposés" comme un tableau à 2 dim.
Cette syntaxe ⁽¹⁾ est plus logique quand on regarde la mémoire pur de la TI pour la lecture d'éléments.

à la limite tu peux faire #define map(x,y) (_map[(x)+size*(y)]), c plus zouli

Tu peux aussi faire ça:
int fonction(int y;char (*tableau)[y],int x,int y)
{
...
}

À appeler comme ça:
fonction(tableau,x,y);

Arf Kevin, spécialiste de la lenteur


Plutôt comme ça, si on tient à avoir le truc sous forme de fonction :

[b]inline[/b] int fonction(char (*tableau)[y], int x, int y) 
{ 
  ... 
} 

Tu n'as rien compris de ce que j'ai dit!!!

J'ai répondu à ça:

Pim89
a écrit : Parce qu'il passe par un pointeur pour pointer vers sa matrice dans un fichier externe je pense.

Donc au lieu d'utiliser:
int fonction(char *tableau,int x,int y)
{
...
}
ce qui oblige à utiliser des multiplications pour tous les accès à tableau dans la fonction, on utilise:
int fonction(int y;char (*tableau)[y],int x,int y)
{
...
}
ce qui permet d'utiliser tableau[x][y] dans la fonction!

Effectivement j'avais pas compris

Et heu... pour les collisions... ?

bon ok je vois