PDA

Voir la version complète : [DEV]programme de creation de sprites


Japi
29/12/2005, 17h58
Slt!

J'ai un soucis avec la création de sprites. J'utilise actuellement BMP2SPR qui marche bien et me fournis un fichier .h contenant data+palette.
Le soucis c'est que des que ma table de sprite est trop grande, il couille et je dois la decouper puis charger apres mes tables à la suite dans le jeu. C'est pas trop genant mais si en fait, c'est genant, surtout que je comprend pas pkoi ça marche pas.

Ma question est la suivante :
Quel programme utilisez vous pour crez vos sprites sachant que je bosse en stockage 1D, et que je ne gere pas les fichiers .map pour les sprites.
Merci

Nesgba
29/12/2005, 18h03
http://playeradvance.hexadom.com/forum/showthread.php?t=438

Japi
29/12/2005, 18h48
oui mais non :)

ce programme est sans doute tres bien mais ça me va pas du tout pour faire des sprites.
Premierement, il me change ma palette. Il met du noir en couleur de transparence et moi, je travaille pas avec le noir. Pour ça que je refais toutes mes palettes à la main et bim, il pete tout.
Deuxiemement, il crée des mosaique comme si il sagissait d'une map mais la memoire pour les sprites en 1D elle s'organise pas comme ça donc ça dessine n'importe quoi.

Nesgba
29/12/2005, 19h02
oui mais non :)

ce programme est sans doute tres bien mais ça me va pas du tout pour faire des sprites.
Premierement, il me change ma palette. Il met du noir en couleur de transparence et moi, je travaille pas avec le noir. Pour ça que je refais toutes mes palettes à la main et bim, il pete tout.
Deuxiemement, il crée des mosaique comme si il sagissait d'une map mais la memoire pour les sprites en 1D elle s'organise pas comme ça donc ça dessine n'importe quoi.
ce programme est absolument parfait pour creer tes sprites.
a part si tu veut compresser tes tiles. (lzss, huffman ...)

premierement: tu t'en tape carrement de ce que devient la couleur de transparence qu'elle soit verte, rouge, noir... cela revient au meme.
tu peut definir ta couleur de transparence a prendre en compte dans le menu "couleur".

deuxiemenent: il crée des mosaiques ? c'est a dire ? tu veut dire qu'il crée une map ? si c'est que ca tu decoche la case "creer une map" ca ne change rien du tout au niveau des tiles.
les tiles de tes sprites sont gérés exactement comme les tiles de ta map, en 1D.
a condition que tu definisse des tiles en 8x8 (choisi par default).

pour gerer des tiles en 2D il faut que tu le veuille, imagine que tu ai un sprite de 32x32 ben tu defini une taille de tiles de 32x32 et hop il te crée un sprite 2D (faut vraimment avoir une raison pour utiliser cette methode car elle est tres gourmande en tiles sprites)

n'oublie pas de decocher la case "tilset optimisé".

ps: il a l'air chiant au depart comme logiciel mais tu verra avec le temp qu'il fait partie des meilleurs de tous (avec maped) ;)

Japi
29/12/2005, 19h09
bon, passons sur l'histoire de la couleur de transparence, mais moi c'est vert, et je la met en couleur 1 quand je fais ma palette sous photoshop. ça revient pas au même parce le noir pur, je l'utilise dans quasi tous mes sprites donc bon ;). C'est vrai que j'vaais pas vu dans le menu l'option sur les couleurs.

j'ai decoché :
-tileset optimisé
-générer une map

j'ai laissé en 8*8

nombre de couleur max à 255

