Jeu de plateforme - Page 5

geogeo, le problème des sauts pour sortir de l'eau (./92) s'applique même pour un Mario!

Je retire ce que j'ai dit!
Moi pollux m'a convaincu.
C kler que les tables ne sont pas les meilleurs solutions.

yep, toute façon à partir de maintenant je vais abandonner les tables pour les sauts avec formules.

ben voilà, comme quoi c pas la peine de se vexer en croyant qu'on veut vous insulter ou vous ridiculiser

geogeo >

Une première version bêta est disponible, avec le premier niveau ( non définitif )... Téléchargeable à l'adresse : http://vincent.corfdir.online.fr/ressources/wizz_beta1.zip.

Touches :

- flèches directionnelles
- 2ND : sauter
- Diamond : parachute ( une fois en l'air )
- alpha : pause

NB : Une fois baissé ( dans son chapeau ), le magicien est en sécurité.

[edit : j'ai oublié les touches :$]

Pas mal, le jeu donne bien.
Par contre, il m'a fallu un bon moment à l'écran titre pour trouver qu'il fallait appuyer la touche droite pour commencer
Le truc qui me gêne un peu, c'est de ne pas pouvoir retourner en arrière. Si tu ne veux pas gérer de scrolling dans les deux sens, tu pourrais au moins permettre au personnage de se déplacer sur l'écran comme Super Mario Bros hm?
Bon je sais ça risque d'être dur de modifier ça suivant comment à ce stade du jeu... (si tu as fait tous tes tests de collisions avec Scroll_x/largeur_bloc)
geogeo> Personnellement, je ne suis pas intéressé de DASM les jeux et quand je vois ce que tu dis encore moins. Même si des développeurs le font, ce n'est (visiblement) pas forcément une bonne idée...
Sonic par exemple n'utilise QUE des lois physiques (si Pphd voit ça il va me tuer, car il pense que c'est un bidouillage complet, lui ). Pas la moindre table, pas le moindre bidouillage. Et je peux te dire que c'est LARGEMENT plus simple que de faire des tables, puisque les lois physiques donnent TOUJOURS une réponse à toute éventualité, tandis que les tables ne prévoient pas tout et là c'est plantage (bug) garanti au moindre problème... Et au moins avec les formules, on sait tout de suite si on est sur la bonne voie -> résultat absolument identique à l'original sans DASM ou reverse engineering

Moi perso, je ne le trouve pas génial, enfin ce n'est peut-être qu'une beta.
Le jeu en lui-même n'apporte rien, je trouve, on avance sur des plates-formes et on saute sur les ennemis. Vu et revu (et monotone)

D'ailleurs je crois que c'est son premier jeu de plate-forme, alors je pense que c'est bien de l'encourager, d'autant que techniquement c'est pas mal.
Forcément, les idées manquent, mais ça va s'améliorer, car ce n'est qu'une bêta

D'ailleurs, tu utilises quoi comme lib ? OrageGL ?

Brunni>Merci
Sasume>J'utilise extgraph pour le moment ( fonctions de sprites masqués et clippés ), mais je bosse parallélement sur OrageGL, et je vais sûrement utiliser des fonctions de cette lib. Pour le jeu, c'est vrai qu'il n'inove pas trop mais je vais essayer de trouver d'autres interractions.

Il est vraiment bien !

Dommage que ca plante sous PedroM...

merci ... Mais il plante sous pedrom arf... Et c'est quoi comme plantage ( quand on quitte, dans le jeu, lors d'une action ? )

il utilise peut être des romcalls 2.xx ?

a tiens, bizarre, y a un screen sous pedrom sur le site...

Ximoon > quelle est ta méthode pour gérer de manière réaliste les collisions lors d'une chute, quand le delta_y est plus grand que la distance qu'il reste à notre perso pour toucher le sol ? Tu calcules des trucs dès le départ ?

