Bonjour à tous !

Je suis débutant en programmation. J´apprends le C (librairies standards) et la librairie SDL. Pour moi, rien de mieux que la pratique pour apprendre. Je me suis donc lancé dans l´élaboration d´un jeu en 2D ... projet qui me prendra bcp de temps mais qui je pense sera très bénéfique.

J´ai déjà fait un éditeur de maps, et je m´attèle ici à la gestion des collisions en 2D.

Mon premier problème est : quel algorithme utiliser ?

J´ai vu un excellent article sur Games-Creator parlant de la détection "pixel-perfect", malheureusement pas assez détaillé pour mes pauvres connaissances.

Je viens donc ici implorer votre aide ^^, soit pour me proposer d´autres méthodes plus simples mais précises, soit pour me proposer des liens vers des tutoriaux, dossiers, concernant ces collisions.

Lorsque je parle de collisions, il s´agit ici d´un "jeu" où le personnage se déplace au "pixel près" ... pas de "cases" dans l´écran, ... je sais pas si je suis très clair désolé. Je veux donc gérer les collisions entre les éléments du décor et mon personnage.

Merci d´avance pour votre aide !
Bonne continuation

Oulah si c´est ton premier jeu les collisions pixel perfect ça risque d´être un gros challenge.
C´est quel type de jeu ? Vue de côté/top down/vue 3/4 ?

Ca change un peu la manière de ruser =)

Hum ... c´est une vue tout ce qu´il y a de plus banal ... un peu comme Zelda par exemple. Le gars est vu de "côté", un peu du dessus, enfin banal quoi ...

PS : j´aime les challenges, j´aime les problèmes, j´aime ce qui prend la tête ^^ donc la difficulté.

On a parlé de ca hier, recherche sur la premiere ou seconde page.

La vue "à la zelda" c´est la vue de 3/4 ;)

Ok merci je vais rechercher

Après quelques recherches, finalement, je pense que le pixel perfect n´est franchement pas nécessaire dans mon cas, même surement inutile étant donés les sprites.

Je vais donc simplement détecter les collisions grâce à cet algorithme (merci JYY) :

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

Mais auparavant j´aurais besoin d´aide. Je vous explique :

La map est faite :

- d´un background d´"herbe" (une image de la taille de l´écran de jeu).

- de sprites collés sur ce background. Pour "coller" ces sprites. Seulement la map a été faite à partir d´un éditeur. pour passer de l´un à l´autre, je suis donc passé par un fichier, en inscrivant les coordonnées, et tout ce qu´il fallait. Maintenant, quand je colle ces sprites dans le jeu, je fais un simple BlitSurface. Il me faut donc un moyen de "marquer" que cette zone-ci est un sprite, alors que cette zone-là est de l´herbe.

Ce ne sont pas les idées qui me manquent, mais elles me paraissent toutes aussi "lourdes" et peu rapides les unes que les autres. Je voudrais donc savoir comment vous feriez pour "marquer" les sprites, afin que je puisse ensuite détecter les collisions.

Merci d´avance

La technique traditionnelle (au moins en flash)c´est de stocker tout le monde dans un tableau à deux dimensions.

Un tableau d´autant de pixel que contient ma fenêtre ? C´est pas un peu "bcp" ?

Par exemple pour une fenêtre 800*600 un tableau[800][600] ? Sachant que mon écran ne peut être divisé en "rectangles" comme certains jeux puisque les sprites, sont positionnés de n´importe quelle manière dans l´écran).

Sinon j´avais pensé à une technique, peut-être un peu lourde, mais qui rejoins en même temps la tienne.

Avant tout déplacement, lors du chargement de la map, je lis le fichier où sont inscrits toutes les coordonnées des sprites, et à partir de celles-ci je crée une sorte de "masque" ... qui peut être sous forme de tableau bidimensionnel, où les 1 vont correspondre à des sprites, et les 0 à du "background walkable". Auquel cas je n´ai, au moment du déplacement, plus qu´à vérifier que le sprite n´empiète pas sur une zone 1, et c´est tout.

Cela dit, je ne sais pas si c´est le plus rapide lors de l´execution (mon but étant bien sûr de rechercher le plus rapide à chaque tour de boucle évènementielle, quitte à alourdir le chargement de la map), et surtout je ne vois pas pour l´instant trop comment m´y prendre.

Je pense qu´il est deja trés important que tu reflechisse en separant bien ce qui est gestion du jeu et ce qui est affichage. Deja tu aura bien moins de problemes.

La conclusion de ce truc c´est que tu va faire des choses bien distinctes : Un truc pour faire ton affichage, et un truc pour faire la gestion du jeu (collision par exemple).

Ensuite pour chaque probleme, tu reflechi qu´est ce qui est le plus simple a faire. Comme dit fil, un bon gros tableau 2D c´est bien. Faut que tu determine quel precision tu as besoin. Dans DNA, j´en ai deux qui representent des cases de 32x32 pixels, un pour l´affichage (en gros quel tile j´affiche a cet endroit) et un pour la gestion du jeu (collision : mur, sol, echelle ). Etc ...
Ces données me servent pour faire les calculs, mon perso et les enemis se deplacent au pixel.

Mon conseil, c´est donc de bien separer tous les problemes et chaque probleme sera plus simple a resoudre. Car toute la map gerée au pixel, c´est pas possible.

C´est impossible ou difficile ? Parce que jusque là je n´ai eu aucun problème. M´enfin je vais tâcher de me renseigner un peu plus concernant cet aspect "au pixel près", merci pour ton aide !

Tout depends de la taille de ton jeu (que je connais pas). Donc si t´as des petit tableaux, pas de soucis, tu peux tout gerer "au pixel". Si tu veux utiliser des grandes maps, je vois pas trop comment c´est possible, vu la grande quantité de données qu´il va falloir stocker et parcourir (et pour des questions de vitesses, tu sera obligé de mettre en place des systeme de tableaux simplifiés si tes maps sont grandes)
Mais je repette, quand tu dis "gerer au pixel", faut bien preciser de quoi tu parle, car dans un jeu tout est separer.

Ok, ok, merci tu m´as bien éclairé, et je crois que je vais repartir sur des bases plus rigoureuses, mieux organisées, et créer des maps gérées par des tableaux bidimensionnels !

Meci bcp pour votre aide à tous !

(semi HS)
Les jeux de l´epoque des amstrad CPC 464, les nes et mastersystem ne faisait pas des collisions aux pixels pres ?
(j´ai toujours cru, a tord peut etre)

Certaines machines avaient des circuits specialisés pour afficher des sprites et faire des colisions entre ces sprites.
Cependant ca marchait pas pour tout (genre que sprite/sprite et pas decor/sprite).
De nos jours, la GBA (et surement la DS) ont encore ce genre de circuit. Mais les PC sont plus du tout equipé de ca, ca sert a rien. Le probleme des données grahiques maintenant c´est qu´elles sont stockées dans la carte graphique et qu´en general il est difficile de les lire ou manipuler par le proc principal, tout est bien separé.

Désolé de upper un topic qui a deux ans, mais j'ai pensé que c'était utile.

Je cherchais un algo de collisions de rectangle et comme j'étais sur que ca avait été fait 100 fois ici, je suis tombé sur ce topic.
Lodu disait qu'il utilisait un algo venu de JYY, mais cet algo est faux(en fait, il ne compilait meme pas, donc...). Il est rectifié ci dessous:

int Collisions(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;
}