Ce programme est sous licence Creative Commons 2.0 BY-NC
Description en français :
Cette librairie python permet de gérer des sprites en python grâce à la librairie casioplot.
Elle définit 2 fonctions: draw, qui dessine un sprite à une position donnée, et meta_draw qui dessine des sprites en suivant une disposition donnée par un autre sprite (un sprite de sprite).
Elle définit également des sprites de base que vous pouvez utiliser (cercle, carré, coeur...)
English description:
This python module allows you to generate sprites using the casioplot module.
It defines 2 functions: draw, that draws a sprite in a given position, and meta_draw, that draws sprites following a disposition given by a sprite.
It also defines some basic sprites that you can use (circle, square, heart...)
Il y a une chance sur deux que ce soit un problème du site donc ne t'en fais pas. ^^"
Ton format de stockage n'est pas très compact mais le meta_draw() est assez marrant. Ça donne des idées sur plein de mécanismes de combinaisons d'images ! D'ailleurs il y a des méthodes de génération de bruit qui font ce genre de choses.
Alors désolé du temps de réponse
Pour le format de stockage, j'ai fait au plus simple, j'avais aussi pensé à du RLE mais le problème est que c'est plus long à décoder, surtout avec des figures complexes...
une chaîne de caractères aurait pu être plus lisible mais encore une fois plus longue à afficher... déjà que les graphiques sont longs...
Si tu as des idées, je suis preneur, parce que niveau algorithmique je ne suis pas très doué...
Le
meta_draw()
m'à paru intéressant pour faire un zoom d'image ou bien pour des images pixelisées... j'ai réfléchi à une fonction
metafy()
qui au lieu de dessiner le meta-sprite, en retournerai l'encodage, mais ça m'à paru long pour peu d'intérêt en plus (il y aurait eu possibilité de faire des encodage d'images, et de les décoder en trouvant la clef symétrique mais bon, je fait pas un module de crypto )
Le principal problème de ton système c'est qu'il prend beaucoup de place en mémoire. Énumérer les pixels ce n'est pas stupide pour éviter de stocker les trous (quoique RLE est aussi efficace), mais sur la calculatrice ça se joue aux détails. Chaque entier prend dans les eaux de 24 à 28 octets à stocker. Et là, tu mets encore des tuples autour, donc le tas prend assez cher.
Je ne connais pas les chiffres exacts mais l'ordre d'idée pour un tuple ou une liste (ça dépend de l'interpréteur) c'est 8 octets plus les contenus. Donc pour ton carré vide de 10x10, tu as 38 pixels qui prennent chacun 8+48 octets, pour un total de 2128 octets.
Alors que si tu utilises les bits des entiers (30~31 bits par entier avant qu'ils ne grandissent en taille), tu peux stocker tes 100 bits en 4 entiers, dans une liste qui fera 104 octets en tout. C'est 20 fois moins.
Et encore, c'est sans compter sur le fait que comme la taille des entiers est affine en le nombre de bits, si on met des gros entiers on amortit les 24 octets initiaux...
Je pourrais aller loin comme ça donc je m'arrête là peut-être ^^"
Si je peux me permettre une parenthèse, c'est vraiment marrant de voir que selon le langage les considérations ne sont pas du tout les mêmes. En Basic, il faut utiliser aux maximum les fonctions natives qui affichent beaucoup de pixels d'un coup sinon le rafraîchissement constant de l'écran ralentit tout. En C, comme la RAM est plus lente que la capacité du proco à décoder, on peut se permettre pas mal de choses niveau CPU sans compromettre la vitesse de rendu. Et là, on est principalement limité par le format de stockage et le tas. À chaque fois c'est des problèmes différents !
Effectivement je ne m'attendais pas à ce que cela prenne autant de RAM !!!
J'attends donc avec impatience que Casio décide de stocker les programmes BASIC ailleurs que dans la RAM ! Surtout depuis que les 35+ ont la mémoire add-in accessible !
c'est vrai que la logique diffère beaucoup d'un langage à l'autre !
J'ai beaucoup fait d'APL, un langage qui travaille quasiment uniquement sur les tableaux et qui n'utilise jamais de boucles (ça ressemble à ce qu'on peut faire avec bumpy sur python), et encore une fois la logique change beaucoup
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