Ximoon> Euh non, je ne crois pas.
Pim89> Pour calculer les colisions avec le décors ? C'est une carte de précision 8 pixel, et le moteur vérifie en permanance sous ses pieds il y a bien du sol. Si le sol arrive plus tôt que prévu, il y a une variable d'accélération ( pour les chutes ) qui est réinitialisée à 0... Mais ce n'est encore pas trop au point, je pense modifier le système.

ça donne une sorte d'accoup au moment de toucher le sol ?

Je vois ce que tu veux dire Pim89. Mais si tu débutes, je ne te conseille vraiment pas de faire cela... Tu peux faire un moteur en pixel par pixel que tu exécutes max(delta_x,delta_y) fois. C'est beaucoup plus simple.
Mais si tu tiens tout de même à faire un moteur du style... -> en réfléchissant, si le personnage se trouve sur une plate-forme plate, alors ses pieds seront toujours à une position y multiple de 8 (la largeur de tes blocs), tu es d'accord?
Pour simplifier, prenons que ton personnage fait 16 pixels de hauteur (c'est un peu plus compliqué s'il n'en fait pas un multiple de 8). Si le personnage est à la position y 26, tu vas vérifier dans ta matrice aux positions (y+hauteur_perso)/8 s'il y a un "mur"... ici cela donne 5 (entier). Prenons qu'il y a un mur ici. Il faut maintenant "monter" ton personnage de manière à le faire passer dessus la plate-forme en question, ok?
Et là, c'est très simple: tu verras tout de suite que si tu arrondis sa position y à un multiple de 8, alors le perso passera bien au-dessus, c'est à dire à la position 24. Si le personnage fait 39 pixels de haut par exemple (Sonic ), il faudra calculer de manière à ce que juste le plat de ses pieds (mais pas sa tête donc) soit à une position multiple de huit.
Ce type de moteur est plus difficile à gérer et ne convient pas à certaines applications. Par exemple, pour Sonic, il est quasiment impensable de faire un moteur qui fonctionne correctement de cette manière car la moindre imprécision est inadmissible (il faut penser que son point d'appui n'est pas forcément le bas, qu'il y a les plate-formes très inclinées, etc.); il faut impérativement passer en pixel par pixel si tu n'es pas sûr de ce que tu fais... Mais pour Mario, alors il n'y a pas de problème.
Pour conclure, je dirais que ce moteur consomme infiniment moins de processeur par contre est généralement moins stable. A toi de voir

heu, oui, mais ça répond à moitié à ma question, quel est le paramètre qu'on gère concretement éviter l'accoup, quel calcul concret fait on pour que notre delta_y fasse que notre perso va toucher pile poil une plate forme sans accoup ?

que veux tu dire par moteur "pixel par pixel" ?

Ben un moteur qui fait s'avancer le personnage d'un pixel à la fois. Tu n'as pas de problème de détection (ou pas de raison d'en avoir) ainsi. Tandis que si tu as des distances trop grandes et que tu les fais d'un coup (plusieurs pixels à chaque fois), la détection de collisions sera plus difficile à coder et même, tu risques de passer à travers certaines plate-formes sans les voir sous certaines conditions...

heu, oui, mais ça répond à moitié à ma question, quel est le paramètre qu'on gère concretement éviter l'accoup, quel calcul concret fait on pour que notre delta_y fasse que notre perso va toucher pile poil une plate forme sans accoup ?

D'abord, tu fais descendre le personnage, ensuite tu détectes les collisions et tu le remontes si nécessaire...
[affichage], y vaut 24
-> gravité, y passe à 26
-> détection de collisions et remontage, y passe à 24
[affichage], y vaut 24, rien n'a changé
Il n'y a pas d'accoup de cette manière

Pim89 :
heu, oui, mais ça répond à moitié à ma question, quel est le paramètre qu'on gère concretement éviter l'accoup, quel calcul concret fait on pour que notre delta_y fasse que notre perso va toucher pile poil une plate forme sans accoup ?

que veux tu dire par moteur "pixel par pixel" ?

par exemple, si pendant la chute le perso doit se déplacer de delta_y, alors que la finesse du masque de collision est de 4, je fais des tests de collisions à y0, y0-4, y0-8, etc et je m'arrête à la première coordonnée qui a un impact, ou à y0-delta_y.
Une fois le y_final réel calculé, je mets à jour les coordonnées réelle de mon perso.

>Sonic par exemple n'utilise QUE des lois physiques (si Pphd voit ça il va me tuer, car il pense que c'est un bidouillage complet, lui ). P
Nan. Un melange de gros bidouillage et et de lois physiques a 2 balles.

