Petit problème

[YoGi]

Salut,

je tente de faire un petit jeu du type puzzle bubble en Java (Glop, pas de remarque ), et là je bloque sur un point précis depuis 2 jours, donc sachant que je ne sais plus trop quoi faire je viens m’adresser à vous, ô maitres du pointeur et autres joyeustés.

Avant de rentrer dans le vif du sujet, sachez que je pense que c’est complètement indépendant du langage.

Ok, alors vous avez tous joué a puzzle bubble (ou l’excellent frozen bubble), dans l’idée, on dirige un canon, et on balance une « bulle » selon la direction du canon. C’est sur ce point très précis que ça merdouille. Je m’explique :
La rotation du canon permet d’obtenir un angle, si on suppose qu’il peut varier de 0 (tout à droite) a 180° (tout a gauche), ou, pour être plus précis puisque je travaille en radian, de 0 a PI (en passant par PI/2, qui est donc la position verticale).

Mon problème est ensuite de déterminer, a partir de cet angle en radian, la trajectoire de la bulle à partir de cet angle. Pour résoudre ce problème, j’ai tenté une approche « pas à pas » : je calcule le cosinus de cet angle pour obtenir la variation en X et le sinus de ce même angle pour la variation en Y. Et, a chaque itération, j’ajoute aux coordonnées de la bulle cette variation de X et de Y. Dans le principe ça marche très bien, en pratique c’est un peu différent.

Vous savez tous que le cosinus ou le sinus d’un angle, en valeur absolue, donne un flottant compris entre 0 et 1. A coté de ça, les coordonnées d’un point, en pixels, ben ce sont des entiers, 1, 2 , 3… mais pas des flottants. Donc, jusqu’à présent,j’ai arrondi les coordonnées obtenues (après ajout des variation de X et Y), mais le gros problème, c’est que du coup la trajectoire n’est plus précise du tout.

