Pour Sonic, je ne pense pas que le systeme donne de l´accélération : par contre il possible que pour un certain niveau de vitesse proche du max, les évenement de ralentisement dus à la gravité soient annulés. C´est le même principe que pour des bumpers. Il doit y avoir un flag qui dit que la gravité ne s´applique pas. Quant à savoir quand est-ce que le flag est mis ou enlevé, ça c´est une autre histoire...

Par contre les blocs de boucles génèrent autre chose au contact : ils modifient le repère de déplacement et passent à l´étape de rotation suivante pour peu qu´on les tape en étant dans le bon état (bon angle et vecteur vitesse dans la bonne direction). C´est pour celà que sonic ralenti dans les montées : le repère a changé, le vecteur vitesse engendré lors d´une pression de pad est le même, mais il vaut moins en x du coup.
D´ailleur ça reprend la "triche" dont on a parlé plus haut : les sprites des pentes sont arrondies, mais les surfaces sont droites et les pieds de Sonic mangent les coins...

Ce qui me fait plus pencher pour cette théorie, c´est le fait qu´un rétablissement au sommet d´une courbe se ferait en automatique sur une durée minimum, et que effectivement dans Sonic la distance entre un plafond sur lequel on peut marcher et un sol ne dépasse jamais un minimum.

reno_> l´idée des tout petits blocs est sympa mais pose un problème de granulosité : pour mon déplacement soit fluide, il faut que la variation en y induite par les blocs soit inférieure à mon déplacement actuel. En clair, le nombre de pixels à escalader doit être inférieur ou égal au nombre de pixels dont je me déplace à chaque frame. Sinon, je donne l´impression de sauter.
Autre problème de granulosité, si je réduis suffisament mes blocs pour garder une animation fluide, je me rapproche énormément d´un test de collision au pixel près sur une droite orientée librement. Bref je me retrouve à faire le test de collision que je voulais éviter en prenant des blocs au lieu des traits...
Remarque, ça reste pas con parce le nombre de tests serait moins important que pour une collision au pixel. La complexité du test ne change pas, mais il est quand même plus court.

Un autre moyen de faire de belles pentes, tres controlées (qui est finalement un peu comme Bézier, mais niveau en maths lycée suffisant)

--> Un polynome du 3e degré (ax^3 + bx²+cx+d).
Typiquement, vous avez 2 plateformes, une en haut (horizontale), et une en bas (horizontale aussi), vous voulez faire une jolie pente lisse sans cassures :
http://img376.imageshack.k.us/my.php?image=pentegh9.png

vous voulez cette belle courbe, elle sera de la forme : f(x) = ax^3 + bx²+cx+d
vous voulez que f(XA) = A, que f(XB) = B
Mais, comme vous voulez que la courbe soit plate au départ et a l´arrivée (pour éviter la cassure avec les plateformes horizontales)
vous voulez aussi que f´(XA) = 0 et f´(XB) = 0

Or la dérivée de f est : f´(x) = 3ax²+2bx+c
Vous avez un systeme de 4 équations, 4 inconnues que vous résolvez facilement : vous trouvez a,b,c,d.
--> Tout cela, vous le résolvez pendant l´init, pour ne pas perdre de temps pendant la boucle principale.

Applications :

Pour une position x donnée, vous savez tout de suite ou se trouve le sol : c´est f(x) -> 3 multiplications et 3 additions -> ultra rapide.
--> Vous savez immédiatement si un y donné est en dessous ou au dessus de la pente.
Vous avez immédiatement le sens de la pente, pour faire glisser le perso : c´est f´(x). Si vous voulez un vecteur, c´est (1,f´(x)) --> se démontre en passant en paramétrique.
Si vous voulez la normale a la courbe en un x donné (pour un rebons par exemple), c´est (f´(x),-1) (se démontre par un produit vectoriel).

Si vous voulez allez plus loin, et acoller des courbes, (acoller f et g par exemple), vérifiez que f(dernier_point) = g(premier_point) pour que les courbes se touchent, et aussi que f´(dernier_point) = g´(premier_point) pour qu´il n´y aie pas de cassures...

Voila comment utiliser les maths niveau lycée, qui a dit que ça ne servait a rien ?

godrik > oui, peut etre qu´on pouvait sauter, je voulais trop simplifier ça

touhizy > oui, le probleme que tu évoques est un vrai probleme, a savoir, a chaque frame, on se déplace de X pixels (on tabule, c´est inévitable)
Par contre, il faut que ce X soit plafonné, et qu´il soit inférieur a la largeur d´un tile (sinon, on risque de passer a travers les tiles)

Une astuce : si vraiment on doit se déplacer de X pixels en un temps dt, et que ce X est trop grand, mais inévitable, c´est de faire 2 déplacements dans la meme frame (sans redessiner, j´entends), 2 déplacements de X/2 dans 2 fois un temps dt/2.

