Posté le 28/02/2013 22:56
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 246 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 28/02/2013 23:03 | #
c'est une bonne question
selon moi, tu mettre jusqu'a saturation de la mémoire principale, c'est à dire 1,5Mo.
Par contre, ça en fait des sprites ! =>
MS2 ne fait que 42Ko mais possède quand même une bonne trentaine de sprites 128*64, plus quelques backgrounds... T'inquiète, t'a de la place.
Par contre, pense à rajouter "const" devant tes "unsigned char sprite[] = ...", ça réduit un peu la place de tes images
Si t'en a beaucoup, tu peut te faire un script javascript pour le faire à ta place (et si t'es sage je te le met demain à 10h)
Citer : Posté le 28/02/2013 23:15 | #
je demande par exemple ca :
unsigned char face[3*151][32*4] ,
et ce n'est qu'une partie... et ca plante deja sur l'emulateur
j'ai fait deux trois petits autres test, et j'ai l'impression que la limite est de [253][32*4]
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 28/02/2013 23:22 | #
Qu'est ce que tu veux dessiner avec un truc pareil !
Aussi, pourquoi a-tu 32*4 sprites différents ? J'avoue que tu m'étonne là
Petit calcul: 3*151*32*4 = 57984 octets
Ca fait beaucoup de pixels ça (57984*8)
Citer : Posté le 28/02/2013 23:30 | #
bon le 151 je te laisse trouver tout seul, le 32*4 c'est que j'avais la flemme de calculer (sprite 32*32), et le *3 c'est pour des petites animations... je pense avoir une petite idée d'un truc que je pourrais faire, mais je suis pas sur que ca marcherais...
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 28/02/2013 23:44 | #
151= 200-49
c'est aussi le nom d'une marque de pastis
151 = 3*50+1
Sur WP: 151 est le vainqueur du 666
Je vois vraiment pas. Ca fait autant de sprites que de vient de trouver
POKEMONS !
Citer : Posté le 28/02/2013 23:46 | #
j'ai trouvé de magnifique sprite pokemon monochrome en 32*32, et ca fais depuis tres longtemps que je veux faire un bon pokemon pour calto, parce que celui qui est en allemend est, comment dire... pourri
donc je commence par encoder les sprites, mais bon, les problemes commencent deja
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 28/02/2013 23:49 | #
t’inquiète pas, ça ne fait que commencer
T'a essayé d'initialiser à vide ton tableau, puis de le remplir au fur et à mesure ?
Ca bugue quand même ?
Citer : Posté le 28/02/2013 23:53 | #
quand j'ai teste, je n'ai rempli qu'a peu pres qu'a
const unsigned char face[3*151][32*4] = {{0x00, 0....
120 lignes de { 32*4 unsigned char}
}};
do
{
ML_bmp_or(face[0],0,0,32,32);
ML_display_vram();
ML_clear_vram();
}while (1);
et ca plantait deja...
mais comme a [151][32*4] ca marche, je vais oublier les petites animations de debut de combat
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 28/02/2013 23:56 | #
oulà, t'as choisi la méthode lourde !
Je te poste demain ma manière de procéder, je la trouve bien plus lisible
(Je code sur l'ordi de mon père, j'ai pas accès à tous mes fichiers)
Citer : Posté le 28/02/2013 23:57 | #
ben il me semble que c'est la methode la plus simple et legere non? c'est pas tres lisible, mais au moins c'est leger
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 01/03/2013 00:01 | #
de toute manière, lisible ou non, c'est pareil dans la calto, donc autant proceder lisiblement
ce que je fait:
*tiles[10][32*32];
sprite = {...};
tiles[1] = sprite1;
// pour y acceder:
ML_bmp_or(tiles[1], 0, 0, 32, 32);
Je te met le code exact (avec les bons type, pointeurs etc.) demain, comme promis
Citer : Posté le 01/03/2013 00:12 | #
mais ton code sera plus lourd a la compilation non? (en terme de taille du fichier)
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 01/03/2013 10:28 | #
On peut stocker autant de mémoire que la taille de la RAM à laquelle on soustrait quelques ko d'exécution du programme. La taille de la RAM d'une 85 ou équivalent vaut un peu plus de 60ko, ce qui correspond à la taille de la mémoire principale qui, je vous le rappelle, est temporairement placée en RAM avant d'être sauvée en mémoire de stockage à l'extinction.
Selon la taille du programme, il reste donc environ 40ko disponibles.
PS : pour les sprites de pokemons t'as récupéré ceux que j'avais récupérés et postés sur ce site ?
Citer : Posté le 01/03/2013 10:35 | #
non, j'ai pris ceux ci :
de dos
et de face, mais je ne vais pas utiliser leurs animation
Ajouté le 01/03/2013 à 13:17 :
j\'ai trouvé une solution qui va peut-etre marché : je place tout les sprites dans un fichier (comme pour une sauvegarde) et quand j\'ai besoin d\'un sprite, il me suffirait de lire dans le fichier a tel endroit... je vais faire quelques tests, et je verrais bien si ca marche
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 01/03/2013 13:57 | #
Le coup des sprites dans un fichier ne résout rien, car :
1) ça revient exactement à les mettre en const dans ton code, ils sont stockés dans la ROM et pas dans la RAM
2) ça implique un surplus de mémoire pour la lecture du fichier qui est placé dans un buffer
3) ça implique une perte de temps d'exécution
Citer : Posté le 01/03/2013 14:03 | #
et zut...
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 01/03/2013 14:21 | #
Essaie le const, au pire le projet sera volumineux mais on a toujours de la place sur une calto.
Citer : Posté le 01/03/2013 16:32 | #
Bon, ben temps que je passe par là...
La G85 possède si je ne me plante pas 128Kio de RAM, dont les 64 derniers sont utilisés par le système (stocké dans la mémoire flash régulièrement comme l'a dit louloux).
Par contre, contrairement à ce que l'on pourrait croire, le programme n'est jamais chargé en RAM, il est exécuté depuis l'EEPROM (en utilisant la translation d'adresse pour ne pas subir la fragmentation du système de fichiers).
Du coup, la taille d'un exécutable G1A est limitée par le nombre de pages translatables (4*32) facteur de la taille maximum d'une page (4kio), le tout sur un SH3 7705.
Bref, je me perds dans les détails, mais tout cela veut dire qu'il est possible de lire depuis le programme lui-même exactemment comme depuis la RAM, et de mémoire les performances ne sont pas si ridicules. Cependant, un compilateur C n'est pas vraiment pensé pour ça, et il est assez difficile de lui faire comprendre que des données doivent résider et être utilisées uniquement dans l'EEPROM...
Donc 2 solutions : écrire en assembleur directement (juste la partie qui permet de récupérer les adresse des sprites), ou faire comprendre au compilateur que certaines données ne doivent pas être copiées en RAM (sûrement possible, en réfléchissant un peu et en utilisant du #pragma, mais je ne connais pas le compilo Renesas).
Bonus pour ceux qui veulent se tapper la tête contre les murs : j'avais implémenté ce genre de comportement à l'époque, pour Tiles Creator (ça me rajeunit pas tout ça :x), c'est un peu compliqué à comprendre (par ce qu'une partie, les données elles-mêmes, sont générées par le plugin), mais si ça intéresse quelqu'un... Les parties intéressantes sont dans tiles.s/map.s/tileset.s, entre les #ifndef COPY_ON_RAM : tile.s.
Ce qu'il faut comprendre, c'est qu'une fois que les données sont enregistrées dans le programme lui-même, avec une simple table d'adresse (Tile_JTable dans mon cas), il est très facile d'obtenir l'adresse d'un élément (même en C avec deux trois rustines ça se fait).
Pour finir, il y a aussi moyen de faire beaucoup plus ingénieux (mappage de fichiers en mémoire via le MMU, manuellement, avec quelques primitives de manipulation du FS de la mémoire de stockage, un équivalent basique de mmap).
Avec un tel système, les ressources peuvent être placées dans un ou plusieurs fichier indépendants de l'exécutable, tout en étant accessible aussi facilement que la RAM.
Mais bon, là c'est vraiment du boulot
PS : "const" ne changera pas grand chose au problème, si le comportement du compilo Renesas est standard sur ce point. Il y aura toujours une copie dans une section de la RAM (la section .rodata n'est que temporairement dans l'exécutable, la routine d'initialisation s'occupe en théorie de copier cette section dans son adresse prévue en RAM, à côté de .data et .bss). Et encore, si tu le défini à l'intérieur d'une fonction, ce sera de l'espace alloué sur la pile (et s'pas fait pour stocker tout ça la pile...) + la valeur d'initialisation dans .rodata
Citer : Posté le 01/03/2013 16:54 | #
Merci pour les précisions. Cependant :
Donc toujours utiliser du const, c'est votre ami pour les ressources
ça t'assure aussi que les données soient lues depuis la ROM (vu que l'OS exécute l'addin depuis la ROM) et ne soient pas copiées en RAM
Peut-être que Renesas n'est pas standard (il ne l'est pas sur pas mal de points, ce ne serait donc pas étonnant ici où la mémoire a un fonctionnement particulier).
Citer : Posté le 01/03/2013 17:09 | #
waw ! merci pour toutes ces precisions (meme si je suis pas sur d'avoir tout saisi a 100% )
bon, je vais finalement utiliser un systeme un peu plus lent, mais qui marche et qui est facile a implementé .
en tout cas merci pour cette grosse expliquation kristaba
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 !