type texte ou rotation j'ai testé les deux.
ça me fait des trucs tout pourrite sur mon zeu :(

Japi
29/12/2005, 19h14
je copie ça comme ça:

/*for(n = 0; n < 15; n++) SpritePal[n] = sprites1_palette[n];
for(n = 0; n < 3328; n++) SpriteData3[n] = sprites1_tiles[n];*/

SpriteData3, c'est l'emplacement pour les sprites + 512 puisque mode 3 (je sais mode 3 mais c'est pour les tests ;))

j'ai 15 couleurs et une table de sprite de 3328pixels

Nesgba
29/12/2005, 19h30
je copie ça comme ça:

/*for(n = 0; n < 15; n++) SpritePal[n] = sprites1_palette[n];
for(n = 0; n < 3328; n++) SpriteData3[n] = sprites1_tiles[n];*/

SpriteData3, c'est l'emplacement pour les sprites + 512 puisque mode 3 (je sais mode 3 mais c'est pour les tests ;))

j'ai 15 couleurs et une table de sprite de 3328pixels

laisse en mode texte (le mode rotation c'est juste pour les maps)
tien j'ai tapé un petit bout de code, j'ai pas testé mais ca devrai marcher ;)



unsigned short *OAMData = (unsigned short*)0x6010000 ;


void IRIS_IN_IWRAM BOOSTCopieDo16(short *src,short *dst,unsigned short taille){
do { *(dst++) = *(src++) ;} while (--taille) ;}

/*!################################################ #################################################
\fn : InsertSpriteTiles
\brief : copie un certain nombre de tile dans l'emplacement reserve aux sprites.
################################################## ################################################*/
void inline InsertSpriteTiles(void *Tiles, unsigned short NbTiles, unsigned short Offset, unsigned char couleur)
{
if (couleur==16) BOOSTCopieDo16((void*)Tiles, OAMData + (Offset<<4), NbTiles<<4) ;
else if (couleur==256) BOOSTCopieDo16((void*)Tiles, OAMData + (Offset<<4), NbTiles<<5) ; // si sprite mode 256 couleur il y a le double de tiles a copier
}


// sprite de 64x64 = 8x8 tiles = 64 tiles
InsertSpriteTiles(MonSprite_tiles, 64, 512, 256);

ps: essaye de rester tant que possible en mode 4 bits ;)

Japi
29/12/2005, 19h45
Merci Nes.

C'est gentil de me faire du code mais bon, il faut que je t'avoue sans honte que tu code assez difféemment de moi (ça veut dire "mieux" de façon camouflé ;)).
Resultat, tu tappes des trucs que je comprend même pas ou alors c'est organiser pas du tout comme moi je l'aurais fait.
Et puis j'aimerais bien comprendre pkoi ça marche pas ce que j'ai fait alors que dans ma tête, ça me parait ok.

Je te montre ce que j'ai fait mais bon, je sais que c'est chiant à lire quand on est pas dedans alors laisse faire sinon.

void UpdateSprites()
{
u16 n;

for(n = 0; n < 15; n++) SpritePal[n] = sprites1_palette[n];
for(n = 0; n < 3328; n++) SpriteData3[n] = sprites1_tiles[n];
}

ma fonction qui charge les graph de sprites en memoire. Puis pour afficher un sprite, j'ai fait une strcture avec les parametres et une fonction qui va avec, je l'appel:
InitSprite(1, 100, 144, 8, COLOR_256, 512+0);
ça initialise le sprite 1 à x=100 y =144 de taille 8*8, 256 couleur et il choppe ces données graphiques à l'emplacement 512+0 pour le debut de la memoire atrtibuée à ça.

apres, il suffit de modifier chaque parametre de façon indépendante pour modifié le sprite, on ne l'initialise qu'une fois.

Quand BMP2SPR me sortait un fichier, il faisait moitié moins en taille que celui de GBAgraphics, le soucis vient surement de là. il faudrait que ça dessine en 8bits au lieu de 16 peut-etre pour que ça marche...?

Dr.Vince
29/12/2005, 20h00
et gfx2gba il le fait pas ton truc là ??

Brunni
29/12/2005, 21h33
Je crois que gfx2gba génère des gfx de façon à peu près identique à GBA Graphics, donc je ne sais pas si ça changera quelque chose.
Sinon en ce qui concerne l'organisation des tiles, c'est asssez simple en fait. Par exemple un sprite de 16x16 est organisé comme ceci:
01
23
C'est déjà comme ça en mode 1D (sans map), donc il te suffit de copier ton tileset en VRAM (ici, taille: 4 tiles) et de créer un sprite qui utilise la tile n°0 (+512). Si tu as plusieurs sprites, tu les mets à la suite. Prenons le cas suivant: on a un sprite de 16x16 et un de 32x64 à afficher à la suite.

Le premier sprite commence à 512, comme tu l'as décrit plus haut. C'est un sprite de 16x16, donc il prend 4 tiles (en fait (16*16)/(8*8)), c'est-à-dire de 512 à 515. Comme il s'agit de tiles 8 bits dans ton cas, tu peux calculer la taille totale des données du sprite, c'est-à-dire 16*16*1 (8 bits = 1 octet). Il te suffit donc de copier les données du tileset généré par GBA Graphics, comme ceci:
memcpy(VRAM+n_tile*8*8, tonsprite_tiles, 16*16);
Si jamais: memcpy(destination, source, taille). Le n_tile est le numéro de tile, il commence à 512, et il est incrémenté du nombre de tiles, à savoir:
n_tile = n_tile + (16*16)/(8*8);
Donc pour notre prochain sprite, qui fait 32*64, on a n_tile à 516, donc on copiera 32 tiles à partir de là, jusqu'au 548, et ainsi de suite pour le prochain sprite. En général, on "vide" la VRAM des sprites à chaque frame, c'est-à-dire qu'on recommence à 512 et qu'on recopie tous les sprites, ça permet de shooter facilement les plus anciens. De cette façon tu t'en sors facilement et sans problème de déchets en mémoire vidéo.

En ce qui concerne les palettes, la couleur 0 n'importe pas, elle n'est de toutes façons pas visible, mais il y a un hack pour la changer dans GBA Graphics (invite de script -> convert.couleurzero=RGB(255,0,0) pour du rouge par exemple), cela sera appliqué à la prochaine palette qu'il génèrera et n'est pas sauvé quand le programme est quitté.

Désolé si je ne suis pas très clair... n'hésite pas à me demander des précisions ^^

Nesgba
29/12/2005, 22h30
En général, on "vide" la VRAM des sprites à chaque frame, c'est-à-dire qu'on recommence à 512 et qu'on recopie tous les sprites, ça permet de shooter facilement les plus anciens. De cette façon tu t'en sors facilement et sans problème de déchets en mémoire vidéo.

ah tu les jartes a chaque frame toi Oo, n'esce pas mieu de vidanger les tiles à la creation seulement (si et seulement si on crée un sprite vide pour ecrire du texte par exemple sinon les nouveaux tiles giclent les anciens) et laisser les innutilisés hors ecran ? facile a gerer avec une bonne structure ca.

mais c'est vrai qu'avec cette methode si tu crée 128 sprites vides d'affilé tu prend des risques :p

Brunni
30/12/2005, 00h00
mais c'est vrai qu'avec cette methode si tu crée 128 sprites vides d'affilé tu prend des risques :p
Je parlais des tiles en fait, mais pour l'OAM un petit DMA et c'est ok :p
Enfin pour les tiles tu peux aussi faire comme ça, c'est un peu plus compliqué mais c'est bien optimisé. Le seul problème c'est qu'il faut obligatoirement les copier pendant la VBLANK, donc il faut faire un tableau qui contient les tiles utilisées et faire la copie à la fin, et l'intérêt devient limite parce que tu vas perdre du temps à savoir si un sprite doit être giclé (il faut faire un compteur pour savoir combien de fois telle ou telle tile a été utilisée et shooter celles qui n'ont pas été utilisées depuis longtemps) sans compter que lorsqu'ils commencent à se chevaucher à cause de la mémoire pleine, ça devient compliqué à gérer.
Perso, j'utilise 16 à 24K pour les sprites dynamiques et le reste (8K) pour les sprites constants (utilisés à toutes les frames) comme ça ça fait moins de copie à chaque fois.

