Posté le 23/12/2014 13:06
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 217 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
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
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
merci a tout le monde pour son soutien
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 !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é !
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
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
merci a tout le monde pour son soutien
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 !Citer : Posté le 23/12/2014 13:33 | #
Ok merci je m'y pencherais !
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é
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
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
merci a tout le monde pour son soutien
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 !Citer : Posté le 23/12/2014 14:08 | #
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
! 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 ?
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.
Citer : Posté le 23/12/2014 14:17 | #
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...
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
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};
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é
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
merci a tout le monde pour son soutien
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 !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
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 !
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)
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
merci a tout le monde pour son soutien
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 !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 !
Citer : Posté le 23/12/2014 16:02 | #
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