Discussion :

[poussinphp]

Bonjour à tous !!

Je suis sur un petit projet de jeu style "sonic".
J'ai crée un menu d'intro qui mène au jeu en lui-même (premier niveau).

J'ai réalisé un clipping pour le personnage (encore merci pour le tuto trouvé sur ce site, il ma beaucoup aidé ).

Je tombe maintenant sur quelques problèmes. J'ai cherché un peut partout mais je n'ai pas trouvé mon bonheur.

Je cherche à gerer les collisions entre mon personnage et le decors. J'ai vu des exemples qui utilisent le système de cases mais j'aurais besoin d'utiliser une méthode qui detecterais au pixel près la collision (et qui ne prendrais pas en compte la transparence de mes png).

Pour la gestion de la carte, faut t'il charger toutes les images (dans un tableau de SDL_rect) puis les poser (même dans la partie non visible de l'ecran) ou (seulement poser la partie visible et on change les images celon le deplacement) ??? Dailleurs, pour la seconde proposition, je ne voit pas comment je pourrais faire

Auriez-vous un lien ou un exemple pour ces 2 petits problèmes svp ?

Merci par avance

[Fiquet]

Je cherche à gerer les collisions entre mon personnage et le decors. J'ai vu des exemples qui utilisent le système de cases mais j'aurais besoin d'utiliser une méthode qui detecterais au pixel près la collision (et qui ne prendrais pas en compte la transparence de mes png).

Les collisions pixel perfect ? Je ne sais pas si loka va en parler dans ses articles (http://loka.developpez.com/tutoriel/sdl/).

Pour la gestion de la carte, faut t'il charger toutes les images (dans un tableau de SDL_rect) puis les poser (même dans la partie non visible de l'ecran) ou (seulement poser la partie visible et on change les images celon le deplacement) ??? Dailleurs, pour la seconde proposition, je ne voit pas comment je pourrais faire

Non il ne faut jamais essayer de dessiner ce qui ne se voit pas, ce serait un manque de temps inutile. Il faut afficher les images selon le déplacement du perso, oui. Par exemple en stockant dans un tableau les informations sur les sprites, ainsi que leur position, tu parcours ton tableau selon l'endroit ou tu te trouves et tu affiches le bon endroit.

[loka]