Nesgba
30/12/2005, 02h00
Je parlais des tiles en fait, mais pour l'OAM un petit DMA et c'est ok :p
Enfin pour les tiles tu peux aussi faire comme ça, c'est un peu plus compliqué mais c'est bien optimisé. Le seul problème c'est qu'il faut obligatoirement les copier pendant la VBLANK, donc il faut faire un tableau qui contient les tiles utilisées et faire la copie à la fin, et l'intérêt devient limite parce que tu vas perdre du temps à savoir si un sprite doit être giclé (il faut faire un compteur pour savoir combien de fois telle ou telle tile a été utilisée et shooter celles qui n'ont pas été utilisées depuis longtemps) sans compter que lorsqu'ils commencent à se chevaucher à cause de la mémoire pleine, ça devient compliqué à gérer.
Perso, j'utilise 16 à 24K pour les sprites dynamiques et le reste (8K) pour les sprites constants (utilisés à toutes les frames) comme ça ça fait moins de copie à chaque fois.

moi la totalitée de mes sprites sont gerés de facon dynamique, j'ai une structure pour chaque sprite qui m'indique ou se trouve le debut des tiles que celui ci utilise et la taille en tiles du sprite, et quand j'efface ce sprite je le marque comme "non utilisé" et donc ses tiles deviennent libres pour un autre sprite que je crée par la suite. au fil du temp ca devient un veritable gruyere... et encore je gere pas les tiles placé de facon non continue sinon ca serai vraiment pire et la copie des tiles deviendrai vite tres lente puisqu'il faudrai forcement copier tile par tile.
je pourrai optimiser les tiles + que ca en decalant pour tout les tiles a chaque fois mais j'en ai pas l'utilitée pour le moment.

