Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.
La shoutbox n'est pas chargée par défaut pour des raisons de performances. Cliquez pour charger.

Forum Casio - Autres questions


Index du Forum » Autres questions » Réduire la taille de deux sprites presques identiques ?
Drakalex007 Hors ligne Membre Points: 687 Défis: 0 Message

Réduire la taille de deux sprites presques identiques ?

Posté le 23/12/2014 13:06

Salut à tous,

J'ai un petit problème: j'ai trois chaines de sprites déclarées comme ceci:

http://pastebin.com/6xYWLG5k

Et le problème c'est que si vous regardez attentivement, ces sprites sont exactement les mêmes à quelques petits détails près. Y'a-t-il un moyen de réduire leur taille en disant par exemple que les éléments n°x de la chaine sont les memes et que les éléments n°y sont différents ?

Merci


Dodormeur Hors ligne Ancien rédacteur Points: 3965 Défis: 84 Message

Citer : Posté le 23/12/2014 13:23 | #


Nan mais vous savez que les sprites sont juste des tableaux non?
Il te suffit de modifier les cases différentes, tu pourrais même faire une fonction qui fait cela automatiquement.

C'est comme vouloir changer "bonjour" en "lonjour", il te suffit de modifier la case [0] du tableau en l
Pokemon !!!!!! => pokemon stadium/battle

mes meilleurs jeux
Cliquer pour enrouler
un jeu avec des niveaux de gris mais compatible SH4 (mais en monochrome pour les SH4) => bomberman
envie de plonger dans la mer pour ramasser des tresors? => ballon sea
envie de sauver l'univers dans un jeu avec une longue durée de vie? => saviors of the future
un add-in addictif avec plein de secret et de trophées => evasion survival
un shmup bien dur et sadique => saviors 2

projets
Cliquer pour enrouler

pokemon
Cliquer pour enrouler



encodage des données de combat (sprite, attaques et nom)
   100%

systeme de combat
   100%

