Discussion :

[garcon_etoile]

ya ici 2100 points pour 22 euros, mais un avis en dessous dis que comme ça marche beaucoup, c'est souvent en rupture:

http://www.rueducommerce.fr/Jeux-Con...s-Xbox-360.htm

Et un sujet qui traite pour avoir des points pas cher:

http://gueux-forum.net/index.php?showtopic=194260

Sinon je suis ok avec toi, XNA c'est sympas il devrait y avoir un forum francophone plus concequent, il y a beaucoup de contenu.
Mais apres je pense que c'est le boulot qui fait peur, car ouvrir un forum c'est facil, mais le mainteir c'est autre autre chose...

[Djakisback]

- Animation image par image indépendante.
- Moteur 2D mais pas en "tiles" (par points car les sols sont en courbes).
- On fait nous meme l'editeur de niveaux. (On fai tout nous meme en fait)

On a des problemes avec l'animation et son rapport image par image, vu qu'on veut des animations tres fluide, une animation peut donc aller jusqu'à 60 images, juste pour l'animation d'attente avec sa goutte qui sort du nez...En plus d'etre tres lourd en images, c'est tres lourd en ressources.

Salut,
le projet a l'air sympa
Ce qui est dommage c'est que c'est typiquement le style de graphismes/animations qui se prêtent au vectoriel et à l'interpolation de vertices ou autres. D'ailleurs vous utilisez Flash pour les graphismes, non ?

Pour ta goutte au nez par exemple, une simple interpolation linéaire d'un scaling aurait suffit.

Enfin c'est toujours le choix difficile de la balance entre RAM et CPU et de toute façon vous avez fait votre choix il y a 2 ans. Mais si par exemple vous stockez chaque image du perso complet rien que pour la goutte y a un léger problème de conception, il faudrait au moins découper le perso en tranches communes d'anims et positionner le tout "à la main".

Pour ce qui est d'un développement parallèle je pense qu'il vaudrait mieux que vous terminiez le projet et partir par la suite sur un portage. A équipe réduite le dev parallèle me semble un peu cassse-geule à moins que la phase de conception (surtout le découpage/dissociation/abstraction des sections du projet) ait été vraiment bien faite.

A ce propos :
"- Moteur 2D mais pas en "tiles" (par points car les sols sont en courbes)."
il me semble pas que cela eût posé de problème, il suffit de dissocier la physique du tracé.

Bon courage pour la suite ^^

[garcon_etoile]

Coucou Djakisback

Merci pour ta réponse.
Ca veut pas dire grand chose "utiliser flash pour les graphismes" , flash c'est juste un procédé d'animation en vectoriel, tu peux animer en flash n'importe quels types d'images. On s'est habitué aux graphismes "type flash" en applat de couleurs, car c'est plus léger à animer. Donc non notre jeu n'est pas en flash, c'est un jeu 2D basique, programmer à l'ancienne à la dur.
J'utilise le vectoriel via Illustrator. Donc au final on travail betement l'image en .PNG comme n'importe quelle jeu 2D. On ne peux pas interpoler avec notre moteur 2D, sinon pour faire ça il aurait fallu developper un moteur vectoriel, chose qui est ardue, et meme si on y arrivait, flash pour l'animation est un format propriétaire.
Comme on veut une animation tres fluide et en image par image, y'a pas de secret, ca demande beaucoup d'images. Et les moteurs 2D basique ne sont pas adaptés pour traiter ça.

Ce qui est dommage c'est que c'est typiquement le style de graphismes/animations qui se prêtent au vectoriel et à l'interpolation de vertices ou autres.

Pourquoi c'est dommage ?

A plus

[E-Sh4rk]

En tant que développeur pour le projet White Night, je souhaiterais rebondir sur les remarques de Djakisback, en apportant plus d'informations sur le problème des animations dans White Night. J'espère ainsi que des solutions nouvelles puissent être déterminées, avec l'aide de l'expérience des membres de ce forum.

Le problème du stockage et de la restitution des animations perdure depuis le début du développement du projet, sans que jamais nous n'ayons réussi à trouver la solution parfaite, dont l'existence même peut être sujette à débat. White Night pose un problème particulier du fait de l'abondance et de la lourdeur des animations dont il est composé. Un seul cycle de marche de l'héroïne représente à titre d'exemple pas moins de 60 frames !

La solution de l'image par image, bien que scandaleuse du point de vue de la mémoire occupée par les animations (l'animation du cycle de marche n'excède pas 30ko en swf, alors qu'on dépasse le Mo avec une suite d'images PNG), reste cependant le meilleur compromis que nous ayons réussi à trouver.

En effet, la solution du vectoriel est très tentante, et d'ailleurs largement utilisée pour animer les menus du jeu par exemple. Ainsi, les animations de montage et de bouclage du menu sont stockées dans des fichiers XML sous un format personnalisé qui retrace à travers une timeline les transformations subies par differents éléments.

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<scene x="0" y="0">
		<anims>
			<anim name="intro" duration="240" fps="24">
				<blending element="2" begin="0" duration="240" /> 
				<htranslation element="5"  destination="0" begin="0"   duration="240"/>
				<htranslation element="6"  destination="0" begin="96" duration="144"/>
				<voscillation  element="8"  destination="6" begin="0"   duration="65"/>
 
				<vtranslation element="11" destination="393" begin="144"   duration="96"/>
				<vtranslation element="12" destination="409" begin="154"   duration="96"/>
				<vtranslation element="13" destination="429" begin="164"   duration="96"/>
				<vtranslation element="14" destination="449" begin="174"   duration="96"/>
 
				<hloop element="9" destination="800" begin="0" duration="144" />
				<hloop element="10" destination="0" begin="0" duration="144" />
				<hloop element="3" destination="-800" begin="0" duration="480" />
				<hloop element="4" destination="-2400" begin="0" duration="480" />
			</anim>
			<anim name="loop" fps="24">
				<voscillation  element="8"  destination="6" begin="0"   duration="65"/>
				<hloop element="9" destination="800" begin="0" duration="144" />
				<hloop element="10" destination="0" begin="0" duration="144" />
				<hloop element="3" destination="-800" begin="0" duration="480" />
				<hloop element="4" destination="-2400" begin="0" duration="480" />
			</anim>
		</anims>
	</scene>

