Voir la version complète : [NDS][Aide] Animated Backgrounds
Salut
Pour terminer mon projet sur DS, j'ai besoins d'animer des fonds.
Est-ce possible avec la PA_lib, ou avec une autre lib ?
Je ne peux pas utiliser de GIF parce que je veux déclencher les animations selon certains évènements du jeu.
Si qqun a une idée, je suis preneur :)
Merci !
Vraiment aucun moyen d'animer un fond ? :cry:
Je ne sais pas s'il y existe une fonction magique pour ça, mais tu peux toujours tricher un peu:
* Si c'est une animation basique, tu peux essayer de charger 2 ou 3 fonds et de les swapper tout les autant de frames.
* ou alors charge 3 backgrounds avec une couleur de transparence et fait un parallax comme dans les exemples de PALib.
* Sinon, tu peux essayer de modifier le contenu du background à la main (je vais surement dire une grosse connerie, mais il me semble que c'est en mode 7...quelqu'un me corrigera si c'est une erreur).
Tu peux alors animer le fond avec une deformation sinusoidale...
Tout dépend de l'animation que tu veux donner en fait.
Je ne suis pas sur que mon post t'aide vraiment, mais j'aurai essayé ^^
bonjour,
tu ne donne pas beaucoup d'infos sur ce que tu veut faire, animer un fond comment ?
en mode bitmap en mode tiles ou en mode 3D ?
avec l'aide du hard ou en soft ?
une animation sur le fond entier ou juste sur des tiles ?
soit precis et tu aura des reponces ;)
Ok, c vrai que c'était p-e pas assez précis :-'
Donc en fait voila ce que je cherche à rendre :
au départ d'un niveau de jeu, le fond est presque vide et très triste (presque pas de couleurs), puis lorsque le joueur déclenche un élément de jeu, des éléments apparaissent dans le fond en étant animés (par exemple un batiment qui se construit en fond).
En plus de ça, comme je me sers d'un background pour gérer mon plan de collision (c'est un jeu de type plate forme), j'aimerai l'animer également. Il serait en noir et blanc au départ du niveau, puis j'aimerai colorer certaines parties du bg de collision sur des events.
D'un pt de vue technique, pour l'instant j'utilise des fonds en tiles. Tout est en 2D. Mais si vous voyez un autre mode plus intéressant pour résoudre mon pb, jpeux m'adapter =_= (jvais essayer en tous cas). Tout mon proto est codé avec la PA_lib, mais comme je n'ai rien trouvé dedans pour résoudre mon pb, je peux utiliser une autre lib, ou autre si il faut (g meme pas peur :ph34r: ).
Donc pour répondre directement à tes questions Nesgba :
en mode bitmap en mode tiles ou en mode 3D ?
tiles (mais si il faut je peux essayer de changer)
avec l'aide du hard ou en soft ?
heu, bah pour le mieux, je sais pas
une animation sur le fond entier ou juste sur des tiles ?
A la base c'est seulement qques tiles du fond à chaque fois. Mais comme je veux lancer plusieurs anims sur un meme fond, c'est p-e plus simple de considérer le pb comme l'anim du fond en entier (si c possible).
@Gwoin :
Merci pour toutes ces pistes :)
Et ton post a quand même l'utilité de me dire que j'étais pas assez précis sur ce que je cherchais ^^
J'espere que c + ( + ) clair ;)
Merci les gars
Le probleme que je vois c'est que tu veux faire un tas de trucs dans ton fond (ajouter des objets, changer la couleur, ...) et que tu es limité en nombre de background.
Pour le changement de couleur, il faut voir si tu peux changer la palette de couleur, comme ça tu fais une anim sur la palette et tu modifies la couleur avec de jolis dégradés :)
Serait-il possible de considérer des sprites au lieu de backgrounds?
C'est juste une idée, mais ca te permettrait d'en rajouter et supprimer plus et de facon plus simple (je pense, mais je ne connais pas la structure de ton code, donc je ne sais pas si c'est vraiment une bonne idée ^^ )
Pourla collision ca ne devrait pas être pus cmpliqué si ce sont des sprites, vu que tu connais leur position et leur taille, leur couleur, ... bref tout ce qu'il faut, quelque soit ton algo de detection de collision.
Ouais je vois. Tu me conseilles donc d'utiliser des sprites pour mes anims ...
Le gros probleme que je vois avec ça, c'est de bien synchroniser toutes les anims des sprites, autant au niveau de la position que du timing.
En fait, l'idéal pour moi, ce serait de gérer mes fonds comme des sprites : je mets dans mon bg plusieurs étapes d'anim à la suite, et je choisis de charger telle ou telle étape. Gérer un sprite de la taille du bg en fait.
Et c'est pour ça que je cherche une autre solution que les sprites. Ca me semble compliqué de découper mon bg en sprites et de faire un code qui gere la cohérence de tous mes sprites (jsais pas si je suis tres clair là :blink: ).
Tembargo
27/04/2006, 13h16
Moi je comprends pas bien ^^ un ptit exemple ?
Ok, voila un petit exemple. J'ai que l'exemple du bg de collision sous la main.
Là le bg de collision au début du niveau :
http://swat64.free.fr/EXEMPLE_collision.jpg
Là le bg une fois qu'on a tout activé dans le niveau :
http://swat64.free.fr/EXEMPLE_collision_color%e9.jpg
En fait, on passe pas de l'un à l'autre d'un coup, mais par étapes. Par exemple on va d'abord faire apparaitre le premier rond jaune à gauche, qui devrait apparaitre en suivant la ligne (en anim koi v_v ). Et ensuite un autre élément, lorsque le joueur active autre chose, etc ...
Pour le bg d'arriere plan, c un peu le meme principe, sauf qu'il serait vide au début, et les formes devraient apparaitre. Enfin c le but recherché =_=
PS : les trous dans le fond de collision, c pour y mettre des sprites
Je vois un peu ton probleme,
Mais tu seras alors limité en taille mémoire. Ca t'impose de mettre une tres grande texture en mémoire. Un background de 1024x1024 ca devrait passer, mais si tu rajoutes d'autres trucs en plus en mémoire, tu vas vite saturer.
Finalement, mieux vaut créer plusieurs backgrounds séparé et passer de l'un à l'autre. Le résultat est le même qu'avec une image contenant tous les backgrounds, mais tu utilises alors beaucoup moins de mémoire :)
Si tu connais d'avance toutes les combinaisons possibles et que ca ne te dérange pas de toutes les dessiner sur des backgrounds, alors oui, utilises des backgrounds pour ton anim, mais sur des images différentes que tu charges quand tu en as besoin.
En gros, plutot que de faire un truc du style PA_SetBackgroundFrame(i); (qui n'existe pas, je pense), tu deletes ton bg courant et tu en charges un nouveau (PA_ResetBgSys() ne fait que cacher le fond courant mais ne l'efface pas de la mémoire, essaie plutot PA_DeleteBg )
[EDIT]: j'avaisd pas vu ton post pendant que je créais le mien :)
Tu veux animer les traits et tout et tout?
Oublie les fonds. il t'en faudrait des dizaines pour commencer une anim correct sur l'ensemble du jeu.
A ta place, j'utiliserai le mode 7 pour dessiner mes traits ( je ne sais pas encore comment je ferais,mais c'est surement ce que je ferais).
Ou alors en sprite, mais même là c'est chiant à gérer :huh:
Et charger et décharger tout un bg à chaque frame, ça va pas faire ramer le bordel ?
J'ai pas essayé, mais si ça peut marcher, ça résoud mon pb. Parce que effectivement, l'ordre d'apparition des formes et de coloration est complètement définit et prévu par nous.
[EDIT] : Pareil, g pas vu ton edit pendant ke je postais ;) ouais, tu voies un peu mon pb. Mais produire les fonds c pas un pb, avec after effect ou 3DSMax, c jouable. C surtout niveau perfs je sais pas ce ke ça peut donner. Ou meme si techniquement c jouable.
quesque tu as gwoin avec ce mode 7 ? :blink: :D le mode tiles suffi amplement pour des trucs pareil.
alors c'est simple, tu va avoir un bg de fond (sans aucun element affiché dessu) avec un bg par dessu (la ou les rond animés vont apparaitre) pour les etapes d'animation il te suffi de modifier les tiles affichés sur la map.
si ton bonhomme touche un interupteur ou je ne sais quoi tu lance l'animation qui fait apparaitre tel element (il faut que dans ta map tu ai bien placé les tiles correspondants aussi)
donc pour resumer: affiche tes 2 maps (tout les elements a animer sur l'une et les autres sur l'autre)
ensuite trouve l'emplacement memoire ou sont stockés les tiles de ta map (avec les elements a animer)
mais attention il vaudrai beaucoup mieu pour toi que les tiles de chaque element soit placé a la suite (arrange ton tilset de depart en consequance)
puis copie des tiles vides (ou d'autres etapes d'animation) a l'emplacement de l'element que tu ne veut pas afficher ou que tu veut animer.
c'est un truc super simple a faire mais je me demande juste si tu va bien me comprendre :S
Ca à l'air pas mal ce que tu proposes.
Je ne suis pas sur qu'avec PALib on puisse jouer avec la mémoire aussi facilement.
En tout cas, ça à l'air d'être la meilleur solution (ce que j'en disais pour le mode 7, c'était surement une connerie comme je l'expliquais dans mon premier post ^^ )
Effectivement, le retour apres la pause repas est un peu rude ;)
Non, je crois que j'ai compris le principe Nes. Tu me propose de modifier directement les tiles, en me servant du fond de départ, et un autre par dessus qui ne comprend que les tiles que je modifie.
Au niveau de la réalisation, ça me parait collossal comme travail. Surtout si on considère qu'il y a plusieurs niveaux ...
Mais même sans aller jusque là, je n'ai jamais travaillé directement sur les tiles. J'utilise PAGfx (en bon assisté que je suis =_= ) qui me génère un fichier de palette et un fichier de définition pour chaque bg.
Donc en fait, dit comme ça, ça me fait un peu peur :unsure: , même si tu dis que c'est simple.
Si tu ne veux pas bosser sur les tiles du BG, il te reste les sprites comme déja dit, je pense que tu peux faire ce que tu veux avec. C'est du boulot, mais rien n'est simple ;)
Bobby Sixkilla
27/04/2006, 15h46
Une petite question en passant : dans Street Fighter II, les BG étaient animés... Comment ça marchait? Ca pourrait être une piste... :-'
Même si mon espoir secret était de trouver une méthode simple :ph34r: , je suis clairement conscient que ça va être chiant à gérer (jm'en rends compte en tous cas avec les sprites, parce ke je travaille avec depuis un bout de temps).
Mais si la solution c'est effectivement de bosser directement sur les tiles, le premier pb qui se pose, c'est "comment ?" .:blink:
Une petite question en passant : dans Street Fighter II, les BG étaient animés... Comment ça marchait? Ca pourrait être une piste... :-'
A voir les animations, ca devait surement être une suite d'images affichées les unes à la suite des autres.
Fab, effectivement je ne pense pas que PALib te permette de toucher directement à la mémoire, mais essaie de voir du cote de la ndslib (sur laquelle est basée la PALib).
Sinon, les sprites restent une bonne solution...
Même si mon espoir secret était de trouver une méthode simple :ph34r: , je suis clairement conscient que ça va être chiant à gérer (jm'en rends compte en tous cas avec les sprites, parce ke je travaille avec depuis un bout de temps).
Mais si la solution c'est effectivement de bosser directement sur les tiles, le premier pb qui se pose, c'est "comment ?" .:blink:
Déja, faudrai que tes animations soient pretes , peu importe que ce soit sprite ou bg.Quand je dit pretes , je veux dire par là déja passé dans une moulinette qui te perme d'avoir tes anims au bon format (tile 16 couleur par exemple )
Avec la méthode de NES, c'est assez simple. Tu t'arranges pour mettre tes tiles animés dans dans la meme zone mémoire, ce que je veux dire c'est de mettre tes tiles animés regroupés.
Ensuite c'est un simple transfert en mémoire à faire dans ta ram de tile de tes animations à chaque frame. L'avantage si tu as regroupé tous tes tiles animés de façon contigues, c'est qu'en 1 seul transfert, ça te gére toutes tes anims d'1 coup.
( à suposer bien sur que tu ais le meme nombre d'animations pour toutes tes anims, car si tu as une anim sur 8 frame et une autre sur 6 par exemple ça ne vas pas aller, et dans ce cas tu regroupe tes tiles par nombre de frame d'anim )
Cette méthode marche , que ce soit du bg ou du sprite on s'en fout, c'est des tiles dans les 2 cas, des sprites c'est jamais que des bout d'un buffer découpé. On peut meme dailleurs créer un bg complet rien qu'avec des sprites aussi.
Là je dois bien avouer que tu m'as un peu noyé :-'
Mais j'ai réfléchi un peu à un système de tiles, le pb, c ke lorsque je vais animer une tile, ça va animer toutes les tiles identiques .... :-*
Enfin bon, je crois ke g fais le tour de la question avec ce topic, jvais bien regarder tout ça, et je vous tiens au courant. v_v
Merci à tous B)
Ca à l'air pas mal ce que tu proposes.
Je ne suis pas sur qu'avec PALib on puisse jouer avec la mémoire aussi facilement.
En tout cas, ça à l'air d'être la meilleur solution (ce que j'en disais pour le mode 7, c'était surement une connerie comme je l'expliquais dans mon premier post ^^ )
on en revient finalement au probleme des libs, permettre de programmer un systeme sans connaitre le hard, ca fini par poser probleme dans des jeux un peu plus evolué.
en fait le but d'une lib c'est de fournir des fonctions premachés, mais il n'y a pas TOUT ce que l'on peut faire avec la machine(encore heureux ^^), il faut un peu mettre la main a la pate quand on souhaite utiliser des effets un peu plus poussés (meme si c'est pas le cas ici)
a partir du moment ou tu sais ou demare la memoire dedié au tiles tu fait ton affaire tout seul, allé je te fille une fonction (pour que tu ai une bonne note :p)
par exemple si la memoire bg debute au registre 0x6000000 (gba dans ce cas la)
et si tes tiles sont copié depuis le debut de la memoire
(j'ai pas testé ce code je le tappe de tete, mais ca devrai marcher normalement)
unsigned short *DEBUTMEMOIRETILESBG = (unsigned short *)0x6000000 ;
/*################################################# #################################################
## Def : copie en 16 bits(diviser la valeur par 2) ou 32 bits(diviser la valeur par 4)
## la taille des valeurs doit etre multiple de 2(16 bits) ou 4(32bits)
################################################## ################################################*/
void IRIS_IN_IWRAM CopieDo16(short *src, short *dst, unsigned short taille){
do {
*(dst) = *(src) ;
*(dst+1) = *(src+1) ;
src+=2 ;
dst+=2 ;
} while (--taille) ;
}
/*!################################################ #################################################
def : copie un certain nombre de tile dans l'emplacement reserve aux sprites.
################################################## ################################################*/
void CopieTile256(void *Tiles, unsigned short NbTiles, unsigned short Offset)
{
CopieDo16((void*)Tiles, DEBUTMEMOIRETILESBG + (Offset<<4), (NbTiles<<5)>>2) ;
}
// dans le main
int main()
{
unsigned short NbTiles = 64*64 ; // pour un carré de 8*8 tiles
unsigned short Offset = 0 ; // ou debute tes tiles
unsigned short Compteur = 0 ; // compteur de frame de l'animation
while(1)
{
CopieTile256(mestiles_tiles, NbTiles, Offset+(Compteur*NbTiles)) ; // copie un ensemble de tiles
Compteur++ ; // change d'etape de l'anim
}
}
pour le mode 7 si tu fait referance a celui qui etai disponible sur la snes oui ca a effectivement rien a voir ;)
on en revient finalement au probleme des libs, permettre de programmer un systeme sans connaitre le hard, ca fini par poser probleme dans des jeux un peu plus evolué.
en fait le but d'une lib c'est de fournir des fonctions premachés, mais il n'y a pas TOUT ce que l'on peut faire avec la machine(encore heureux ^^), il faut un peu mettre la main a la pate quand on souhaite utiliser des effets un peu plus poussés (meme si c'est pas le cas ici)
Entierement d'accord.
Une lib de haut niveau c'est tres bien pour commencer ou pour de petits projets.
On peux faire de chouette trucs avec de facon rapide et efficace, mais on butte sur des fonctions avancées.
D'ailleurs pour "Slide & Run", je ne pense pas utiliser de lib (ou peut etre certaines fonctions de libnds pour commencer) justement à cause de ce problème.
Ca va être un peu plus long, mais j'aurai plus de controles sur mes affichages ( et surtout ça va me permettre d'apprendre vraiment les modes de la consoles :p )
Oui c'est vrai que je me rends bien compte de l'effet pervers d'utiliser une librairie.
Mais pour replacer le contexte, je ne suis pas programmeur ^^ . Je suis dans une école de Game Design (construction de règles, de gameplay, mécanismes de jeux, etc ...) et pour valider nos études, on doit faire le game design complet d'un jeu et un proto pour présenter ce que ça pourrait donner.
C'est pour ça que j'ai vite choisi PA_lib, c'est ce qui me semble le mieux pour faire une maquette de jeu, sans avoir de connaissances poussées en prog, ni passer des heures sur le hardware de la DS.
Au point où nous en sommes, on a un proto jouable, et on essaie de 'polir' le proto avec des effets visuels un peu plus poussés qui sont prévus dans nos docs de game design. D'ailleurs, on ne devrait pas être noté sur l'aspect technique de notre proto, mais le fait est que ça joue forcément au final ;)
En tous cas, merci pour cette fonction, jvais essayer de regarder ça. B)
Bon, intéressant topic ^^
En ce qui concerne la maitrise sur la mémoire des fonds, pas sur que ca t'aide de passer par ndslib : il faudra recoder toute la partie qui gère les fonds (PAlib le fait indépendemment de ndslib). Plusieurs pointeurs sont dispos pour accéder directement aux tiles de PAlib, mais j'ai pas le nom de tête (suis un peu rouillé).
En ce qui concerne l'idée de changer les tiles qui ont changé, ca revient un peu à ce dont on avait parlé, Fab, de faire un énorme fond, changement de tiles dynamique (prochaine version de PAlib), et scroller écran par écran. Toujours le meme soucis par contre : ca va mettre affreusement longtemps à convertir, amis ca doit être jouable je pense.
Sinon, mode7, ca va pas aider ^^
On va pas refaire le débat sur lib ou pas ^^ sur DS, y'a plus de choses qu'on peut régler que sur gba, donc c'est un peu plus galère pour démarrer sans lib, mais la lib, du coup, limite aussi plus que sur gba... PAlib offre une configuration de base (2d dépourvue de 3d par défaut), il en existe bien d'autres qui peuvent être plus adaptées à vos besoins (ou pas ^^).
vBulletin® v.3.7.2, Copyright ©2000-2008, Jelsoft Enterprises Ltd. Tous droits réservés - Version française vbulletin-fr.org