C´est un probleme de fonctonnalité ca, et ca depends de ce que represente tes rectangle. La premiere etape c´est de detecter les collisions ensuite il faut gerer le resultat des collision mais ca ca depends de ce que tu veux faire (detruire les rectangle, les faire rebondir, en ejecter un ou l´autre, etc ...)

A mon avis, tu dois mal faire ton algo, comme dis Lapintade. Je pense que tu fais ceci :

Lors d´une demande de mouvement :
- si il y a collision, alors tu n´autorises pas le mouvement
- sinon, tu déplaces.

Cette façon de faire pose un probleme, car tu peux avoir des cas ou tu es DANS un mur, et ne plus bouger. Tu permets a ton bonhomme - par exemple - d´aller dans le mur, et une fois qu´il y es, tu lui interdit d´en sortir. Ce qu´il faut, c´est de ne JAMAIS etre dans un mur.

Je te suggere plutot ceci :
Lors d´une demande de mouvement :
- tu mémorises la position ou tu es, puis tu déplaces.
- tu testes la collision avec la nouvelle position.
- s´il y a collision, alors tu restaures l´ancienne position mémorisée (donc finalement, tu ne valides pas le déplacement)

Avec ceci, tu ne seras jamais dans un mur

Pour tester les collisions, voici un algo plus rapide:
http://rafb.net/paste/results/xIFciv75.html

Ensuite, pour gerer les positions, si par exemple tu veux que les objets puissent se toucher mais sans rentrer l un dans l autre (en supposant que lorsque tu fais le teste, un seul bouge, sinon c est un chti peu plus complique), et qu´ils ne glissent pas l un sur l autre:
- si le mouvement n est que suivant X ou que suivant Y, fastoche, tu peux facilement calculer ou doit aller l objet pour qu il se touche (tu le deplaces de -penetration)
- si le mouvement est suivant X et Y, une facon de faire et d´iterer sur les valeurs de depart et de fin tant qu il y a collision (et ca ne fonctionne que si le deplacement maximal est plus petit que la taille des rectangle).

Joli algo !! !

je le traduis avec des prototypes de SDL_Surface pour ceux qui utilisent SDL, merci Kufa

int Collision(SDL_Surface* a,SDL_Surface* b )
{
if((b->x >= a->x + a->w)
|| (b->x + b->w <= a->x)
|| (b->y >= a->y + a->h)
|| (b->y + b->h) <= a->y
)
return 0;
return 1;
}

No problemo
(c est d ailleurs l algo que j utilisais dans certains de mes jeux pour portables)

Si tu cherches encore quelques détails, tu peux regarder sur ce topic :

https://www.jeuxvideo.com/forums/1-31-8465061-1-0-1-0-0.htm

On avait le même problème que toi. En plus, il y a qurlques lien à propos du "pixels perfect" (collision sans rectangle) et quelques techniques bien sympa de JeanYvesYves qui pourront peut-être t´inspirer !

(comme on en parlé sur
https://www.jeuxvideo.com/forums/1-31-8273016-355-0-1-0-0.htm je répond ici)

C´est bizarre ta traduction jyy ca dit qu´il y a une collision si: (b->x >= a->x + a->w) . Soit si b est a 100 kilometre a droite de a, alors il y a une collision.

J´ai du ne pas comprendre quelque chose...

En fait il teste toutes les conditions fausses, et renvoie 0, donc si b est a 100 kilometre a droite de a, on renvoie 0, sinon 1.

Non, justement, on passe dans le if si il n´y a pas collision

En gros, le if se traduit ainsi :

si on est trop a gauche
ou trop a droite
ou trop en haut
ou trop en bas

--> Alors pas de collision
Sinon, collision

ah, oui j´avais mal lu!
C´est un peu duale comme vision des choses!

en tout cas, c´est un bel algo !
Comme il est souvent en zone critique, il faut qu´il speed !

Je dirais meme qu´en fonction du type de jeu, on peut se permettre de la personnaliser, en mettant les conditions OU dans le meilleur ordre possible :
Comme la norme veut que les conditions soient traitées dans l´ordre, il faut mettre en avant (comme c´est des OU) celle qui a le plus de chances de passer à 1 pour sortir au plus vite.