j'utilise pas de buffer soft et je copie pas mes tiles pendant la vblank (oui je sais c'est pas bien) :p

Japi
30/12/2005, 06h42
gfx2gba me fait pareil en effet et d'ailleurs, je comprend pas pkoi ça marche si bien avec BMP2SPR et pas les autres (cette histoire de 8bits 16bits est la cause, j'en suis presque sur mais ???).
Sinon, j'ai pas encore trouvé, j'suis passé à autre chose (faut faire du game design de temps en temps aussi, pas que la prog dans la vie) mais bon, faudra bien que je mette la main dessus.
Moi aussi je gere les sprites avec un systeme dynamique qui prend le dernier sprite libre quand il y en a besoin puis si il ne sert plus, il retourne dans le stock des sprites non utilisés, ça m'a paru obligatoire des le debut de faire un systeme comme ça alors c'est une des premieres choses que j'ai fait.

Question pour essayer d'avancer : GBAgraphics ou GFX2GBA sortent les fichiers sprites en combien de bits? quand j'ai fait 8 bits ou 16 bits sur GBAgraphics, j'ai pas vu la diff au niveau de la quantité de donnée. Je pense que si j'arrive à sortir mes sprites en 16bits, ça peut marcher vu que là, je suis en mode 3, même si je n'utilise que 256 couleurs (soit 8 bits).

Japi
30/12/2005, 22h34
alors, apres pleins d'essais et tentatives avec environs 5 soft de convertion différents en testant pleins d'options...J'AI TROUVE!!!

donc finnalement j'utilise WINGIT, le convertisseur que préconise TONC.
Les parametres que je mets pour que ça fonctionne sont :
une palette de 256couleurs
image Tile, en 8bits de profondeur, pas de compression
pas de metaTile, les tiles de 8*8 sinon.
Un truc super classique en gros.

Si je fais ça avec gfx2gba par exemple ça marche pas...mystere.
Dans Wingit, ya une option que j'ai trouvé nullepart ailleurs, c'est le type de donnée de sortie. J'ai choisi u16 et ça passe nikel.
En regardant ce que donnent GFX2GBA ou GBAGraphics, ça sort un tableau de u8 pour les data et donc le soucis viendrait de là, à priori.
Je peux ptet m'arranger pour prendre le tableau de u8 et que ça passe mais j'ai pas regardé ça encore.

Brunni
30/12/2005, 22h40
Tu dis que ça ne marche pas avec gfx2gba mais qu'est-ce qui se passe au juste? Les couleurs sont fausses? Les tiles sont corrompues, mal placées, ... ?

Japi
30/12/2005, 22h54
de toute façon, il ne faut pas se leurer, si ça marche pas, ça vient pas de gfx2gba ou autre, mais de la façon dont je stocke les données dans mon code, c'est sur.
Je vois pas pkoi tout le monde utilisent ces softs et moi j'y arrive pas, j'ai du louper un truc dans les registres OAM ou bien je sais pas, un type qui est faux...?

Je vais te mettre une capture de l'affichage de ma table de sprite sous VBA, tu verras le resultat. Je charge ça sur un ftp et je fais un post pour te montrer.

