Discussion :

[skhay]

Bonjour,
Voila, je me met à la programmation d'un shoot them up avec SDL.
J'aimerais savoir comment je peux faire pour définir des trajectoires à mes sprites (ennemies) comme, les faire tourner en huit, les faire arriver en file indienne de la gauche de l'écran puis qu'ils se retrouvent en haut de l'écran en formation "triangle"... etc
Je ne sais pas si vous connaissez "Critical mass - Critter" qui est un très bon shoot'em up, je voudrais faire évoluer les ennemies un peu de la même facon, merci d'avance

[Fiquet]

Salut,

Je suppose que tu connais déjà le principe d'affichage de SDL, et que tu peux définir la position d'un sprite au blit grâce à un SDL_Rect. Si oui ta question est plus de l'algorithmie. Les déplacements ce n'est ni plus ni moins que des changements en X et Y. Si tu veux des algos pour faire des formes spéciales, je pourrais déplacer ton sujet sur le forum algorithmie plus approprié .

[bafman]

un methode simple et puissante pour gerer les deplacement de tout objet :
chaque objet a un vecteur deplacement {x,y} et une position.
le vecteur de deplacement pointe toujours vers la destination, et à chaque mise à jour de l'objet, il suffit de faire
position = position + deplacement
et voila ton objet va tout seul comme un grand vers sa destination...
un gros aventage de cette methode est qu'elle permet tres simplement d'ajouter des "truc" simpa comme de la gravité, ou la gestion simple de collisions

[fearyourself]

un methode simple et puissante pour gerer les deplacement de tout objet :
chaque objet a un vecteur deplacement {x,y} et une position.
le vecteur de deplacement pointe toujours vers la destination, et à chaque mise à jour de l'objet, il suffit de faire
position = position + deplacement
et voila ton objet va tout seul comme un grand vers sa destination...
un gros aventage de cette methode est qu'elle permet tres simplement d'ajouter des "truc" simpa comme de la gravité, ou la gestion simple de collisions

Je fais pareil que toi sauf que j'ajoute toujours le temps (et je me doute bien que tu l'ajoutes aussi ) dans le calcul du déplacement. Finalement, j'ai un vecteur Vitesse qui donne la direction du mouvement et je calcule le déplacement en faisant: Vitesse*Temps. Cela permet d'avoir une vitesse constante par rapport aux différents ordinateurs que j'utilise pour mes tests.

Jc

[bafman]

en fait pour la prise en compte du temps tu a plusieurs possibilitée :
- prendre en compte le temps dans le calcule du deplacement
- prendre en compte le temps lors de l'appel de l'update (l'update se faisant à horaire regulier (24 fois par secondes par exemple), on a plus a prendre le temps en compte lors du deplacement)

chacune des methode ayant ses aventages et ses inconvenients...

[skhay]

Ok merci, je vais réfléchir à tout ca et je vais allé faire un tour dans la section algorithmique alors...

[loufoque]

SDL n'étant pas sous-pixel on ne peut pas appliquer des calculs normaux de trajectoire, il faut prendre les approximations entières.
C'est un peu chiant mais on se débrouille en travaillant avec des suites de translations sur des pixels.

[mat.M]

[quote="loufoque"]SDL n'étant pas sous-pixel quote] ?
Que veux-tu dire par là ? On peut accéder aux pixels d'une image avec SDL ...

[fearyourself]

SDL n'étant pas sous-pixel on ne peut pas appliquer des calculs normaux de trajectoire, il faut prendre les approximations entières.
C'est un peu chiant mais on se débrouille en travaillant avec des suites de translations sur des pixels.

Je pense qu'il parle du problème que lorsqu'on fait un blit on donne une position en entier, or généralement la position du sprite est en flottant (plus précis pour le calcul du déplacement).

Je ne trouve pas que c'est un problème, je fais tout en flottant et juste avant le blit je passe en entier...

Jc

[Sivrît]

Je pense qu'il parle du problème que lorsqu'on fait un blit on donne une position en entier, or généralement la position du sprite est en flottant (plus précis pour le calcul du déplacement).

Idem.

Je ne trouve pas que c'est un problème, je fais tout en flottant et juste avant le blit je passe en entier...

C'est probablement la meilleure solution tant qu'on a assez de puissance de calcul, et avec les machines actuelles c'est généralement le cas. Mais quand on se lance dans du GigaWing like et autres joyeusetés et qu'on a des centaines ou des milliers de sprites le coût des conversions devient non négligeable


Pour les trajectoires, une solutions générique conciste à donner des points de passage puis à faire une interpolation entre ces points (tout simplement linéaire pour faire simple, ou polynomiales pour avoir plus rond etc.)
Ca permet avec un minimum de travail de définir n'importe quelle trajectoire (même complexe) sans rajouter du code. Par contre pas de réactivité et peu d'aléa.
Sinon il est possible de jouer avec des sinus pour les ennemis qui arrivent en zig-zag, voir même en huit mais il faut s'accrocher.

Pour les tirs, il y a bulletML à regarder. 8)

[loufoque]

Je ne trouve pas que c'est un problème, je fais tout en flottant et juste avant le blit je passe en entier...

Disons que tu veux déplacer un objet placé en (x, y) dans une ligne droite définie par un angle α, le tout sur une distance d.
Tu obtiens donc les nouvelles coordonnées (x', y') ainsi :
x' = x + d*cos(α)
y' = y + d*sin(α)
Problème : le sin et le cos sont entre -1 et 1. Si d est trop faible, ça bouge pas.