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.
Menu
Calculatrices
Graph 35 à 100
Graph 25+Pro/25+E/25+E II
Graph 35+USB/75(+E)/85/95 SD
Graph 100(+)
Classpad 300/330(+)
fx-CG 10/20 (Prizm)
Classpad 400(+E)
Graph 90+E
fx-92+ SC
Liens
¤ Transférer un programme sur
sa calculatrice

¤ Vous cherchez une fonction ?
Utilitaires >> Graph 35 à 100 >> Graphisme >> Sprites python
Sprites python
Version : 1.0 Taille : 1432 octets Ajouté le : 2020-09-06 17:19 Modifié le : 2020-09-06 17:29
Auteur et posteur :
OskarHors ligneMembrePoints: 151 Défis: 0 Message
Aucune image disponible
Nombre de visites sur cette page : 1630
Score au progrank : 15
Pas encore de note !
Vous devez être connecté(e) pour noter (inscription).
250 téléchargements | Soumettre un test

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...)


Commentaires :

Pages: 1, 2 | Suivante

LephenixnoirHors ligneAdministrateurPoints: 24575 Défis: 170 Message
Posté le 06-09-2020 à 17:25 | #
Ton fichier joint est arrivé sur le serveur mais vide, c'est pour ça qu'il n'est pas listé en téléchargement.
OskarHors ligneMembrePoints: 151 Défis: 0 Message
Posté le 06-09-2020 à 17:25 | #
ah zut ;(
OskarHors ligneMembrePoints: 151 Défis: 0 Message
Posté le 06-09-2020 à 17:26 | #
Le serveur ne supporte pas le .py ?
Ou bien est-ce qu'il suffit de recommencer à charger le programme ?
OskarHors ligneMembrePoints: 151 Défis: 0 Message
Posté le 06-09-2020 à 17:28 | #
Ah, et aussi, je n'arrive pas à changer l'emplacement : ce n'est pas vraiment un jeu d'action
LephenixnoirHors ligneAdministrateurPoints: 24575 Défis: 170 Message
Posté le 06-09-2020 à 17:29 | #
Cette fois-ci il est passé, va savoir pourquoi. :x

Je l'ai mis dans une catégorie a priori plus appropriée
OskarHors ligneMembrePoints: 151 Défis: 0 Message
Posté le 06-09-2020 à 17:34 | #
merci beaucoup Lephenixnoir !!!
C'est le premier programme que je publie, je ne connais pas encore très bien la plateforme !!
LephenixnoirHors ligneAdministrateurPoints: 24575 Défis: 170 Message
Posté le 06-09-2020 à 17:37 | #
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.
OskarHors ligneMembrePoints: 151 Défis: 0 Message
Posté le 06-09-2020 à 19:43 | #
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 )
LephenixnoirHors ligneAdministrateurPoints: 24575 Défis: 170 Message
Posté le 06-09-2020 à 20:18 | #
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 !
OskarHors ligneMembrePoints: 151 Défis: 0 Message
Posté le 06-09-2020 à 22:31 | #
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

Pages: 1, 2 | Suivante

Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 205 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