Nombre de visites sur cette page : 21064 Score au progrank : 51 Note actuelle : 9.5/10 noté 3 fois Vous devez être connecté(e) pour noter (inscription).
Picture compressor est un petit utilitaire qui j'espère vous sera utile
Voici la marche à suivre :
1) Enregistrer une picture
2) Aller dans la mémoire principale, sélectionner une seule picture et l'exporter dans la racine de la mémoire de stockage (vous pouvez répéter l'opération autant de fois que souhaité)
3) Exécutez l'addin PICTURE, et sélectionnez le fichier contenant la picture à réduire
4) Choisissez la taille désirée
5) Ca y est, l'opération est terminée, vous n'avez plus qu'à vous rentre dans la mémoire de stockage et retranférer votre fichier dans la mémoire principale
Ce programme est garanti sans aucun danger pour votre calculatrice. J'espère que vous saurez tirer profit de ces nouvelles possibilités, pour réaliser des jeux toujours plus performants 8)
Voici un petit jeu qui utilise ce programme pour faire un joli scrolling : Yétisport ic
Remerciements à Dafp pour ses recherches et ses explications.
Et à Pierrotll pour tout le code que j'ai récupéré.
18/03/12 : possibilité de compresser des pictures en moins de 1024 octets
19/03/12 : plus de problème avec en ligne en haut de l'écran quand la picture fait moins de 1024 octets
Mais si la picture ne fait que 1024+20 de header, des données hors de la picture doivent être lues quand tu changes l'adresse de lecture pour changer la position du perso, non ?
Apparemment non puisqu'il n'y a pas de parasites entre les pictures.
@ Cartix : Si c'est de la compatibilité avec la graph 100 dont tu parles il n'y a pas de problème, puisqu'elles ont plus de mémoire. Il suffit de réenregistrer les pictures.
Après quelques tests, la meilleure méthode est bien d'utiliser le background pour afficher les pictures réduite.
Pour y superposer une autre image, utilisez alors une picture non réduite.
Je vais voir pour compresser les pictures encore plus, comme la fait Daft, mais l'utilisation sera alors beacoup plus complexe !
@Pierrotll: En fait, vu qu'il y a pleins de pictures avant qui font 2 lignes, ça permet de décaller et donc de faire descendre le personnage.
Donc si je lis (avec rclpict) la 1er picture, elle est suivit de la 2eme, ... jusqu'à que ça fasse 2048 octets. Encore une fois, pas besoin de picture pour remplir les 2048 octets à lire. Donc si on veut être sûr de ne pas avoir de parasites, et faire comme j'ai fais pour Wario: soit 2 pictures de 1024, soit 1 de 2048 (mais ça revient au même).
Rclpict lit 2048 octets, tandis que background lit 1024.
Donc plus la calculatrice lit de picture vide qui dessine 2 lignes, plus ça decalle wario. Donc les pictures représente plus une position qu'une image. On joue sur ça, et ça permet de fairebouger son personnage à volonté.
Je voudrai déplacer Wario à l'horizontal, mais je n'y arrive pas, il faudrait faire des pictures de 1 ou 2 octets (8-16pxl de decallage) mais j'ai une erreur: Full memory ... étonnant. Je ne sais pas d'où ça vient, à voir ...
Non du tout. J'ai fais le test, même en mettant la pict 32, ça marche. Elle n'est pas affiché dans lem enu (donc pas d'adresse) mais elle est lu si on met une picture de 10 octet par exemple.
Non il considère bien que la picture fasse x octets, c'est juste que RclPict lit forcement 2048 octets. Donc pas de problème d'alignement d'élément, ni de depassement de mémoire, c'est simplement la fonction qui est comme ça sur les nouveaux modèles - je ne parle pas pour la prizm.
On pourra sans doute bientôt comme l'a expliqué Dafp.
On enregistre 1024 pictures d'un pixel puis la picture à déplacer.
Suivant la picture qu'on affiche avec RclPict, l'emplacement est différent.
Oui et non Purobaz, car une picture est lu de ligne en ligne, de haut en bas. Et il n'y a pas indiqué la dimension de l'image, mais sa taille. Nuance.
Donc la seul bonne solution pour avoir des personnages qu'on voudrait déplacer, serait de mettre le dessin en haut à gauche, et de bien penser quel picture il faut pour faire des sauts de lignes.
Encore une fois, l'emplacement est différent car une picture est lu à la filé. Cad que si la picture commence À l'adresse 0x800, et quel se finit À 0x710, rclpict continuera jusqu'à 0x00. donc si mon personnage se trouve à l'adresse 0x710, il y aura un decalage de 144*8=480 pxl, cad un decallage de 3 lignes vers le bas, et 96 pxl vers la droite.
Mais si je lis directement à 0x710, pas de decallage (voyez les adresses choisis peu inteligente), mais si je comence à 0x800, ou 0x900, etc,..
Mais pour avoir ce decallage, il faut forcement le représenter par une picture.
Un tel système révolutionnera les graphismes sur Casio !
Je dois avouer que pour l'instant, j'ai du mal à tout comprendre au système... J'ai pourtant essayé en Background mais rien ne s'affiche...
Au fait, vous devriez joindre des exemples autres que warrio à ce topic, des pictures qui font vraiment 1024 octets, afin de mieux comprendre. En effet, vous présentez un système mais votre exemple présente des images plus "compétitives" !
Et pourquoi ne pas faire un exemple "simple", sans rien qui bouge, pour les lents comme moi ?
Au fait, une fenêtre s'ouvre-t-elle pour une adaptation sur PRIZM ?
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
A cause du changement de processeur des nouvelles Graph 35+ USB, 75 et 95 SD, de nombreux addins sont incompatibles avec ces calculatrices.