La même approche est beaucoup plus difficile à mettre en place pour la totalité des animations, en particulier celles des personnages. Il ne serait pas très difficile de construire un moteur vectoriel, mais le réel problème réside dans l'entrée à fournir à un tel système. Le logiciel d'animation utilisé par notre infographiste (Toon Boom) peut produire les formats d'exports suivants : image par image, mov, avi, swf... Aucun d'eux ne peut être interpreté par un moteur vectoriel et c'est là qu'est tout le problème. Si le logiciel pouvait exporter une animation sous un format normalisé serialisant éléments constitutifs bruts, timeline, et matrices de transformations, nous n'aurions peut être plus de problèmes à ce jour ! Avec nos outils actuels, travailler en vectoriel signifierait donner de grosses contraintes à notre infographiste, et lui empêcher d'utiliser les outils dont il a l'habitude.

J'ai longtemps parcouru la piste de la conversion du format SWF vers SVG (format ouvert), mais aucune solution réellement satisfaisante n'existe sur ce terrain là.


Tous les idées et témoignages d'expériences vécues sont les bienvenues !
Jonathan

[yodaime]

Juste pour info, Toon Boom est un partenaire de XNA. Donc je pense qu'il doit y a voir tout ce qu'il faut dans ce logiciel :

http://creators.xna.com/en-US/partners

[Djakisback]

Salut ^^,
quand je disais "c'est dommage" c'est pour la raison de la taille des ressources comme évoquée par E-shark et signalée à la base du topic. L'outil/méthode de création a son importance car travailler en vectoriel et générer du bitmap a un côté illogique sauf s'il y a un paquet de dégradés, des masses de couches, etc. (30ko vs plusieurs Mo)

Mais le but est seulement de réduire les ressources ou bien le jeu a du mal également a tourner sur des petites config ? (ex : trop de grosses bitmap transparentes ou non) En fait, le prob des ressources matérielles est peut-être mineur sur les config de maintenant et sur la 360.

Si vous partez du format des ressources qui est définitif pour faire le moteur 2d, effectivement un export en opensource aurait été le top.

Sans grosses modifications, vous pourriez tenter de passer tous les backgrounds fixes en vectoriel (s'il y a trop de courbes, pas sûr que le gain soit formidable, tjrs la balance).
Sinon, découper les anims par tranches communes mais en 800*600 je suis pas sûr de la qualité du résultat pour la rotation, jamais tenté.

A part ça, la démo ne se lance pas chez moi (aucun message dans la console)

[edit] Après re-réflexion et au vu des png des bg fournis dans la démo, je crois que ce serait stupide de les repasser en vectoriel, la compression png fait déjà bien son travail[/edit]

[khazna]

Pour votre problème d'animation...

Pourquoi ne pas utiliser une animation skeletale? En 2D.
Vous ne stockez en mémoire alors que les images des parties du corps (bras, jambes, torses, tête etc...), et les définitions des animations.

Plus besoin de faire une image complête (et lourde!) pour chaque frame d'animation!

Côté CPU c'est pas couteux du tout (quelques multiplication de matrices).

Par exemple j'ai en tête un projet que je suis de près, Demina ( http://demina.codeplex.com ) qui rend ceci possible. Celui-ci est fait pour XNA d'ailleurs.

Pour le développement, question pratique, je te conseille un ordi portable, une 360 S (pour le wifi), plantés devant la télé . J'en rêve!

[SQUAL]

Bonjour,
j'aimerais revenir sur une question qui avait été posée vers les premiers posts mais à laquelle nous n'avons pas eu de réponse :
sur quelle résolution est il préférable de travailler ? Sur le site officiel de xna, il est indiqué : 1024x728. Si jamais le jeu est lancé sur une TV de résolution plus petite, est ce que la qualité d'image (les courbes, le ratio) sera intact ? Et sachant que les jeux xna sont supposés être compatibles sur les windows phones, est ce qu'il faut prévoir des une autre version avec des images de plus petite résolution ?

Merci pour votre aide !

[Emmanuel Deloget]

Bonjour,
j'aimerais revenir sur une question qui avait été posée vers les premiers posts mais à laquelle nous n'avons pas eu de réponse :
sur quelle résolution est il préférable de travailler ? Sur le site officiel de xna, il est indiqué : 1024x728. Si jamais le jeu est lancé sur une TV de résolution plus petite, est ce que la qualité d'image (les courbes, le ratio) sera intact ?

Réponse ici.

C'est à toi de traiter les cas dégradés : en 640x480 entrelacé, tu n'auras pas la même qualité de rendu, y compris pour les chaines ce caractère. Pour qu'elles soient lisibles, il te faudra certainement changer certaines choses, y compris le ratio taille de chaîne/taille d'écran.

Et sachant que les jeux xna sont supposés être compatibles sur les windows phones, est ce qu'il faut prévoir des une autre version avec des images de plus petite résolution ?

Oui - sans quoi ton jeu sera trop lourd à télécharger. Inutile de charger inutilement les téléphone de tes futurs clients

[Fabiani]

Salut à tous,

Quelques autres considérations:

http://www.xnawiki.com/index.php?tit...ommunity_Games

Salutations.