Oui je compte en parler dans mon tuto (il y aura 3 parties : box-colisions, collisions pixel-perfect, collisions circulaires).
Il faudra attendre 4 chapitres (surtout attendre que je finisse mes exams pour m'y remettre vraiment ^^)

Pour les collisions pixel-perfect, il faut que tu penses chacun de tes sprites comme une rangée de rectangles.
Par exemple un cercle comme celui-ci :


te donnera une serie de rectangles comme ça :


Il te reste à verifier que chaque rectangle n'entre pas en collision avec d'autres, donc tu dois tester chaque serie de rectangle du premier sprites avec chaque serie de rectangle du second sprite.

Pour ma part afin de simplifier le code j'utilise <vector>

Je te laisse reflechir à partir de ça

[poussinphp]

Merci Fiquet (Va falloir que je trouve une méthode pour gerer ce système de carte).

Concernant la gestion des collisions. J'ai regardé le tutorial de game-creator. Je comprend pas trop ce système. Je trouve plus logique la méthode de Loka.

Par contre je comprend pas comment l'implémenter. Comment je peut savoir si les pixels sont transparent ou remplis dans mon fichier
J'utilise :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IMG_Load("image.png")

De plus, je voit pas comment decouper mon image en rectangle

Je suis débutant encore en SDL, désolé mais je ne voit vraiment pas comment faire .

[loka]

Pour decouper ton image en rectangle tu peux faire un truc de ce genre (je fais ça au niveau du constructeur de mon sprite) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
//Initialize the collision boxes' width and height
    box[ 0 ].w = 6;
    box[ 0 ].h = 1;
 
    box[ 1 ].w = 10;
    box[ 1 ].h = 1;
 
    ...

Bien sûr ça reste specifique à chaque sprite, donc il y a un gros travail là dessus, mais on à rien sans rien

Ensuite ce que tu dois penser à faire aussi c'est de bouger les rectangles de collision lorsque tu bouges ton sprite.
Un code tout bête qui ne devrait pas te poser trop de problèmes, il faut juste y penser. Tu as même deux façons de le faire :

- bouger les rectangles de collision de la façon :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
box[ 0 ].x = x + 7;
box[ 0 ].y = y;

(bien sur pas en dur mais une fonction avec en parametre le deplacement).

- mettre à jour la position des rectangles de collision par rapport à où se trouve ton sprite, dans ce cas tu n'as pas besoin de parametre si tu as bien fait ton code, il suffit juste de connaitre la position(x,y) du sprite, la largeur de ton sprite, la largeur du rectangle de collision ainsi que la hauteur du rectangle de collision par rapport au sommet de ton sprite.

Tu n'as donc pas besoin de savoir si les pixels sont transparents ou remplis dans ton fichier.

Et oui c'est du boulot si tu veux faire du pixel-perfect ^^

[poussinphp]

Désolé mais j'ai toujours du mal à comprendre Je vais donc essayer de marquer ce que j'ai compris.

Si je comprend bien je crée ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
SDL_Rect box;
box[0].x = 0;
box[0].y = 3;
box[1].x etc....

Puis je le place sur le sprite
(voici un bout de sol pour ma part)


Ainsi qu'une des images de mon personnage (Que je recupère via un clipping)


Je crée un element box_sol[X] qui referenceras 2 box (une pour la petite côte[0] et l'autre pour le reste[1]). La dimension de box[0] seras de 1px de hauteur et de la largeur de la petite cote. La dimension de box[1] feras toute la longueur du sprite et 1px de hauteur.

Pour le personnage, je fais la meme chose avec les pieds (etant donné qu'il bouge ça serais pas mieux de faire une box qui fasse toute la longueur mais juste en dessous de ces pieds??? ça eviterais de recalculer pour chaque image du clipping).

Puis, si je comprend bien, je dit par defaut que le personnage doit tomber de 1px à chaque fois que je fais un tour de ma boucle (de jeu). Si la box du personnage est plus basse que celle du haut du terrain, alors je redeplace le sprite du personnage pour qu'elle soit juste au dessus.

Mais là, j'ai un doute. Si plus tard, je met le même sprite un peut plus haut (bah oui, une plateforme) et que le personnage passe en dessous, il va automatiquement passer au dessus, non?

Ou alors j'ai toujours mal compris

[Laurent Gomila]

La méthode des rectangles me semble bien compliquée à mettre en oeuvre, pourquoi ne pas faire du vrai pixel perfect avec tableaux de booléens et tout le tsoin-tsoin ? En gros il faut te trimballer deux représentations de tes sprites et décors : la représentation visuelle qui va apparaître à l'écran, et une qui va dire si chaque pixel est "walkable" ou non. A chaque fois que tu veux tester une collision tu parcours tes tableaux de booléens : si deux pixels superposés sont tous les deux à false, alors boum collision.

Ensuite pour trouver la position du perso, il suffit de remonter verticalement en partant de sa position, jusqu'à trouver un pixel walkable. Ainsi tu n'arriveras pas jusqu'à la plateforme qui est au-dessus de ton perso si celui-ci est par terre

[poussinphp]

Je voit bien ton système mais je voit pas comment l'implémenter

Ma forme n'est pas parfaite, comment voir si un pixel est noir ou blanc?

Je doit blitz 2x? C'est pas lourd en ressource? J'aimerais bien que ça reste rapide

[Laurent Gomila]

Je voit bien ton système mais je voit pas comment l'implémenter

Ma forme n'est pas parfaite, comment voir si un pixel est noir ou blanc?

Tu gères de la transparence pour ton sprite non ? Et bien si un pixel est totalement transparent alors il ne sera pas collisionnable, facile.

Je doit blitz 2x? C'est pas lourd en ressource? J'aimerais bien que ça reste rapide

Blitz 2 fois ? C'est-à-dire ? Tout ce que tu as en plus au niveau calculs c'est un parcours de petites zones de tableaux de booléens, pas de quoi casser trois pattes à un canard.

[Sivrît]

Le première chose à faire est de détecter les collisions comme d'habitudes, avec de bon gros rectangles, afin de voir si deux sprites se chevauchent (sinon pas la peine de perdre du temps avec les pixels). En cas de chevauchement on détermine la zone que les sprites ont en commun (pour limiter l'étendue à tester).

Et ensuite on teste les pixels sur la zone réduite. Une méthode est d'avoir un masque pour chaque sprite qui indique les pixels occupés (dixit le tableau de booléens de Laurent Gomila). Sinon, si le masque de collision se confond avec la partie affichée (ce n'est pas toujours le cas : dans certains shoot par exemple le masque de collision est beaucoup plus petit que le sprite affiché... mais c'est un rectangle ), on peut se baser sur l'image, soit parce que une couleur correspond à la transparence (surtout quand on a une palette de couleurs), soit en utilisant le canal de transparance.
Par exemple on va regarder si pour un point du rectangle 'louche' on a des valeurs de tranparance non nulles pour chancun des deux sprites (donc une collision). Et ce sera lourd en terme de calcul, ce qui explique qu'on ne fasse pas ça tout le temps.

En terme d'implémentation je ne connais pas l'API SDL par coeur mais il me semble qu'elle permet un accès direct à ses surfaces (ie sprites).

Par contre je ne sais pas si poser le personnage sur le sol est la meilleurs application de cette technique. Tu est parti pour avoir un personnage qui ne fait jamais qu'effleurer le sol. Je m'attendrais à le voir poser franchement les pieds dans l'herbe plutôt que de reposer sur un simple brin d'herbe.
En plus, est-il nécessaire d'utiliser une technique si lourde juste pour ne pas toucher à l'herbe (oui c'est une fixation ) ? Je pense qu'elle serait plus à réserver pour les collisions avec les ennemis (qui ne sont peut-être pas encore là).

loka> Pour les rectangles j'ai un gros doute Dans le cas d'un personnage avec deux jambes (ou pire) ça fait beaucoup de rectangles, et les comparer deux à deux nous fait un algo en n*n avec des comparaisons un brin complexes. En plus on est un peu obligé de tester tous les rectangles par opposition à un sous ensemble des pixels... à moins de monter un arbre façon octree mais ça devient totalement overkill
Ca vaut le coup par rapport à une comparaison de pixels industielle et optimisée ?

PS: Laurent Gomila m'a grillé mais je poste quand même pas tapé tout ça pour rien quand même

[poussinphp]

Je comprend mieux !!!!

Je pensais qu'il fallais prendre son sprites image avec paint, colorier ce qui est visible en noir et le transparent en blanc. Puis charger l'image en "noir et blanc" puis la normal par dessus. l'image noir et blanc aurais servis pour la detection des collisions.

Enfin bon, je voit ce qu'il faut faire. suffit juste que je trouve la fonction pour detecter le type de pixel que c'est.

Donc, si je comprend bien (désolé si je suis un peu lent à comprendre mais faut dire que lorsque qu'on connais pas, c'est assez dur de lier méthode de compréhension et fonctions SDL pour obtenir le resultat), je crée un tableau contenant des boolean et donc la taille = taille du sprite. je fais cette methode pour chaque sprite susceptible d'entrer en collision.

Ensuite lorsqu'un evenement arrive, je test si dans mon tableau de boolean du personnage, j'ai une coordonée qui ce superpose avec un autre tableau de boolean dont la valeur est false.

ça va pas être du gateau, mais bon, faut bien passer par la

Encore merci pour vos aide (je met pas encore le sujet en résolu. il se peut que je bloque encore sur ça )

[poussinphp]

N'ayant pas vu le message pendant que j'ecrivais le message ci-dessus, je pense bien utiliser la méthode des box.

Je m'attendrais à le voir poser franchement les pieds dans l'herbe plutôt que de reposer sur un simple brin d'herbe

J'avoue que cette phrase ma bien fais réflechir. C'est clair que c'est absurde que mon personnage marche sur les brins d'herbes.
D'un autre coté, si je fais "plusieurs étages" du meme sprites pour faire une sorte "d'escalier vertical" (Je le ferais pas à se point là mais bon). Si je fais une collision box, la partie basse du sprite seras aussi bloqué, ce qui n'est pas naturel non plut

Faudrais juste que j'arrive à poser une ligne d'interdiction de passage de façon à pouvoir faire plusieurs étages de sol (comme on pouvais souvent le voir dans les mario ou sonic).

ça me revient à faire 4 couches :
- Arrière plan
- Collisions box
- decors
- personnage

[loka]

loka> Pour les rectangles j'ai un gros doute Dans le cas d'un personnage avec deux jambes (ou pire) ça fait beaucoup de rectangles, et les comparer deux à deux nous fait un algo en n*n avec des comparaisons un brin complexes. En plus on est un peu obligé de tester tous les rectangles par opposition à un sous ensemble des pixels... à moins de monter un arbre façon octree mais ça devient totalement overkill
Ca vaut le coup par rapport à une comparaison de pixels industielle et optimisée ?

PS: Laurent Gomila m'a grillé mais je poste quand même pas tapé tout ça pour rien quand même

Oui mais il y a une façon de reduire enormement la complexité ce qui reviens presque à du log(n) (il me semble, je verifierais^^).
C'est vrai que cette methode est lourde surtout niveau definition des rectangle, c'est pour ça que je la reserve aux figures pas trop complexe et sur ce genre de figures, les tests que j'ai fais m'ont montrer que c'etais plus rapide que du vrai pixel-perfect tout en ayant quasiment la même precision

Mais il est vrai que des figures aussi compliqué qu'un sonic ou autres, ça deviens sans doute trop lourd (pas encore testé de ce coté là, mais ça vaudrais le coup d'essayer je pense... ptete après mes exams ^^).

[poussinphp]

Finalement, j'ai trouvé une fonction pour lire un pixel.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
// Recup d'un pixel (surface, Absicce X sur la surface, absicce Y sur la surface)
Uint32 getPixel(SDL_Surface *surface, int x, int y)
{
    int bpp = surface->format->BytesPerPixel;
     /* Ici p est l'adresse du pixel que l'on veut connaitre */
     Uint8 *p = (Uint8 *)surface->pixels + y * surface->pitch + x * bpp;
 
 
     switch(bpp) {
     case 1:
         return *p;
 
     case 2:
         return *(Uint16 *)p;
 
     case 3:
         if(SDL_BYTEORDER == SDL_BIG_ENDIAN)
             return p[0] << 16 | p[1] << 8 | p[2];
         else
             return p[0] | p[1] << 8 | p[2] << 16;
 
     case 4:
         return *(Uint32 *)p;
 
     default:
         return 0; /* Ne devrait pas arriver, mais évite les erreurs */
     }
 }

Ensuite, dans mes evenements, si il ne se passe rien alors le personnage tombe (descend). Mais j'ai un petit soucis concernant ça justement. je ne sait pas comment vérifier le contenu d'un UINT8

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
       bouge_h = bouge_h+2;
       pixel=getPixel(ecran,(bouge_l+TILE),(bouge_h+TILE));
       SDL_GetRGBA(pixel, ecran->format, &rouge, &vert, &bleu, &trans);
       if (trans == 255) {bouge_h = bouge_h-2;}

J'ai essayé comme ça mais ça marche pas (trans est un UINT8). pourtant c'est bien en valeur Alpha (0 à 255), non?

[poussinphp]

C'est bon !!
ça marche

J'ai trouvé l'astuce pour que ça fonctionne mais j'ai encore des bugs. surtout pour la gestion du "personnage qui tombe". En effet, soit il tombe de X pixels à chaque appuis de touche (pas très réaliste). Soit si je fais une bucle, il tombe d'un coup (instantané), ce qui n'est pas très réaliste non plut.

Autre soucis, quand on a un arrière plan, le système de pixel transparent (pixel noir pour ma part) marche pas

Va falloir que je regarde ça

Encore merci beaucoup pour vos conseils

[Sivrît]

C'est bon !!
ça marche

J'ai trouvé l'astuce pour que ça fonctionne mais j'ai encore des bugs. surtout pour la gestion du "personnage qui tombe". En effet, soit il tombe de X pixels à chaque appuis de touche (pas très réaliste). Soit si je fais une bucle, il tombe d'un coup (instantané), ce qui n'est pas très réaliste non plut.

Autre soucis, quand on a un arrière plan, le système de pixel transparent (pixel noir pour ma part) marche pas

Va falloir que je regarde ça

Encore merci beaucoup pour vos conseils

Bonne chose que tu ais trouvé. Moi je viens de regarder là où j'aurais du commencer : http://jeux.developpez.com/faq/sdl/?...odifier_pixels

Pour ce qui est de tomber, mettre à jour à chaque évènement clavier n'est pas une solution viable, il faut une boucle (pour un jeu temps réel c'est inévitable). Le seul truc qui te manque c'est de limiter la vitesse, afin de mettre à jour un nombre de fois donné par seconde. Disons typiquement limiter à 60 fps. Pour la méthode : http://jeux.developpez.com/faq/sdl/?...esse_affichage


Pour l'arrière plan, le problème est que tu testes sur l'écran qui est "pollué" par tout plein de trucs jolis mais inutiles. Pour que ça marche il faut trouver les sprites en collision au sens non pixel-perfect (en se basant sur des rectangles, par exemple ceux qui servent à blitter). Ensuite on regarde les pixels de ces sprites (et seulement eux) qui n'ont normalement pas de "fond" qui pourrait nous perturber. Ca va juste être un peu plus délicat sur la gestion des coordonnées.

A noter que ce type d'accès aux images va être assez lent car les surfaces SDL sont en mémoire graphique (du moins elles le devraient) alors que les calculs de collisions se font en RAM. Et SDL_GetRGBA n'est pas gratuit non plus. Pour aller plus vite il faudrait peut-être créer pour chaque sprite un tableau de booléen indiquant pour chaque pixel si celui-ci est "dur" (transparant), au début et une bonne fois pour toute. Comme ça les données sont disponibles sous une forme plus exploitable.

De plus, tester les collisions avec chaque élément du décors va être couteux. Il faudrait penser, par exemple, à donner pour chaque niveau un fichier donnant les lignes sur lesquelles on marche, et vérifier que l'on en traverse pas une. Ce serait simple et rapide.


conclusion : la FAQ est grande ! Louée (et utilisée) soit elle !

[poussinphp]

Merci beaucoup pour le message
Pour l'instant je travaille surtout sur la séparation des choses (joueur / collision / carte ) dans plusieurs fichiers. Après pour le rafraichissement j'utilise SDL_Delay. Je pense bientot passer à SDL_GetTicks

Ensuite, pour les collisions, en faite je recupère la position de mon perosnnage, je prend quelques pixels essentielles (haut-droite / haut-gauche / haut centré / bas-droite etc..) ce qui me revient à avoir que 8 points à tester. Ensuite celon le cas, je choisis ceux qui sont succeptible d'entrer en action (la tete du perso ne toucheras jamais le sol).

J'utilise une variable (position x et y) du perso. Je fais l'event puis après je test en boucle et enfin j'affiche. Effectivement, meme si ya un fondu pendant le test sur sonic, le joueur ne le veras pas car le rafraichissement s'effectue après

Il faudrait penser, par exemple, à donner pour chaque niveau un fichier donnant les lignes sur lesquelles on marche, et vérifier que l'on en traverse pas une. Ce serait simple et rapide.

Je suis d'accord mais je ne peut pas car les decors sont pas carrés.

Voila

[Sivrît]

Je suis d'accord mais je ne peut pas car les decors sont pas carrés.

Un ligne peut tout à fait ête oblique. Enfin se serait plutôt des segments pour être exact. L'intéret est qu'en regardant l'abscisse du sprite on trouve très rapidement les segments que l'on doit tester.
Et la zone sur laquelle marche le personnage correspond bien à une succession de segments (enfin dans les sonic et la plupart des jeux de plateformes). Par contre avec les looping à la sonic je sais pas ce que ça donne... en fait je ne sais pas comment Sega a géré ça. Un graphe peut-être. Quand on court sur un segment et qu'on arrive au bout on se met à suivre le suivant (idée comme ça). Ca limite les "collisons" avec le sol aux sauts (quand on tombe vraiment) et permet de vraiment marcher.

J'utilise une variable (position x et y) du perso. Je fais l'event puis après je test en boucle et enfin j'affiche. Effectivement, meme si ya un fondu pendant le test sur sonic, le joueur ne le veras pas car le rafraichissement s'effectue après

En fait le test est plutôt à faire une seule fois, mais dans la boucle de rafraichissement, à chaque frame. Lorsque l'on traite les évènements (claviers surtout), on se contente généralement de marquer l'action demandée, par exemple en notant les touche enfoncées.
Et en parallèle on a la boucle du jeu (et c'est elle qui exploite les entrées du joueur) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Tant que jeu pas fini:
   traiter entrées joueur (si droite ou gauche translation, saut etc...)
   si pas au sol y=y-2
   déplacement des ennemis
   test collisions avec ennemis
   attendre qu'1/60 de seconde soit passé depuis la dernière frame
   affichage

C'est super approximatif mais généralement le déroulement ressemble à ça.