pour Sylvaniah, nous utilisons des vecteurs pour les collisions, et non des bounding-boxes : cela permet en gros d´emuler n´importe quel type de terrain...

http://www.sylvaniah.com/

une petite question.
Tu (Fvirtman) parle beaucoup de mettre des courbes (polynome, bezier, ...). C´est facile de gerer les collisions avec ces betes la ? Parceque du coup, tu es completement vectoriel non ? Ca doit etre difficile de faire une intersection: rectangle/polynome quelconque. non ?

luxregina > Exellent jeu, ma foi ! Pile poil ce que j´essaye de faire à la base en fait...

Je vois comment représenter mon terrain à base de vecteurs mais comment tu fais pour le perso ? Je veux dire tu testes les intersections de vecteurs par rapport à quoi ? Le perso est représenté par un vecteur unique ?

Sinon, tu aurais de la doc pour ce genre de truc ? J´ai essayé l´ActionScript pendant un temps et j´avoue ne pas avoir la moindre idée de comment structurer mon code pour gérer ce genre de choses.

A part ça, côté animation, vous n´avez jamais étés tentés de placer des déplacement spéciaux dans les pentes ? Animation différente ou rotation de sprites...

Et pour info, vous êtes apparement deux à réaliser ce jeu en flash, ça vous a pris combien de temps ? Vous étiez formés à flash par des cours ou un boulot ?

et merci godrik de poser les questions qui m´intéressent à ma place ! :D

Pour gérer les collisions avec un polynome (car meme les béziers sont des polynomes), je dirais que ça dépend s´il est quelconque ou pas.

Dans le cas que je décris plus haut : vraiment la pente, il suffira de regarder si un des deux points d´en bas de la boundingbox est en dessous de la courbe.

Si on considere qu´on peut arriver par en bas, il suffira de regarder si le point hautgauche est au dessus et le point basgauche est en dessous, pareil pour le coté droit.

Apres, si la courbe est quelconque, c´est plus complexe, il faut calculer l´intersection de chaque segment de la bbox avec la courbe.

pour Sylvaniah, c´est vieux, je ne suis pas responsable du code, et n´ai pas le source sous les yeux, donc a prendre avec des pincettes

- il me semble me rappeler que le perso est lui aussi un vecteur, mais en faite, c´est de moindre importance - en AS, tu pourrais theoriquement avoir une collision entre une bounding-box et un vecteur, ou entre un bitmap et un vecteur a condition de "materialiser" ton vecteur par une ligne invisible ...

Il n´existe pas de tutorial complet sur Sylvaniah, mais le codeur en a mis un au point sur le scrolling engine de Sylvaniah :
http://www.strille.net/tu/tutorials/part1_scrolling.php

Sinon, pour les tutoriaux interessants, on revient toujours a Tonypa :
http://www.tonypa.pri.ee/tbw/tut24.html
mais par contre, son game-engine comporte des limites ( pentes a 45 degres seulement )