encodage des données de pokemon (niveau d'apprentisage et evolution)
   100%


moteur de la carte
   50%

level design
   1%

finition de pokemon jade
   42%

merci a tout le monde pour son soutien


projets que je soutiens
Cliquer pour enrouler
minecraft de limachi
zelda prizm de smashmaster (en esperant qu'il puisse le finir)
les tests de marmotti
un RPG de dark storm (dont je connais le nom, mais pas vous ) Arcuz !
Drakalex007 Hors ligne Membre Points: 687 Défis: 0 Message

Citer : Posté le 23/12/2014 13:27 | #


Oui, mais y'a-t-il un moyen de le faire pour réduire la taille du programme en octets ? Ta technique ne réduit pas la taillé !
Dodormeur Hors ligne Ancien rédacteur Points: 3965 Défis: 84 Message

Citer : Posté le 23/12/2014 13:30 | #


Si, au lieu d'avoir

unsigned char carreNoir[8] = {0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF};
unsigned char carreNoir2[8] = {0xFF,0xFF,0xFF,0x81,0x81,0xFF,0xFF,0xFF};
ML_bmp_or(carreNoir,0,0,8,8);
ML_bmp_or(carreNoir2,0,0,8,8);


tu as


unsigned char carreNoir[8] = {0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF};
ML_bmp_or(carreNoir,0,0,8,8);
carreNoir[3] = 0x81;
carreNoir[4] = 0x81;
ML_bmp_or(carreNoir,0,0,8,8);


Ce qui prend moins de place dans la taille du programme.

Et pis sinon tu peux regarder des algos de compression/décompression, c'est long mais ca devrait t'auder
Pokemon !!!!!! => pokemon stadium/battle

mes meilleurs jeux
Cliquer pour enrouler
un jeu avec des niveaux de gris mais compatible SH4 (mais en monochrome pour les SH4) => bomberman
envie de plonger dans la mer pour ramasser des tresors? => ballon sea
envie de sauver l'univers dans un jeu avec une longue durée de vie? => saviors of the future
un add-in addictif avec plein de secret et de trophées => evasion survival
un shmup bien dur et sadique => saviors 2

projets
Cliquer pour enrouler

pokemon
Cliquer pour enrouler



encodage des données de combat (sprite, attaques et nom)
   100%

systeme de combat
   100%

encodage des données de pokemon (niveau d'apprentisage et evolution)
   100%


moteur de la carte
   50%

level design
   1%

finition de pokemon jade
   42%

merci a tout le monde pour son soutien


projets que je soutiens
Cliquer pour enrouler
minecraft de limachi
zelda prizm de smashmaster (en esperant qu'il puisse le finir)
les tests de marmotti
un RPG de dark storm (dont je connais le nom, mais pas vous ) Arcuz !
Drakalex007 Hors ligne Membre Points: 687 Défis: 0 Message

Citer : Posté le 23/12/2014 13:33 | #


Ok merci je m'y pencherais !
Xavier59 Hors ligne Membre de CreativeCalc Points: 1337 Défis: 12 Message

Citer : Posté le 23/12/2014 13:33 | #


Si cette technique réduit la taille, prenons un exemple :


unsigned char personnage[] = {0xff,0xff,0xff};
unsigned char personnage2[] = {0xff,0xff,0x02};
ML_bmp_or_cl(personnage.....);
ML_bmp_or_cl(personnage2.....);
ML_display_vram();


On peut remplacer ça par :


unsigned char personnage[] = {0xff,0xff,0xff};
ML_bmp_or_cl(personnage ..... );          // On affiche le premier personnage
personnage[3] = 0x02
ML_bmp_or_cl(personnage ..... );          // On affiche le second personnage
ML_display_vram();                             // On montre la vram


Ici, dans notre cas, le volume n'est pas vraiment réduit, mais quand tu commence à avoir de gros sprite, ça peut être plutôt utile.


Ajouté le 23/12/2014 à 13:34 :
Grillé
1337
Dodormeur Hors ligne Ancien rédacteur Points: 3965 Défis: 84 Message

Citer : Posté le 23/12/2014 13:36 | #


Si, le volume est quand même réduit
Il y a 3 octets en moins dans la mémoire, et il me semble (mais je ne suis pas sur), que la création (unsigned char []) prend autant de place que le changement de valeur ([3] = 0x02), Donc c'est plus court de 3 octets

personnage[3] = 0x02
est plus court que
unsigned char personnage2[] = {0xff,0xff,0x02};


Mais bon, cela reste de l'optimisation au cas par cas, c'est impossible pour des gros projets avec des milliers de sprites
Pokemon !!!!!! => pokemon stadium/battle

mes meilleurs jeux
Cliquer pour enrouler
un jeu avec des niveaux de gris mais compatible SH4 (mais en monochrome pour les SH4) => bomberman
envie de plonger dans la mer pour ramasser des tresors? => ballon sea
envie de sauver l'univers dans un jeu avec une longue durée de vie? => saviors of the future
un add-in addictif avec plein de secret et de trophées => evasion survival
un shmup bien dur et sadique => saviors 2

projets
Cliquer pour enrouler

pokemon
Cliquer pour enrouler



encodage des données de combat (sprite, attaques et nom)
   100%

systeme de combat
   100%

encodage des données de pokemon (niveau d'apprentisage et evolution)
   100%


moteur de la carte
   50%

level design
   1%

finition de pokemon jade
   42%

merci a tout le monde pour son soutien


projets que je soutiens
Cliquer pour enrouler
minecraft de limachi
zelda prizm de smashmaster (en esperant qu'il puisse le finir)
les tests de marmotti
un RPG de dark storm (dont je connais le nom, mais pas vous ) Arcuz !
Lephenixnoir Hors ligne Administrateur Points: 24120 Défis: 170 Message

Citer : Posté le 23/12/2014 14:08 | #


Dodormeur a écrit :
Si, au lieu d'avoir

unsigned char carreNoir[8] = {0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF};
unsigned char carreNoir2[8] = {0xFF,0xFF,0xFF,0x81,0x81,0xFF,0xFF,0xFF};
ML_bmp_or(carreNoir,0,0,8,8);
ML_bmp_or(carreNoir2,0,0,8,8);


tu as


unsigned char carreNoir[8] = {0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF};
ML_bmp_or(carreNoir,0,0,8,8);
carreNoir[3] = 0x81;
carreNoir[4] = 0x81;
ML_bmp_or(carreNoir,0,0,8,8);


Ce qui prend moins de place dans la taille du programme.

Et pis sinon tu peux regarder des algos de compression/décompression, c'est long mais ca devrait t'auder


Oui sauf que tu dois quand même te taper
mov carreNoir, r0
! Appel de ML_bmp_or
mov #0x81, r1
mov r1,@(r0,3)
mov #0x81, r2 ! SDK
mov r1,@(r0,4)

Ça fait ici pile 8 octets de code en plus. Qui a dit qu'on gagnait en place ?
Mon graphe (25 Fév): (PythonExtra ; fxsdk#11 ; gint#27 ; (Rogue Life || HH2) ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Ninestars Hors ligne Membre Points: 2461 Défis: 24 Message

Citer : Posté le 23/12/2014 14:10 | #


En fait la technique de Dodormeur fonctionne mais faut surtout pas faire ! ("surtout"... bon après c'est un choix hein )

Comme tu as fait en premier, c'est d'utiliser des const unsigned char* l'avantage comparé aux unsigned char* c'est qu'ils sont stockés dans la mémoire de stockage ! Donc tu as 1,5 Mo d'espace !!! C'est largement suffisant, pas besoin d'économiser des bouts d'octet
Tous ce qui n'est pas const est stocké dans la RAM, et là tu as seulement 8000 octet grosso modo.
Lephenixnoir Hors ligne Administrateur Points: 24120 Défis: 170 Message

Citer : Posté le 23/12/2014 14:17 | #


Ninestars a écrit :
Comme tu as fait en premier, c'est d'utiliser des const unsigned char* l'avantage comparé aux unsigned char* c'est qu'ils sont stockés dans la mémoire de stockage ! Donc tu as 1,5 Mo d'espace !!! C'est largement suffisant, pas besoin d'économiser des bouts d'octet
Tous ce qui n'est pas const est stocké dans la RAM, et là tu as seulement 8000 octet grosso modo.

Euh, tu es sûr de ça ? Les linker script utilisés pour la compilation avec gcc semblent bien agir comme ça mais qu'en est-il de l'optimizage linker d'hitachi ? Et puis les const comme les variables sont chargés dans le g1a donc dans la mémoire virtuelle dans tous les cas...
Mon graphe (25 Fév): (PythonExtra ; fxsdk#11 ; gint#27 ; (Rogue Life || HH2) ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Ninestars Hors ligne Membre Points: 2461 Défis: 24 Message

Citer : Posté le 23/12/2014 14:22 | #


On en avait parlé sur le topic Dodormeur qui commençait son pokemon, il voulait savoir si il pouvait stocker l'image de tous ses pokemon
Après je peux rien garantir
Drakalex007 Hors ligne Membre Points: 687 Défis: 0 Message

Citer : Posté le 23/12/2014 14:30 | #


D'ailleurs je profite de ce topic pour parler d'un deuxième problème au lieu d'en recréer un, j'ai 2 sprites alpha de 10*16, quand je les affiche avec ML_bmp_or(sprite,x,y,10,16);, il se passe ceci, tout marche parfaitement:
http://www.noelshack.com/2014-52-1419341433-1.png

Maintenant, quand je mets un carré noir et que je les déclare en ML_bmp_and(sprite,x,y,10,16);, il se passe ceci :
http://www.noelshack.com/2014-52-1419341433-2.png
Le premier a une bande blanche qui n'a rien a faire la tandis que le deuxième est normal, vous savez à quoi c'est dû ?

Les sprites en hexa:


le premier :
{0xC1, 0xC0, 0xC1, 0xC0, 0xC1, 0xC0, 0x00, 0x40, 0x80, 0xC0, 0x00, 0x40, 0x00, 0x40, 0x00, 0x00, 0x80, 0x40, 0x80, 0x40, 0x00, 0xC0, 0x80, 0x40, 0xC0, 0x40, 0xC2, 0xC0, 0x87, 0xC0, 0x8F, 0xC0};
le deuxième:
{0xF7, 0x7F, 0xC0, 0x7F, 0x80, 0x7F, 0x00, 0x7F, 0x00, 0xFF, 0x00, 0x7F, 0x00, 0x7F, 0x00, 0x3F, 0x80, 0x7F, 0x80, 0x7F, 0x40, 0xFF, 0xA0, 0x7F, 0xC0, 0x7F, 0xC2, 0xFF, 0x87, 0xFF, 0x8F, 0xFF};
  

Dodormeur Hors ligne Ancien rédacteur Points: 3965 Défis: 84 Message

Citer : Posté le 23/12/2014 14:31 | #


Nan mais même en const c'est dans la RAM hein, faut pas croire, c'est pour cela que j'ai eu des problème avec la gestion de la mémoire dans pokemon

Et pis si tu peux réduire de 50% la taille de tes sprites (animations très ressemblantes par exemple), cela peut sauver 30 Ko dans les gros projets (dans pokemon, les sprites font +/- 80Ko), donc pas qu'une histoire de quelques octets

Et effectivement, on perd quelques octets au niveau de l'assembleur (j'ai bien dit que je n'en était pas sur, maintenant c'est confirmé ), mais comme pour tout cela dépend du contexte d'utilisation, et dans le cas d'un sprite de 8*3 ce n'est évidemment pas optimal
Pokemon !!!!!! => pokemon stadium/battle

mes meilleurs jeux
Cliquer pour enrouler
un jeu avec des niveaux de gris mais compatible SH4 (mais en monochrome pour les SH4) => bomberman
envie de plonger dans la mer pour ramasser des tresors? => ballon sea
envie de sauver l'univers dans un jeu avec une longue durée de vie? => saviors of the future
un add-in addictif avec plein de secret et de trophées => evasion survival
un shmup bien dur et sadique => saviors 2

projets
Cliquer pour enrouler

pokemon
Cliquer pour enrouler



encodage des données de combat (sprite, attaques et nom)
   100%

systeme de combat
   100%

encodage des données de pokemon (niveau d'apprentisage et evolution)
   100%


moteur de la carte
   50%

level design
   1%

finition de pokemon jade
   42%

merci a tout le monde pour son soutien


projets que je soutiens
Cliquer pour enrouler
minecraft de limachi
zelda prizm de smashmaster (en esperant qu'il puisse le finir)
les tests de marmotti
un RPG de dark storm (dont je connais le nom, mais pas vous ) Arcuz !
Ninestars Hors ligne Membre Points: 2461 Défis: 24 Message

Citer : Posté le 23/12/2014 15:01 | #


Ah ok je m'excuse alors
Mais comment t'as fait avec tes 80 Ko alors ?

Attention à la façon dont tu affiches tes sprites. Tu as le choix entre and or et xor, dans certain cas, deux affichages différents doivent être appliqués
Drakalex007 Hors ligne Membre Points: 687 Défis: 0 Message

Citer : Posté le 23/12/2014 15:07 | #


Non mais l'affichage avec or marche très bien, c'est le and qui marche pas, pourtant le deuxième marche bien et les sprites sont identiques en taille je ne comprends pas !
Dodormeur Hors ligne Ancien rédacteur Points: 3965 Défis: 84 Message

Citer : Posté le 23/12/2014 15:08 | #


Ben simplement l'add-in fait 200 Ko
Et sinon je m'arrange pour ne pas charger tout les sprites en même temps, mais je charge une partie des sprites, et puis je retient celui dont j'ai besoin avec un tableau dynamique, et puis je charge les autres sprites (avant cette méthode, le jeu plantait parfois lors des animations de combats)

Ajouté le 23/12/2014 à 15:10 :
@drak : il me semble (mais ce n'est qu'un souvenir) qu'une des fonction ML_and ne marchait pas bien, essaye avec l'autre (cl), si cela marche mieux (c'est PL qui l'avait dit et qu'il contait aussi corriger cela dans une prochaine mise a jour de ML)
Pokemon !!!!!! => pokemon stadium/battle

mes meilleurs jeux
Cliquer pour enrouler
un jeu avec des niveaux de gris mais compatible SH4 (mais en monochrome pour les SH4) => bomberman
envie de plonger dans la mer pour ramasser des tresors? => ballon sea
envie de sauver l'univers dans un jeu avec une longue durée de vie? => saviors of the future
un add-in addictif avec plein de secret et de trophées => evasion survival
un shmup bien dur et sadique => saviors 2

projets
Cliquer pour enrouler

pokemon
Cliquer pour enrouler



encodage des données de combat (sprite, attaques et nom)
   100%

systeme de combat
   100%

encodage des données de pokemon (niveau d'apprentisage et evolution)
   100%


moteur de la carte
   50%

level design
   1%

finition de pokemon jade
   42%

merci a tout le monde pour son soutien


projets que je soutiens
Cliquer pour enrouler
minecraft de limachi
zelda prizm de smashmaster (en esperant qu'il puisse le finir)
les tests de marmotti
un RPG de dark storm (dont je connais le nom, mais pas vous ) Arcuz !
Drakalex007 Hors ligne Membre Points: 687 Défis: 0 Message

Citer : Posté le 23/12/2014 15:15 | #


Effectivement dodormeur, avec _cl ca marche, c'est bien un bug vu que la même fonction sans _cl marche partout dans le reste de mon code !
Dark storm Hors ligne Labélisateur Points: 11629 Défis: 176 Message

Citer : Posté le 23/12/2014 16:02 | #


Drakalex007 a écrit :
D'ailleurs je profite de ce topic pour parler d'un deuxième problème au lieu d'en recréer un, j'ai 2 sprites alpha de 10*16, quand je les affiche avec ML_bmp_or(sprite,x,y,10,16);, il se passe ceci, tout marche parfaitement:
http://www.noelshack.com/2014-52-1419341433-1.png

Maintenant, quand je mets un carré noir et que je les déclare en ML_bmp_and(sprite,x,y,10,16);, il se passe ceci :
http://www.noelshack.com/2014-52-1419341433-2.png
Le premier a une bande blanche qui n'a rien a faire la tandis que le deuxième est normal, vous savez à quoi c'est dû ?

Les sprites en hexa:


le premier :
{0xC1, 0xC0, 0xC1, 0xC0, 0xC1, 0xC0, 0x00, 0x40, 0x80, 0xC0, 0x00, 0x40, 0x00, 0x40, 0x00, 0x00, 0x80, 0x40, 0x80, 0x40, 0x00, 0xC0, 0x80, 0x40, 0xC0, 0x40, 0xC2, 0xC0, 0x87, 0xC0, 0x8F, 0xC0};
le deuxième:
{0xF7, 0x7F, 0xC0, 0x7F, 0x80, 0x7F, 0x00, 0x7F, 0x00, 0xFF, 0x00, 0x7F, 0x00, 0x7F, 0x00, 0x3F, 0x80, 0x7F, 0x80, 0x7F, 0x40, 0xFF, 0xA0, 0x7F, 0xC0, 0x7F, 0xC2, 0xFF, 0x87, 0xFF, 0x8F, 0xFF};
  


C'est un bug de MonochromeLib que j'avais déjà signalé à PLL, mais il n'a pas encore corrigé le problème
Finir est souvent bien plus difficile que commencer. — Jack Beauregard

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 56 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd