question d'ordre technique

Avant de commencer, je precise que ce topic n'a pas pour but de determiner sur quelle plateforme le jeu serra developpé

Ma question concerne l'animation du heros, des pnj et des ennemis dans le jeu. on distingue deux grand principes:
- La technique la plus utilisés lorsqu'il s'agit de 2d est d'utilisé des sprites qu'un graphistes a gentillement dessiné a la main, et des les affichés les uns apres les autres, pour donner l'impression d'une image fluide. L'avantage de cette methode est qu'elle permet de rendre des animations réalistes dans le sens qu'elles ont été extremement travaillée pour obtenir un bon resultat, et qu'elle ne necessite qu'une faible utilisation du CPU (on se contente de definir l'image a afficher et de l'afficher). Par contre, tous les sprites doivent etres loader en memoire, et la c'est la RAM qui mange (hors, plus on veux un resultat fluide et jolie, plus il faut d'image pour chaques animation...)
- En 3d, on utilise un squelette qui est actualisé regulierement par le jeu, et le rendu a l'ecran est calculé a partir de ce squelette. L'avantage, c'est que tout est dynamique, l'animation du perso s'adapte a la situation dans le jeu, et permet d'obtenir un rendu realialiste dans le sens ou le perso reagira vraiment en fonction de l'environnement, et pas de maniere typique. Par contre, si cette methode libere la Ram, c'est au tour de notre ami le CPU de faire la fete.

Ma question es donc la suivante:
quelle est selon vous la meilleur facon de proceder pour un jeu d'action/aventure/plateforme en 2d?
-utiliser les sprites : bouffe de la ram au profit du cpu et necessite de faire pleins de sprites a la main
-utiliser un squelette : bouffe du cpu au profit de la ram, et necessite une bonne gestion du squellette au niveau du code (moteur physique)
-faire un mix des deux : faire a la main plein de squelettes pour les anims, puis les habiller au niveau du code (equilibre les besoins en cpu/ram et permet d'utilisé une meme anim pour plusieurs elements (heros et ennemis par ex)


Et je reprecise que la question n'est pas de savoir si c'est un proj prevus pour olpc, interrogez vous plutot sur la methode la plus optimisée, la plus realisable, ou tout autre consideration qui vous font preferer une methode plutot qu'une autre

Bah deja la 3D et la 2D c'est pas la meme chose, mais ca tout le monde le sais.

En 3D tu deplace des sommets, se qui déforme des polygones. En 2D je ne vois pas comment tu compte deformé les pixels, a moin de travailler en vectoriel.

on ne deforme pas les pixels:
on a un segment (par exemple un avant bras) qui sert d'indicateur sur l'emplacement où on doit dessiner les pixels (l'os sert ed structure pour la chaire )
c'est peut-etre le principe du vectorielle... j'avoue que je sais aps comment ca marche^^

il y a des squelettes en 2D?

(Apres tout pourquoi pas)

En 3D, le principe des Bones est plutot simple, lorsque tu bouge un des points de la structure les sommets qui lui sont attanché bougé comme lui (dans la limite de leur pourcentage d'attribution au point bougé).

En 2Dpixel, a mois de faire des nuage de pixel qui suivent des points je ne vois pas comment faire.

En 2Dvectoriel, c'est un peut comme la 3D, tu as des sommets qui sont lier entre eux par des fonctions mathematique pour faire des cercles, et des polygonne, apres la structure déplacerais ses points.

M'enfin, je ne pense pas que se soit une bonne solution, car en 3D c'est le GPU qui calcule, et il est spécialisé dans ceux genre de calcule, dons le meilleur truc c'est de faire des sprits, crée un format d'animation plus légé que de mettre des image les une apres les autres. Exemple en stockant seulement les modif dépuis l'image précedante.

Je pense que faire de la 3d serait ridicule dans ce genre de projet...

je n'ai pas parler de faire de la 3D
par contre, stoker juste les modifs en fonction du sprite precedent, c'est pas con

Salomon, tu es trop fort

Garagos, merci

on purait imaginer le format suivant de sprite :
1 image initiale(T0),
puis les pixels changeant à T+1, à T+2, .....

Les spites compressés de cette facon seront plus rapide à afficher et plus légé.

Le tout serait jute de realise un petit prog qui compresse une serie d'images.....

Merci hexa pour ce résumé de l'idée de nounours

Plus léger en mémoire oui.
Plus rapide je sais pas:

Ca necessite de modifier une image avant de l'afficher, hors en stockant chaque image ya qu'a aller chercher la bonne.
De plus cela oblige de commencer l'animation du début, ou de la reprendre la ou on s'arrete, pas avec des sprites bien distinct.

Enfin c'est pas forcement important.