enfin, les tutoriaux de Metanet, connu pour leur jeu "N", qui est impressionnant de physique
(
http://www.harveycartel.org/metanet/n_screenshots/n-21.jpg )

les tutos
:http://www.harveycartel.org/metanet/tutorials.htm
l
le jeu
:http://www.harveycartel.org/metanet/downloads.htm
l

http://www.harveycartel.org/metanet/tutorials.html

et

http://www.harveycartel.org/metanet/downloads.html

et une application directe de leurs tutoriaux

http://www.harveycartel.org/metanet/tutorials/diagrams/tutB_demo04.html

Ooops, je realise que j´ai zappe tes questions :

part ça, côté animation, vous n´avez jamais étés tentés de placer des déplacement spéciaux dans les pentes ? Animation différente ou rotation de sprites...

il aurait fallu pas la rotation de sprite parceque c´est moche, mais des animations pour les pentes...

Disons que j´ai ete un gros feneant sur le coup

Et pour info, vous êtes apparement deux à réaliser ce jeu en flash, ça vous a pris combien de temps ? Vous étiez formés à flash par des cours ou un boulot ?

le jeu a pris environs 6 mois de devloppement, entre le concept et la version finale - mais 6 mois pas a temps plein : Strille a l´epoque etait etudiant ( maintenant il travaille comme codeur...dans une boite de jeux ) et moi, j´ai un boulot plein-temps.

Mais sur ces 6 mois, c´est pas le dev qui a prit le plus de temps ( car on utilisait un moteur ecrit par Strille, fait justement pour emuler un jeu Sonic - en gros, Sylvaniah, c´est son moteur Sonic a la sauce Luxregina ) mais le level design, car je n´ai jamais vraiment joue a des jeux de plateforme, donc j´ai fait pas mal de recherche sure les genres, etc, et pas mal de tatonnement en designant les levels pour le jeu ...

Le jeu en lui meme n´a jamais ete termine, seulement la demo : il n´y a que le niveau 1 - d´autres niveaux etaient ( sont ? Strille est toujours interesse ...) prevus pour avoir des environnements / physique differents ( je pense a un niveau avec de l´eau par exemple ...)
Je reviendrai certainement dessus une fois 2KH fini

d´ailleurs, voici le moteur "original" pre-Sylvaniah :

http://www.strille.net/works/misc/platform_demo/

Comme tu peux le voir, il y a pas mal d´elements sympas qu´on a laisse de cote, et avec lesquels on comptait jouer dans les niveaux supplementaires

godrik > je travaille énormément sur les courbes et les surfaces Bézier, B-splines, NURBS, polynomiales, Hermitiennes... pour le boulot (je manipule des modeles 3D CFAO : pas de triangles la, des BREP de surfaces analytiques)
Donc c´est vrai que j´en vois beaucoup d´applications

Pas mal du tout luxregina ! Il y a beaucoup de choses que j´avais oublié : les troncs d´arbres, les lianes, le joueur qui descend tout seul dans une pente...

Salut à tous, c´est vrai que c´est un sujet interessant.

Pour choisir la bonne formule à adpoter pour réaliser son système de collision, il faut bien savoir qu´est ce qu´on veut faire, le niveau de réalisme.
Car on peut réaliser des jeux sans toucher un poil de physique ou bien même n´utiliser que ca (comme dans un moteur 3d) avec des forces (acceleration, vitesses, force de frottement entre objets, impulsion rotationnelle pour faire tourner un objet lorsqu´on tape sur le côté, etc..)

Il y a deux phases dans tout ce qui est collision :
1ère phase : detection de collision, savoir a quel instant l´objet est entré en collision, determiner le point, le vecteur normale, et les vitesses juste avant la collision, etc...
2ème phase : gérer le rebond entre deux objets.
Selon les infos trouvés dans la phase 1, on peut alors simuler un système de rebond plus ou moins réaliste.

Donc utiliser un même moteur pour un jeu de plate forme ou un jeu de combat, ne me semble pas une bonne solution, car les systèmes des detection de collision et le rebond risque d´être différent.

Ce qui est assez difficile, c´est de trouver un algo assez rapide pour detecter n´importe quel collision entre deux polygones concaves (dans le pire des cas). On peut ainsi representer n´importe quel type d´objet (perso, balle, mur, etc..) avec un polygone de ce type. Mais ce qui complique ensuite c´est de collisioner ces polygones avec des structures de données tels que bézier qui n´est plus un polygone mais une courbe.

Ok, alors d´abord merci à tous pour vos idées et surtout merci à Luxregina pour ses tutos !

Pour info, le tuto de Tonypa donne des explications de base sur les structures et la modélisation utilisables en flash.
On peut aussi voir le site de OutsideOfSociety :
http://oos.moxiecode.com/ pour le même genre d´info. Notez que OOS propose aussi un tuto de 3d isométrique (qui repose aussi sur le principe des tiles) pour ceux que ça intéresserait.

Celui de Metanet pose une reflexion bien poussée sur la gestion de collision sur un moteur de physique "réaliste" (par vecteurs de forces). Leur code est essantiellement fait pour flash, mais lisible comme tel pour la simple compréhension algorithmique... C´est comme de se taper des cours en pseudo-code : c´est utilisable partout une fois qu´on a compris.
Pour ceux qui planchent sur les collisions, Metanet fait référence à des publications super intérressantes sur le calcul d´intersections d´objets en 2d.

Celui de Strille pousse les choses plus loin au niveau de la modélisation du monde : si tous les tutos précédents fonctionnaient par tableau de tiles (bien souvent vide puisqu´il faut de grandes zones où se déplacer), Strille base son monde sur des objets de taille variable ancrés dans des zones d´affichage. Le tuto explique du coup le principe d´un scrolling sur une telle structure...

Alors, perso, là j´ai plus rien à demander : Tonypa comble les manques en flash, Metanet propose une gestion de collision en deux étapes de précision (pour des définitions de collision particulières), et Strille met en place un ensemble d´objets à dimensions variables à même de décrire les formes les plus exotiques (genre les béziers de Fvirtman)...
Ca colle pile-poil à la façon dont je me représentais les choses, d´où plein de tests en perspective...

Mais bon, que ça ne vous empêche pas de proposer de nouvelles choses !
Merci encore à tous !

Vraiment tres sympa le tuto de Tonypa, illustré, bien fait, j´aime bien

merci Lux

pfff ...ca serait plutot "merci Tonypa" je lui ai pas tenu la main ...

merci pour le lien