Discussion :

[all_in]

Bonjour à tous, je fais un flipper en SDL actuellement avec un nombre d'obstacles de formes très variée.

Pour la gestions des collisions,j'utilise une Map_collision, ou j'ai mis des points noirs RGB(0,0,0) et sur ma bille j'ai repéré 8 points.
gauche,droite,haut,bas, +et- pi/4, +et- (pi+pi/4)

A chaque mouvement de balle je contrôles la positions de ces 8 pixels par rapport à la Map_collision, si il y'a contact j'inverse les vecteur suivant le point en contact.
pour les positions pi/4 j'inverse vectx et vecty et pour le haut,bas j'inverse vecty et pour le gauche droite j'inverse vectx.

Cependant j'ai de gros problèmes avec ma méthode:

->Lorsque la balle a un vecteur vitesse telle que vx=19 et vy=10, il arrive que ma balle rentre dans le décors totalement(bordures et obstacles).
(Il me faudrait donc une fonction qui contrôle si la bille est rentré dans un obstacle avant de la blitter et si c'est le cas la blitter au bord)
Par exemple ceci serais simple a faire pour un vecteur x=y=10 j'incrémente progressivement la position de la balle de pos.x++ pos.y++ et je contrôle si il y a des collisions.Si je vois qu'il y'a contact,je m'arrête je blitte et je modifie le sens des vecteurs.
Mais pour les vecteur tel que vx=1 vy=20 il y'a problème je ne sais pas comment faire ?

[nanosoft]

Bonjour,

Je suppose que, en fonction de ton vecteur vitesse, tu modifies la position de la bille avant chaque blit.
C'est à ce moment là qu'il faut faire un test : si la nouvelle la position dépasse la limite tu ne modifies pas la position de l'incrément prévu mais uniquement du delta entre la position actuelle et la limite (et tu changes aussi ton vecteur vitesse).

Il me faudrait donc une fonction qui contrôle si la bille est rentré dans un obstacle avant de la blitter et si c'est le cas la blitter au bord

Oui, exactement !

Mais pour les vecteur tel que vx=1 vy=20 il y'a problème je ne sais pas comment faire ?

Est-ce que tu ne confonds pas vitesse et incrément de position ?
As tu une variable qui représente le temps et que tu incrémentes régulièrement ?

Cela dépend du frame-rate que tu as choisi et tu n'es pas obligé d'incrémenter la position pixel par pixel (l'incrément est calculé en fonction de la vitesse), par contre il faudra peut être faire certains calculs avec des float.

[all_in]

Bonjour Merci beaucoup de ta réponse,

Je suppose que, en fonction de ton vecteur vitesse, tu modifies la position de la bille avant chaque blit.
C'est à ce moment là qu'il faut faire un test : si la nouvelle la position dépasse la limite tu ne modifies pas la position de l'incrément prévu mais uniquement du delta entre la position actuelle et la limite (et tu changes aussi ton vecteur vitesse).

C'est fait !

Est-ce que tu ne confonds pas vitesse et incrément de position ?

par contre il faudra peut être faire certains calculs avec des float.

float k;
Alors je fais le rapport k=vx/vy et suivant le resultat,
--->if(k<1){ vx+=k ;vy+=1;}
--->if(k>1){ vx+=1 ; vy+=(1/k);}

Cela fonctionne a la première collisions mais ensuite il y'a des soucis, en effet lorsque le coefficient k<1, la position s'incremente mais la bille reste au même endroit car k est très petit et la position de la bille reste parfois au même endroit et les collisions se multiplie. La bille oscille et ne sort jamais de l'endroit ou est intervenu la collision.

As tu une variable qui représente le temps et que tu incrémentes régulièrement ?

Non, je n'en ai pas.A quoi cela peut-il servir?

Cela dépend du frame-rate que tu as choisi et tu n'es pas obligé d'incrémenter la position pixel par pixel (l'incrément est calculé en fonction de la vitesse), par contre il faudra peut être faire certains calculs avec des float.

Le problème auquel je suis confronté, est que je n'ai pas choisi de fame-rate du coup mon programme utilise beaucoup de processeur et lorsque j'utilise un SDL delay pour appliquer une pause très faible cela gène le jeux et plus particulièrement les flippers(palettes qui renvoient la bille) qui ne réagissent pas instantanément.

Merci d'avance de ton aide.

[nanosoft]

Bonjour,

float k;
Alors je fais le rapport k=vx/vy et suivant le resultat,
--->if(k<1){ vx+=k ;vy+=1;}
--->if(k>1){ vx+=1 ; vy+=(1/k);}

Je ne comprends pas bien ta méthode.
Si vx et vy sont les coordonnées de ton vecteur vitesse : lors d'une collision il faut changer l'angle du vecteur.
C'est ce que tu veux faire je pense en faisant le rapport vx/vy et en testant le signe, mais les affectations ensuite me paraissent bizarres.

Si tu veux bien gérer l'angle de rebond, c'est de toute façon plus facile à dire qu'à faire
Mais je vais creuser car j'avais justement en projet également un flipper !

Concernant la variable temps : c'est justement en relation avec le frame-rate et cela peut servir à synchroniser des animations : par exemple je contrôle certaines animations par des callbacks de timer avec en paramètre l'instant de début et de fin.

lorsque j'utilise un SDL delay pour appliquer une pause très faible cela gène le jeux

Le problème, si tu ne gères pas de frame-rate, c'est que le délai que tu rajoutes est constant ( et présent même quand il ne le faut pas).
Le principe du frame rate est de rajouter un délai contrôlé pour avoir une durée de boucle principale constante.

Je te recommande vivement de prendre ce principe.

[all_in]

Bonjour, Encore merci de repondre

Je ne comprends pas bien ta méthode.
Si vx et vy sont les coordonnées de ton vecteur vitesse : lors d'une collision il faut changer l'angle du vecteur.
C'est ce que tu veux faire je pense en faisant le rapport vx/vy et en testant le signe, mais les affectations ensuite me paraissent bizarres.

Dans ma methode vx,vy sont des vecteur qui s'incrementent en parralele en faite pour verifier a chaque pixel si il y a colision ou non.
vectX vectY disons sont mes vecteurs de balle.
Dans ma fonction j'ai créer vx ,vy que je vais incrementer selon les conditions si la bille est proche du rebord et qu il y a collisions j'arrête l'incrementation et je change le sens de ces vecteurs, sinon je continue tant que vx!=vectX et vy!=vectY

Si tu veux bien gérer l'angle de rebond, c'est de toute façon plus facile à dire qu'à faire

Voila j'ai un gros problème comme mes formes sont diverses et pas régulière j'ai placé 8 points sur ma balle mais les rebond se font toujours de la même manière je n'arrive pas a trouver une bonne maniere pour gerer un angle de rebond

Le problème, si tu ne gères pas de frame-rate, c'est que le délai que tu rajoutes est constant ( et présent même quand il ne le faut pas).
Le principe du frame rate est de rajouter un délai contrôlé pour avoir une durée de boucle principale constante.

Je vais regarder ça sur le net, j'ai jamais fait mais le principe me parfait très bon

[pfeuh]

Salut,

Le principe du frame rate est de rajouter un délai contrôlé pour avoir une durée de boucle principale constante.

Je ne connais qu'un tout petit peu la SDL, mais l'idéal ne serait-il pas d'avoir un callback sur le retour du transfert vers la mémoire vidéo? Sur les 8 bits d'il y a trente ans, (l'Atari 800, au hasard) l'OS pétait une interruption au blanking vertical, on pouvait y accrocher une callback pour retravailler l'image pendant que la vidéo ne se dessine pas.

A+

Pfeuh

[nanosoft]

Bonsoir,

Je ne sais pas si la SDL date de trente ans !

Sur le frame-rate, il y a un tuto sur le site :
http://loka.developpez.com/tutoriel/sdl/frame_rate/

Mais on n'est pas obligé d'utiliser un timer, on peut prendre des instants avec SDL_GetTicks() et rajouter un SDL_Delay en fonction.

Pour la mémoire vidéo cela dépend de l'init de l'écran en SDL_SWSURFACE ou SDL_HWSURFACE.

pour retravailler l'image pendant que la vidéo ne se dessine pas

C'est le principe avec SDL_Flip.

(PS : il y a un forum dédié sur la SDL)

[ternel]

SDL_flip est l'application à SDL du principe général de double-buffering, qui consiste effectivement à avoir deux images, l'un pour l'affichage, l'une pour l'édition.

[pfeuh]

Salut,

merci beaucoup, ça devient tout de suite plus clair!

A+

Pfeuh

[all_in]

Merci de vos réponses et du tuto sur le frame-rate qui est très intéressant.
je gère ceci maintenant dans mon flipper

Voici comment j'ai fait pour 25 images secondes

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
 
     unsigned int interval
     unsigned int dernierTemps=SDL_GetTicks();
 
    //COLISION    collision(&Gball, couleurs);
    /*********FONCTION ACTUALISATION*********/
        Evoluer(&ball, ball.vectx, ball.vecty);
        blitNew(ecran,ball, pld, plg, base, posflipp,decor,indiceg,indiced);
 
 
        while(SDL_Flip(ecran)!=0) 
            SDL_Delay(1);              
        interval = SDL_GetTicks()-dernierTemps;
        if (interval<40)
            SDL_Delay(40-interval);

J'ai une question pour mon flipper comme il est en 3D, je voudrais savoir si il est possible pour gérer les collisions sur les cotés du flipper qui sont obliques.
Je voudrais en gros savoir si la balle touche le rebord ou pas en regardant si la balle est a gauche ou a droite du trait car mon flipper n'a pas des bords verticaux (il suffirait alors d une simple condition) si a gauche de la position x alors il y'a collisions) .

En gros peut-on tirer un trait oblique en SDL et ainsi contrôler les collisions par rapport a ce trait.


http://famille.vigne.pagesperso-oran...it_oblique.jpg

[nanosoft]

Bonsoir,

J'ai une question pour mon flipper comme il est en 3D

Il est vraiment en 3D ou en 2D avec un effet de perspective "isométrique" ?

En gros peut-on tirer un trait oblique en SDL et ainsi contrôler les collisions par rapport a ce trait.

Oui, tu peux même aller plus loin et définir des polygones et tu testes si un point (le centre de la bille) est à l'intérieur du polygone (mais c'est une fonction plus gourmande que avec des rectangles).
La bille est un cercle (c'est un avantage) tu devrais pouvoir définir des limites de positions par rapport au centre.

Il y a différentes techniques pour gérer les collisions, documente-toi un peu plus avant de choisir une conception.

[all_in]

Ok merci de la reponse, je vais voir si je peux trouver des infos et je reviens ous voir si j'ai des soucis.

Il est vraiment en 3D ou en 2D avec un effet de perspective "isométrique" ?

oui c'est juste un effet de perspective. J'ai fait une modélisation de la carte sous un logiciel de modélisation 3D et j'ai ensuite pris un rendu de la carte ce qui a permis d'obtenir un bon effet avec des ombres ect.