GraphX Sprite Maker beta 1.0 - Page 1

"GraphX sprite Maker" (GSM) est un programme qui vous permet de concevoir des sprites
au format de de la librairie GraphX. Le programme a pour fonction :
- Convertir une image BMP en niveaux de gris (NG4).
- Lister et afficher tous les sprites au format 8*8 ; 16*16 ; 32*32 selon le choix de l'utilisateur.
- Exporter les sprites sous forme d'un ficher *.h qui sera exploitable pour le développement de programmes incluant la librairie GraphX.

Il est téléchargeable à partir des adresses suivantes:
http://nmatrice.tsx.org
http://www.i-station.fr.fm
http://www.ifrance.com/by-laurent

ba, c du rechauffe, ça fait longtemps que je connais. (envirron 1/2 h :-D)

PETITE PRECISION : pour le moment vous devez télécharger les fichiers séparément et les installer "à la main", mais il est bien évident que tout sera automatisé dans la prochaine bêta de GraphX (cet éditeur sera inclus dans le programme d'installation)

Je tiens à préciser à la T3 que j'ai temporairement pris leur algorithme de NG4 (Snesconv)
Je veux pas passer pour un LamerZ alors je l'ai dis dans ma doc. Dès que j'aurais programmé ma propre routine je laisse celle de la T3 tranquille.
Désolé de ne pas vous avoir prévenu plus tôt la T3

Est-ce qu'il serait possible de faire comme Olivier, de faire les déclarations sur ce modèle :

char NomDuSprite_data[]= {0x..., ...};
GX_sprite_XX_nomask *NomDuSprite = (GX_sprite_XX_nomask *)NomDuSprite_data;

(en remplaçant XX par 08/16/32 suivant la taille du sprite, et nomask par masked pour les sprites masqués)



Il est super bien foutu ton convertisseur !

Je n'arrive pas à convertir mon sprite :




Quelles que soient les valeurs de seuil, le gris foncé n'apparaît pas !

C'est pas bien compliqu" de me demandé de rendre compatible XSpriteEditor v3 pour GX.. mais bon si vous voulez en faire un

Fais-le !! ça me permettra enfin de sortir GraphX ß1.1.
Parceque là j'attend que nmatrice est fini sont éditeur

Quand il l'aura fini, ça fera 3 progs pour GX : XspriteEditor & GSM & TIpaintPlus

Erf la je suis occupé a me faire des fontes pour ma ptite rom

Bon je le ferais

Pour le moment on peur dire que la beta de GSM est utilisable mais il y a encore quelques petits trucs a modifier ou a ajouter (comme la gestion des masques)

ca ne vaudrait pas X2S

nmatrice : T'as vu le post #5 ?

ouai je vois le prob... c'est un problème de réglage...
pour ça il faudra aussi que je trouve un moyen

J'ai ma petite idée là-dessus...

Quand tu additionnes les 3 composantes, si tu ne stockes pas le résultat dans un short, il sera faux plus de 2 fois sur 3

Et puis la méthode de conversion que tu expliques dans ton readme est bizarroïde c'est peut-être une cause du pb.
Voici comment je faisais dans l'encodeur AMC2, et ça marchait hyper-bien :

Tout d'abord, on divise en 4 la somme maximale qu'on peut obtenir : 3*255 / 4 = 191.
Les seuils vont alors être :
1*191= 191
2*191= 382
3*191= 573
On a bien 3 seuils parfaitement "équidistants".

Maintenant, la conversion :

if (somme < 191)
{
  // on considère le pixel comme étant noir
}
else if (somme < 382)
{
  // on considère le pixel comme étant gris foncé
}
else if (somme < 573)
{
  // on considère le pixel comme étant gris clair
}
else
{
  // on considère le pixel comme étant blanc
}

Voilà, et les trois seuils peuvent être changés par l'utilisateur s'il le souhaite, comme avec la version actuelle

Thibaut a écrit :
J'ai ma petite idée là-dessus...

Quand tu additionnes les 3 composantes, si tu ne stockes pas le résultat dans un short, il sera faux plus de 2 fois sur 3

Peut-être aussi qu'il manque des unsigned.

Exact !!! merci Kevin

nmatrice : il faut aussi que tu transtypes chaque composante en unsigned char

Ca sert a rien de faire la convertion... elle sera jamais aussi bien faite qu'avec psp ou autre...

À sa place, je n'utiliserais que des unsigned char depuis le début!

TiMad : parfaitement d'accord

Ca dépend de la façon dont il lit la composante.

Bon les gars voilà le code : (je précise que c'est celui de Snesconv) :

TColor col;
int pwr;
for(int x=0;x<Image1->Width;x++)
for(int y=0;y<Image1->Height;y++)
{
col=Image1->Canvas->Pixels[x][y];
if(col!=clFuchsia)
{
pwr=(col&0x000000ff)+((col&0x0000ff00)/256)+(col&0x00ff0000)/(256*256);
if(pwr<CSpinEdit1->Value)
Image1->Canvas->Pixels[x][y]=clBlack;
if(pwr>=CSpinEdit1->Value&&pwr<CSpinEdit2->Value)
Image1->Canvas->Pixels[x][y]=clGray;
if(pwr>=CSpinEdit2->Value&&pwr<CSpinEdit3->Value)
Image1->Canvas->Pixels[x][y]=clSilver;
if(pwr>=CSpinEdit3->Value)
Image1->Canvas->Pixels[x][y]=clWhite;
}
}
CGauge1->Progress=0;

Holàlà quelle horreur !!!!

Prend le code que je t'ai filé plus haut.

oui je sais qu'il est largement optimisable.
Mais le principe est le même que le tiens.
De toutes façon je voulais pas laiser ça comme ça. Même mon algo de listage de sprites je vais l'optimiser et le reste aussi d'ailleur. Mais une beta c'est une beta

Un petit conseil (from Pen^2) : utilise une table de hachage pour élaguer l'arbre des motifs

d'accord, dés que tu m'aura expliqué c'est quoi une table de hachage et l'arbre des motifs!

Et tu peux trier les motifs par checksums croissants, dans les arbres binaires.
Ca permettra une recherche aussi rapide que la dichotomie mais beaucoup plus simplement.

[edit]J'avais pas vu ton post #24. Je vais te l'expliquer. Patiente, ça risque de prendre quelques lignes de texte [/edit]

Y a quelqu'un qui connais où trouver de la doc sur les tables de hachage?

Je vais t'expliquer ça, attend

ba reprend l'ancien topic