Discussion :

[blake_ch]

Bonjour,

Je viens de rejoindre ce forum car j'ai actuellement commencé un petit projet en SDL. Jusqu'à présent, je me suis concentré sur l'affichage et maniement de mes sprites et l'algo de jeu.

Maintenant j'aimerai aller plus loin et faire quelques animations plus complexe que le maniement basique des sprites. Pour vous donner une idée, ce serait des choses comme :
- le fond du jeu qui aurait une animation à la windows media player
- des interactions qui créent quelques effets sur des pixels précis

J'ai vu qu'il était possible d'accéder aux pixels même d'une surface afin de l'éditer, mais je me demande si c'est la bonne question et s'il n'existe pas de méthodes turbo pour le traitement de pixels.

Et de manière générale, comment se passe le développement d'une animation (imaginons un fond avec une animation répétée mais couleurs changeantes style windows media player, sans l'interaction avec la musique directement bien sûr) ?

Est-ce que c'est d'abord étudier les formes de mon animation? Paramétriser (ça se dit?) tous les éléments? Le problème des dégradés qui peuvent aller dans toutes les directions.

J'ai beaucoup travaillé dans le domaine de l'embarqué, donc je sais bien que sur un PC on a une grosse puissance de calcul à disposition, mais j'ai l'impression que dès que je fais des animations très basiques pour essayer, mon code devient vite lourdeau (même si l'exécution se passe vite).

c'est assez difficile à poser comme question, j'espère que vous en comprenez le sens. Je suis preneur si vous avez quelques explications (surtout vis-à-vis de SDL), quelques liens de tutos sur comment développer une animation de A à Z, s'il existe des librairies déjà prévues, ou bibliothèques d'animations, ....

Merci d'avance

[SofEvans]

Bonjour et bienvenu sur developpez.


C'est une question interressante que tu pose.

Pour les animation :

Si tu veux acceder au pixel afin de les modifier, il va falloir faire attention. Si tu test, tu verra que cela occasionne un gros ralentissement visible a l'oeil nu (dependant du nombre de pixel, mais modifier un sprite 50x50 est deja trop, j'en ai fait les test).
Pour ce qui est d'une methode turbo, j'en ai pas encore vu.