Nan. Un melange de gros bidouillage et et de lois physiques a 2 balles.

Bah, je ne vois pas ce que tu veux dire par "à deux balles"? C'est le modèle standard selon mon prof. Sauf que les constantes sont assez space (et son facteur de vitesse surtout) pour lui permettre de faire des trucs hors du commun, mais qui restent toujours physiques malgré tout!
Enfin, si tu dis que c'est un bidouillage en ayant DASM le jeu, alors je te crois, mais sinon le doute persiste...

bah, c simple, tu peux pas tenir les pieds au plafond tout en courant dans la réalité

_______________________
 Y                  \
                     \
                     X|
----------------------------------

X represente le point de depart de Sonic ds Sonic 3. La tu sautes. Tu montes au plafond, ta vitesse est franchement lente, mais tu arrives quand meme au point Y.

Là je suis d'accord. Normalement, ils auraient du faire un calcul, mais #flemme# powaa, ils ont apparemment fait que dès qu'ils détectent une plate-forme inclinée de type plafond, il y collent Sonic. Je pense qu'ils devaient avoir des problèmes avec leur moteur de collision pour avoir implémenté cela...

bah nan, le truc c que dans sonic tu peux marcher courrir sur toute surface plane ou courbe peu importe son inclinaison, mais que à inclinaison != 0, la vitesse augmente (si sonic est dans la pente) ou diminue (si sonic remonte une pente) au cours du temps (par contre la façon dont elle varie est un peu plus complexe...)

Brunni :
Le truc qui me gêne un peu, c'est de ne pas pouvoir retourner en arrière. Si tu ne veux pas gérer de scrolling dans les deux sens, tu pourrais au moins permettre au personnage de se déplacer sur l'écran comme Super Mario Bros hm?

J'ai essayé de faire quelque chose pour ça. Maintenant, on peut se "promener" un petit peu : quand l'abscisse du perso dépasse 1/3 de l'écran, il avance sur la carte.

Voilà la nouvelle bêta : http://vincent.corfdir.online.fr/ressources/wizz_beta2.zip
Screen disp : http://vincent.corfdir.online.fr/images/ti/wizzard/wizz_beta2.gif (0.6 Mo)

En ce qui concerne la vitesse, c'est peut être un peu rapide, car je n'affiche qu'une image sur deux. Qu'en pensez-vous ?

J'ai essayé de faire quelque chose pour ça. Maintenant, on peut se "promener" un petit peu : quand l'abscisse du perso dépasse 1/3 de l'écran, il avance sur la carte.

Ah tu l'as fait... bravo!
Sinon ça a l'air bon mais faut voir sur vraie TI si ce n'est pas trop rapide (vu que c'est déjà limite sur VTI)

bah nan, le truc c que dans sonic tu peux marcher courrir sur toute surface plane ou courbe peu importe son inclinaison, mais que à inclinaison != 0, la vitesse augmente (si sonic est dans la pente) ou diminue (si sonic remonte une pente) au cours du temps (par contre la façon dont elle varie est un peu plus complexe...)

quelque chose de ~plus ou moins~ correct://Calcule l'augmentation de vitesse (cela peut également être une diminution) augVitesse=(s->A*ABS(cos(s->angle))-G*sin(s->angle));Effectivement, mais ça reste physique. Bon ok perso je n'ai pas trouvé comment gérer ça alors je joue avec les signes et ça me donneSinon, Sonic peut normalement "coller" à une pente du moment que la force qui le maintient au sol (ça doit être la centrifuge) est suffisante. Mais dans le jeu ils ont apparemment simplifié: il peut le faire si sa vitesse n'est pas nulle...