Japi
31/12/2005, 13h03
alors voilà les captures, dsl, je voulais poster ça hier mais soucis de connexion, j'arrivais pas à up sur le serveur.

Voila ma table de sprites de base, 14 couleurs avec un vert (0,255,0) en fond et indexe 0 de la palette:

http://pgcd.site.voila.fr/sprites1.bmp

Affichage de la table sur un fond en mode 3.
La table est convertit en 256c avec BMP2SPR (on remarque des defaults dans les sprites sur la fin, decalage de la derniere ligne, tres bizarre):
http://pgcd.site.voila.fr/bmp2spr.jpg

Idem mais ce coup-ci, la table est convertit avec GFX2GBA (16couleurs, tiles 8*8, pas de meta, pas de map, pas de compression, pas d'optimisation de tile):
http://pgcd.site.voila.fr/gfx2gba16c.jpg

GFX2GBA encore mais 256couleurs (256 couleurs, tiles 8*8):
http://pgcd.site.voila.fr/gfx2gba256c.jpg

Et enfin avec Wingit (256c, 8*8...enfin pareil qu'au dessus) mais ce coup-ci, c'est parfait:
http://pgcd.site.voila.fr/wingit.jpg

Merci de ne pas réutiliser mes images sans m'en faire la demande avant.

Nesgba
31/12/2005, 13h47
a moi de te poser une question:
on t'a fillé 2 methodes pour copier tes sprites, esque tu au moin essayé de les utiliser ?

Merci de ne pas réutiliser mes images sans m'en faire la demande avant
:blink: ah c'est fortement dommage ca, j'attendai justement que tu poste des gfx pour te les derober et les mettres discretement dans mes jeux !! ca manque cruellement de gfx sur le net :unsure:
tu devrai poster ton code, a moin que tu ai peur qu'on te le derobe aussi :ph34r:

(le prend pas mal je plaisente bien sur ;) )

Alekmaul
31/12/2005, 13h57
ton problème ressemble au problème d'alignement de données qu'avait eu Dr Vince (je crois ... :| ) à une époque ...
Essayes de déclarer tes sprites, etc avec __attribute__ ((aligned (2))) ou encore __attribute__ ((aligned (4))), par exemple :
u8 __attribute__ ((aligned (2))) toto;

Perso, pour les sprites, j'utilise gfx2gba et jamais je n'ai eu de problème ...

Donnes nous le résultat ^^

Japi
31/12/2005, 13h58
Nes, je te l'ai dit, j'ai pas compris ton code...honte sur moi, oui, dsl. J'essaye de bien comprendre comment ça marche et pas juste de copier des lignes sans comprendre bien ce qu'il se passe, c'est pour ça que j'utilise pas de librairie entre autre et donc je suis moins performant mais c'est pas grave.

Pour les gfx, c'est une question de respect, si tu les veux, mais j'en doute, tu me demande et c'est bon. Par contre, se dire que cela va de soit, ce n'est pas du tout pareil.
J'ai vu trop de gens se servir du travail des autres sans remerciement ni autre, que ce soit du code et le reste, surtout sur des plateformes libres, les gens se disent Open, ils font partie de la "communauté" (ironie) mais l'echange est à sans unique et à part pomper, il reste rien d'eux. C'est un debat fort interressant que je ne continuerais pas ici mais ailleurs pkoi pas. Tjrs est-il que c'est une question de mentalité et de respect comme je l'ai dejà dit. Je ne suis pas contre le fait qu'on utilise mes sprites (si ils en valent la peine) mais qu'on respecte le travail de chacun.

Alekmaul
31/12/2005, 14h09
J'ai vu trop de gens se servir du travail des autres sans remerciement ni autre, que ce soit du code et le reste, surtout sur des plateformes libres, les gens se disent Open, ils font partie de la "communauté" (ironie)
C'est pas faux mais qu'est-ce que cela peut faire puisque c'est open ...
Si on utilise les gfx ou le code de quelqu'un et que ce dernier l'a laissé publique, je ne vois pas le problème, l'auteur pourra toujours prétendre à son bon droit ... Pour ma part, je cite toujours d'où vient le code / gfx quand cela est "pompé" quelque part (par exemple, MarcaDS repose sur Mame et Vantage, comme l'explique le readme ^^ ).

Japi
31/12/2005, 14h17
oui, et bien c'est pour ça que j'ai mis cette ligne.

Sinon,
u8 __attribute__ ((aligned (2))) toto;
ça fait quoi en gros ? ça prend les "char" et ça les depose par deux comme si c'etait des "short"?
Merci

Brunni
31/12/2005, 14h33
Là tu es en mode 3, donc c'est pas de tiles que tu as besoin, mais de bitmaps.
Depuis GBA Graphics, essaie d'aller dans Bitmaps (le dernier dossier), puis 8 bits, et crées-en une depuis là, ça devrait aller ^^
Et si ça ne marche pas, poste le résultat stp. :)

Japi
31/12/2005, 14h39
Même pour les sprites, il faut faire ça?
Je croyais que le buffer pour les sprites etaient séparé du mode dans lequel tu etais et donc que ça avait pas d'incidence.

http://pgcd.site.voila.fr/GBAGraphBMP8b.jpg

Brunni
31/12/2005, 15h31
Ha sorry j'ai mal compris, pour les sprites c'est bien ça.
Et avec GBA Graphics en 8 bits, 16x16, ça donne quoi?
Est-ce que tu fais une copie DMA pour tes tiles? Si c'est une copie 32 bits, essaie de la passer en 16 bits, ou remplace par un memcpy juste pour le test.

Japi
31/12/2005, 15h37
Je ferais les tests demains, là je dois partir, bonne année à tous.

Brunni
31/12/2005, 15h39
Bonne année à toi ^^

Dr.Vince
31/12/2005, 15h54
ton problème ressemble au problème d'alignement de données qu'avait eu Dr Vince (je crois ... :| ) à une époque ...
Essayes de déclarer tes sprites, etc avec __attribute__ ((aligned (2))) ou encore __attribute__ ((aligned (4))), par exemple :
u8 __attribute__ ((aligned (2))) toto;

Perso, pour les sprites, j'utilise gfx2gba et jamais je n'ai eu de problème ...

Donnes nous le résultat ^^

effectivement ça ressemble à un problème de décalage

Mollusk
02/01/2006, 21h03
si tu as un soucis de décalage, essai de chopper une version plus récente de gfx2gba, elle ajoute l'align par défaut...

Sinon, tu as aussi PAGfx que tu peux tester, qui fonctionne un peu comme gfx2gba mais qui apporte quelques petits plus (plus simple à utiliser, génération de fichiers .h et .c contenant tous les autres fichiers, etc...)
http://playeradvance.hexadom.com/forum/showthread.php?t=442&highlight=PAGfx

Tannis Dragon
08/07/2006, 16h05
Salut, J'avais aussi ce soucie de décalage, mais en utilisant la DMA en paquet de 16 je ne l'ai plus :)
parcontre j'essaye aussi de faire comme Japi, en mode 3 faire afficher un sprite. Je suis presque arrivé mais... J'ai créer un sprite de 16x16 et j'ai utiliser GBA graphics, pas de soucie jusque là, mais quand je déclare a l'attribut 16x16 en mode SQUARE, et que je le fais afficher sur mon emulateur, j'ai qu'une partie de mon sprite (la premiere partie en mosaique de 8x8).

En regardant dans OAM viewer j'ai le meme morceau (donc le premier mosaique de 8x8), le reste c'est du n'importe quoi et en regardant dans TILES viewer j'ai bien mon sprite diviser en 4 morceau de mosaique de 8x8 et non une mosaique de 16x16...

De là je pourrais me dire, la copie dois foirée ou mon prog est mal foutu.. Mais j'ai essayer en mode 1 et là mon sprite apparait nickel et il le prend bien comme un sprite de 16x16...

Si quelqu'un a une idée a me soumette ou une explication. Dans GBA graphic je met bien en 16x16 avec une palette de 16 couleurs. Une fois mon PB résolue je pense que je pourrais le remettre sous sa forme 16x8 qui est la forme d'origine de mon sprite en utilisant WIDE et 16x16 comme attribut.

J'ai rééditer mon poste, pour dire que j'ai trouver mon erreur (j'ai poster le pourquoi du comment dans la partie débutant ;) ) voilà :)