Pour ce qui est des animation, on essaye de toujours faire en sorte de les precalculer : par exemple, j'ai un sprite de 4*29 asteroid, j'en fait un tableau de 4*135*29 car je precalcul 135 animation possible (j'utilise SGE avec rotation, ca met 1~2 seconde a se faire).

Pour ce qui est de la fluidité, j'ai l'impression que tu n'utilise pas le meme BPP sur chacun de tes sprite.
Je m'explique :

Lors de la creation de ta fenetre, tu donne un BPP (ou profondeur de couleur), generalement, on mets 32.
Lorsque tu charge tes sprite, le BPP se met automatiquement et en general, c'est 24 BPP. Il y a donc une difference entre ton sprite que tu veux blitter, et ta fenetre.
Or, SDL_BlitSurface ne peux pas coller une surface sur une autre s'il y a une difference a ce niveau. Donc, implicitement, elle fait une conversion. Et a chaque fois que tu veux re-afficher, elle refait la conversion. Pour supprimer ce temps de conversion, il faut convertir le sprite a son chargement grace a la fonction

SDL_Surface* SDL_DisplayFormat(SDL_Surface*);

Attention, cette fonction doit etre appeler apres SDL_SetVideoMode.
De plus, SDL_DisplayFormat ne libere pas la SDL_Surface passer en parametre.


Voila, je pense t'en avoir assez dit. Apres, pour l'animation, il faut definir une suite de sprite via des structures (meilleur moyen), il y a des tuto dessus.

[blake_ch]

Hello et merci pour ta réponse.

Quand je parle de fluidité, je ne dis pas que j'ai des problèmes de fluidité, tout se passe bien. C'est juste que le code devient vite grand pour faire quelques algos sur une animation.

Quel est donc la solution si je cherche à faire un fond dégradé qui bouge et change de couleurs aléatoirement? tout dois passer absolument par des sprites? ce n'est pas très idéal :/

[SofEvans]

Bonjour,

Non, pas forcement.
si tu veux faire un fondu aleatoire, u peux toujours faire un SDL_CreateRGBSurface que tu remplirais aleatoirement avec un SDL_FillRect, puis SDL_BlitSurface.

Apres, il va falloir determiner les valeurs "aleatoire" pour faire un fondu agreable aleatoire. La, c'est plus de l'algo que de la SDL.

Sinon, je suis daccord avec toi. Si on veux faire des animation "sécuriser" (c'est a dire avec verif chargement+verif conversion), le code devient vite grand. Mais quand tout est mis dans une structure (ou une classe), le code devient "leger", c'est a dire qu'une fonction s'occupe de tout et toi tu as juste a donner le chemin.

http://www.gnurou.org/writing/linuxmag/sdl/partie3

voila un lien pour l'animation via liste chainé

[blake_ch]

Je vois bien comment gérer une animation pour un truc qui est pré-défini (comm l'explosion dans ton lien), mais quand c'est du totalement aléatoire je pense qu'il est nécessaire de travailler au niveau du pixel et de faire de l'algo à fond.

J'aimerai bien trouver quelques consignes pour débuter dans le domaine.

Si par exemple je veux avoir un dégrade en diagonale dont les couleurs clés ( from -> to ) et les lieux de références changent, je suis obligé de travailler au niveau du pixel il me semble puisque les surfaces sont rectangles.

je vais faire quelques essais.

Ce que je cherche comme genre d'aide ou de lien, c'est quelques consignes sur les manières de travailler et développer un algo de ce style (le dégradé est un exemple). Je me pose des questions comme :
J'ai choisi de prendre la couleur ROSE comme référence en x = 200, y = 300 et de faire un dégradé circulaire dans toutes les directions vers le NOIR. Le point de référence bouge dans tous les sens (par exemple rebondit contre les bords diront nous).
Dois-je partir du centre et tourner dans tous les sens pour calculer les couleurs de mes pixels?
Dois-je partir d'en haut à gaucher et changer les calculs?
Dans quel cas simplifier les parties ou devoir détailler chaque truc?

Bref, c'est plus des conseils d'algo dans le traitement de gros tableaux à partir de sources aléatoires.

J'ai mis ce topic dans SDL car je pensais que l'API offrait quelques possibilités dans ce domaine...

[SofEvans]

Tu vise haut.

La SDL ne te permettra pas de faire ceci de maniere optimiser si tu fait de la manipulation par pixel.

J'ai choisi de prendre la couleur ROSE comme référence en x = 200, y = 300 et de faire un dégradé circulaire dans toutes les directions vers le NOIR. Le point de référence bouge dans tous les sens (par exemple rebondit contre les bords diront nous).
Dois-je partir du centre et tourner dans tous les sens pour calculer les couleurs de mes pixels?
Dois-je partir d'en haut à gaucher et changer les calculs?
Dans quel cas simplifier les parties ou devoir détailler chaque truc?

Typiquement, je te conseillerai de faire un enorme sprite qui representerai ton degrader, et d'utiliser a bon escient SDL_BlitSurface pour donner l'illusion qu'un cercle rose se deplace et rebondisse.

Franchement, pour ce que j'en ai experimenter, plus tu fais de manipulation sur des pixel, plus ca ralentit. La SDL est critiqué pour sa lenteur justement, il faut veiller a faire les operation de blittage le plus optimiser possible.

Sinon, tourne toi vers la SFLM (incompatible avec C par contre) ou alors vers le couple SDL/OpenGL (ce qui revient a utiliser uniquement OpenGl pour les sprite).

Tu verra qu'on creer dabord les surface avant de les afficher.