Moteur 2D - Page 3

Pour les pouvoirs de Mario:
1. Mario peut courir. Dans n'importe quel Mario.
2. Dans Super Mario 64, Mario peut bondir d'un mur.
3. Depuis Super Mario Bros. 3, Mario peut voler.
4. Mario peut courir verticalement depuis Super Mario World (il suffit d'avoir le moyen de monter, dans Super Mario World, ce sont les blocs triangulaires qui permettent ça) et dans Yoshi's Island, il peut même faire des loopings (quand on prend une étoile, ce qui le descend de Yoshi et lui donne ces pouvoirs-là).

Effectivement...

Ximoon> C'est beaucoup, je trouve 4 pxl de déplacement horizontal...

Parce que c'est quoi comme jeu Ximoon?

Mega Man

Aha! Et il y'a des plate-formes inclinées?

NON

Sonic dans SMA se deplace de 16 pixels/frame max (Ca fait quand meme gros beuf). Mais ca peux egalement etre 16x2.
Le test pixel par pixel est valable.

Le decolage de ce genre de truc se fait normalement lorsque la vitesse selon Y est superieure a la vitesse de decolage

Sinon tu peux editer des niveaux de SMA pour comprendre comment ca marche.

>Mais il ne restait plus qu'à "faire coller sonic au plafond" dans les cas où cela s'appliquait.
C'est le plus complique

Désolé mais j'arrive pas à jouer à SMA! Le prog ne démarre même pas!
>>Mais il ne restait plus qu'à "faire coller sonic au plafond" dans les cas où cela s'appliquait.
>C'est le plus complique
Ca je n'en doute pas

>Le decolage de ce genre de truc se fait normalement lorsque la vitesse selon Y est superieure a la vitesse de decolage
Je ne comprends pas... Tu as pas un truc plus proche du jeu lui-même? Moi je pensais utiliser des listes (pour indiquer la perte de vitesse sur la plate-forme), par ex:
{0,1,0,1,0,1,0,1,0,...
pour une plate-forme triangulaire. Donc si la vitesse du perso est supérieure à ... 80% de la vitesse max et que la valeur de décélération est suffisante, alors on transpose la vitesse du perso moins un petit offset dans la variable SAUT_OBLIGATOIRE (la même que j'utilise pour les bumpers, les ennemis, ...)

Pour le "collage au plafond", je pensais faire déjà un "type" qui s'appellerait "plate-formes de pendu" ou un truc du genre pour les identifier. Tout comme les plate-formes inclinées ont leur type (81-96), les passe-bas leur type (41-80), les murs aussi (1-40), les types "mort subite" (64-80), etc.
Après lorsque en plein saut, Sonic rencontre une plate-forme de type "pendu", alors on transposera son SAUT_OBLIGATOIRE à nouveau sur sa vitesse (variable de ce nom donc). Un flag pendu de son nom indiquera que c'est le cas et là si Sonic n'a plus une vitesse suffisante (0 ou 1 ou -1 pitet) alors il est plus pendu (=faux).

Tu as installe preos d'abord ? Ca suffit pour faire fonctionner SMA. Essaye le et tu verras ce que tu dois faire pour le depasser.

LE principal pb est que sonic est contraire aux lois de la physique: ces loopings ne devraient pas marcher mais ils marchent. Il faut donc bidouiller.

Quant a t'expliquer le moteur. Je l'ai ecrit il y a 2 ans, et c'etait tres complique (Mis au point sur la plage le 20 aout). Va lire les sources de SMA (spr_sonc.asm). Y'a des commentaires.

le probleme de ton idee est que ca limitera fortement les niveaux (Comme les sonic master system) compare aux sonic megadrive, si tu vois ce que je veux dire.

>le probleme de ton idee est que ca limitera fortement les niveaux (Comme les sonic master system) compare aux sonic megadrive, si tu vois ce que je veux dire.
Non je ne vois pas en quoi ça limiterait les niveaux...
>Tu as installe preos d'abord ? Ca suffit pour faire fonctionner SMA. Essaye le et tu verras ce que tu dois faire pour le depasser.
J'ai installé préOS mais ça démarre toujours pas (et j'ai mis 50 librairies).
>Quant a t'expliquer le moteur. Je l'ai ecrit il y a 2 ans, et c'etait tres complique (Mis au point sur la plage le 20 aout). Va lire les sources de SMA (spr_sonc.asm). Y'a des commentaires.
Ca signifie que tu l'as commencé en BASIC? Moi aussi mais c'était très limité. Tu pourras voir une démo dans les clex (exemples de clib). C'est sur mon site (section progs TI -> programmation -> clib) Sinon c'est sympa de distribuer la source!

Ben mon code c'est assez différent et c'est pas moitié en français, moitié en anglais (tu viens d'où?) . Tu peux aller voir la source de mon Mario3 en développement http://www.isuisse.com/brunni2/mario3src.zip.
ATTENTION: IL EST EN DEVELOPPEMENT ALORS EVITEZ DE ME SIGNALER DES BUGS!

[Edition] Ah! Il reste encore des variables (et utilisées en plus) du type enboule dans mon Mario, spécialement prévues pour Sonic. Poilant!

- (voir plus haut)
Quelqu'un pourrait pas le supprimer ce post?

Brunni :
>Tu as installe preos d'abord ? Ca suffit pour faire fonctionner SMA. Essaye le et tu verras ce que tu dois faire pour le depasser. J'ai installé préOS mais ça démarre toujours pas (et j'ai mis 50 librairies).

Une seule suffit, stdlib

>Quant a t'expliquer le moteur. Je l'ai ecrit il y a 2 ans, et c'etait tres complique (Mis au point sur la plage le 20 aout). Va lire les sources de SMA (spr_sonc.asm). Y'a des commentaires. Ca signifie que tu l'as commencé en BASIC?

Je ne vois pas le rapport

Tu peux aller voir la source de mon Mario3 en développement http://www.isuisse.com/brunni2/mario3src.zip. ATTENTION: IL EST EN DEVELOPPEMENT ALORS EVITEZ DE ME SIGNALER DES BUGS!

Très pratique pour les corriger
Si tu ne veux pas être mis face à tes bugs, fais comme Pollux, ne release que lorsque tu es sûr qu'il n'y en a aucun (cad jamais )

-

Heu oui. Le projet s'appelait Sonic au départ. Et je n'ai pas eu le courage de tout renommer. Je ne sais pas ce que contient Copie de sonic.c. C'est soit le début du moteur de Sonic, soit... une très vieille version du Mario actuel.

PpHd
: LE principal pb est que sonic est contraire aux lois de la physique: ces loopings ne devraient pas marcher mais ils marchent. Il faut donc bidouiller.

Il suffit de définir une force centrifuge supérieure à la force de gravité.

1. Mais la force centrifuge est une force induite par la vitesse du mobile. Si la vitesse est horizontale, la force centrifuge hozirontale est nulle, donc ca merde.

2. Non j'ai fait Sonic direct en asm.

3. Tu as installe Preos 0.67 et stdlib, que tu as archive, tu as lance preos, et il t'a affiche Install done, et tu as envoye sma.89z, chaos1, chaos2 chaos3, chaos4, (Tout quoi) de SMA v0.41 ?

mais la force centrifuge n'est elle pas du à la force de coriolis ? Et celle-ci n'est elle pas nulle en cas de mouvement rectiligne (je sais plus si il faut qu'il soit uniforme ou non)

Si, elle est nulle dans le cas d'un mouvement rectiligne (uniforme ou non)

enfin tout ça pour en venir au fait que je ne comprends pas ce que veut dire PpHD par

la force centrifuge hozirontale est nulle, donc ca merde.

Coriolis, c'est 2 oméga vectoriel v où oméga est le vecteur rotation et v le vecteur vitesse, donc l'accélération de Coriolis est nulle si et seulement si ces deux vecteurs sont colinéaires.

Hum, comme t'es sur une parabole, je pense qu'on peut plus simplement estimer
Fic = 2.r(t).Omega²
(possible que je me plante)

Je ne comprends rien!
Mais bon... Pour l'histoire du saut fait par une de ces plate-formes comme l'image ci-dessous:

je fais simplement faire un saut de 1 pixel à Sonic, plus encore sa vitesse courante lorsqu'il la quitte avec une vitesse >0 (donc en marchant vers la droite)

mais la force centrifuge n'est elle pas due à la force de coriolis ?

Non. La force centrifuge est un cas particulier de la force d'inertie d'entraînement.
De toute manière, les forces d'inertie sont nulles si l'accélération du référentiel l'est (autrement dit si le référentiel est galiléen), ce qui est a priori le cas ici.
Donc je ne comprends pas du tout le post de Kevin , à moins qu'il ne prenne Sonic lui-même comme référentiel ? pour gérer la rotation du sprite alors ?
Ou alors on n'appelle pas la même chose force centrifuge...

Il y a les forces d'inertie des repères par rapport aux galiléens mais aussi les forces appliquées directement aux solides en déplacement (ici Sonic).
Coriolis ne s'applique en gros que lorsqu'on s'éloigne ou se rapproche du centre instantané de rotation dans un repère en rotation, et est proportionnel à la vitesse. On s'en fiche ici car le décor est supposé galiléen.
La force centrifuge (en fait elle est axifuge ) n'existe en fait pas en tant que telle, elle correspond juste à l'accélération radiale qui existe dans tout mouvement circulaire, par définition.

La force centrifuge (en fait elle est axifuge )

Oui, mais en l'occurence on est en 2D, donc non en fait

n'existe en fait pas en tant que telle, elle correspond juste à l'accélération radiale qui existe dans tout mouvement circulaire, par définition.

Pour moi, ce qu'on appelle "force centrifuge" est la composante radiale de la force d'inertie d'entraînement ; elle n'existe donc que dans un repère en rotation, donc pas ici.
Effectivement, peut-être que Kevin a voulu parler de l'accélération radiale, mais je ne comprends quand même pas très bien son post...

C'est bien pour ça que je dis que c'est une pseudo force qui est ressentie alors qu'elle n'existe en fait pas... Mais le fait est que c'est quand même ça qui devrait faire coller Sonic aux loopings s'il respectait les lois de la physique, ce qui n'est pas le cas: si on regarde les basses vitesses dans Sonic II par exemple on voit bien qu'il reçoit des impulsions dans certains tuyaux pour l'aider à monter

ben oui, pauvre bête quand même, c'est que c'est pas facile de grimper au mur, de courir de tout les sens...

Heu... Si vous regardez bien dans le II, il devrait meme pas marcher au plafond.

on voit bien qu'il reçoit des impulsions dans certains tuyaux pour l'aider à monter

Je vois pas de quels tuyaux tu parles (ou peut-être ceux de Chemical Plant comme dans le screenshot ci-dessous?)

Sonic reçoit des impulsions dans des endroits du style le tuyau (à sa gauche dans l'image ci-dessous) mais que dans Sonic 1 à ma connaissance:

Heu... Si vous regardez bien dans le II, il devrait meme pas marcher au plafond.

Alors là! Je ne vois pas quand est-ce qu'il marche au plafond