Sur un tel schéma (prenons l’axe des Y), elle peut adopter 2 positions : soit elle change (ce qui veut dire que la variation suite a l’ajout du sinus > ~0.51, qui est arrondi a 1), soit elle ne bouge pas (

Merci d’avance !

[Edité le 7/3/2003 par YoGi]

[use_writer]

Nan, c’est moi qui ait le dernier mot, à savoir :
LOCK !

Tsss, floodeurs, va !

[Moe]

Tchik tchiki boum

J’ai le dernier Moe ( matez le jeu de mot ).
Mon Dieu, vous me tentez trop là, faut locker si vous voulez pas que quelqu’un d’autre ait le mot de la fin.

Désolé …

[Glup]

Ploum.

" Et nan c’est à moi le dernier mot."

PS: bien bien ton post

[c0unt0]

pour finir (parce que j’aime bien avoir le dernier mots )

bonne reponses collegiale de … pas mal de monde en fait
le coup de ne faire la conversion qu’a l’affichage est LA solution (c’est d’ailleurs ce qu’il se passe dans 99.9% des cas sur la plus part des hardware de maintenant !)
l’autres remarque auquel ca me fait penser : float ou double ? float : tu ne fais pas de la physique nucleaire, tu a besoin d’une precision aux allentour du 2eme chiffre apres la virgule (vu que tu bosses en pixel a l’arrive, audela, c’est de la masturbation numerique !) donc utilise des float : c’est beaucoup beaucoup beaucoup plus rapide et tellement tellement plus petit…
une autres chose a prendre en compte c’est que le temps ecouller entre une frame et la suivante est rarement constant (surtout sur PC, ou l’utilisateur peut faire tout un tas de truc, et l’OS (win32/linux/macos/be/… meme combat !) aussi) donc tu a interets a prendre en compte le temps ecouler entre la frame courrante et la precedente :

si tu a une vitesse en unite par seconde :
tu fait position += vitesse * deltaT.
vitesse etant ta vitesse en u/s et deltaT, le temps ecoule entre la frame courrante et la precedante… comme ca, quelque soit la vitesse de la machine (lente, tres lente ou tres rapide) ta bulle mettra toujours le meme temps a parcourrir la meme distance.

pour la petite histoire, le coup de changezs d’echelle (tout multiplier par 10 ou 100 ou 15787562) marche bien et a ete tres utilise dans le temps ou le calcul en flotant etait interdit ! (trops leeeennnnnt…) et est toujours utilise en compression de donnees. Mais il ne faut pas oublier de diviser (par 10 ou 100 ou 15787562) avant d’utiliser tes valeurs pour l’affichage !.

enfin pour repondre a urdle : Si! les methode incrementiel ont encore un interets : dans la plus part des system temps reel (et les jeux en sont « en quelque sortes ») une methode incrementiel sera plus simple a implementer (mathematique parlant et algorytmiquement parlant) et souvent achement plus optimum en temps machines !

[YoGi]

Bon ben finalement en n’arrondissant pas a chaque itération ça marche bcp mieux, comme c’est étrange…
j’ai honte sur ce coup là, enfin, merci pour votre aide les gars !

[YoGi]

Merci pour ces infos Glop, j’y jetterai un oeil demain, de bonne heure et de bonne humeur.
Pour ta méthode Wild_cat, C_wizard m’a également soufflé la même, j’ai pas eu le temps de l’essayer mais je le ferais dès que possible, et te dirais si c’est plus efficace tel que je le vois, ça devrait etre mieux, mais pas encore parfait.

[GloP]

En plus c’est meme pas vrai J’aime bien Java, apres plusieurs annees profesionnelement on finit par s’attacher… mais c’est vrai que c’est dur de revenir en arriere quand on prend ses habitudes avec qqch qu’on trouve objectivement mieux… Effectivement en directx9, avec C# ca serait surement plus optimise, mais y a pas de raisons que ca marche pas en Java…

C’est plus un probleme pour Count0 que pour moi ca en plus … hehe… bon le probleme de comment tracer une droite entre deux points, sur une grille composee de pixels est un probleme pas mal classique. Par contre vous simplifiez trop avec vos histoire la C’est pas aussi simple que ca et pour faire une vrai jolie droite il faut se creuser un peu plus la tete… L’algo qui marche bien s’appelle algo de Bresenham. Tu applique l’algo et tu dessine ta boule, centree sur le pixel en question…

Bon je me dechire d’un lien avec une joli applet qui te demontre comment ca marche… la version qui est presentee la peut etre amelioree et ne te limite pas a cette page dans ta recherche mais juste Bresenham dans google t’amenera toute les pages que tu veux pour satisfaire tes envies de ligne droite

http://www.dcs.ed.ac.uk/home/stg/pub/L/lines.html

[Edité le 8/3/2003 par GloP]

[Wild_Cat]

Tu as essayé de gérer leur trajectoire en utilisant des floats, et en arondissant seulement quand tu as besoin d’afficher?
Un truc du genre (bon, je simplifie)

pos.x += speed * cos (angle); pos.y += speed * sin (angle); pos_disp.x = int(pos.x); pos_disp.y = int(pos.y); affiche_balle (pos_disp.y, pos_disp.x); [/quote] où pos.x et pos.y sont des floats, speed, pos_disp.x et pos_disp.y des int et affiche_balle la fonction d'affichage de la balle...

[ZGoblin]

Arrête moi si je dis des conneries car je n’ai pas tout à fait saisie quel était ton problème, mais tu dis que tu as du mal avec les arrondis, tu utilises bien des doubles (ou des floats) pour les coordonnées ? car c’est normalement, si tu multiplies des int avec des doubles ca donne un int donc tu as des erreurs d’arrondies (à moins de forcer le type).

Je ne suis pas sur de t’avoir aider mais j’ai essayé.

Une dernière chose, pour la petite allusion à GloP, je te conseille d’éviter le Java comme langage, les animations seront vraiment très lentes à moins d’optimiser à fond ton code, tes graphismes et tes animations, chose qui est vraiment très difficiles. Je n’ai encore jamais essayé mais le C# en DirectX me semble une très bonne idée pour garder le coté Objet du Java.

[YoGi]

Pour l’intersection, j’en suis pas encore là, mais merci
Pour le mouvement, je saisis pas très bien en quoi ta méthode résoudrait le probleme que je rencontre avec mon approche, a savoir l’arrondi des valeurs.

[urdle]

j’pense que sur les ordis actuels, la methode incrementielle ne se justifie plus, donc

1. pour savoir ce quelles autres bulles ta bulle intersecte, tu calcules si la droite intersecte les bulles
2. pour connaitre les coordonnées de la bulle dans son mouvement, tu multiplie la distance par sinus et cosinus. [edit : la distance depuis le point de depart]

voili voilà, j’espere etre clair
j’ai pas trop l’temps là, alors j’fait court :-/

[Edité le 7/3/2003 par urdle]

[Edité le 7/3/2003 par urdle]