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+USB/75(+E)/85/95 SD >> Graphisme >> Libscreenshot
Libscreenshot
Version : 0.0.1 Taille : 0 octets Ajouté le : 2010-02-12 15:33 Modifié le : 2010-02-13 18:51
Auteur et posteur :
TratakHors ligneMembrePoints: 131 Défis: 0 Message
Aucune image disponible
Nombre de visites sur cette page : 5596
Score au progrank : 20
Pas encore de note !
Vous devez être connecté(e) pour noter (inscription).
583 téléchargements | Soumettre un test


Description :

Cela n'est pas un addin complet, mais une librairie pour les codeurs C, à inclure dans vos addin utilisant les niveaux de gris de Revolution-FX.

La fonction ls_screenshot() vous permettra de convertir deux buffers (clair et foncé) en une image BMP 4 bits (seulement 4 couleurs seront utilisées).

C'est encore très basique et de nombreuses améliorations peuvent être apportées (en vrac meilleur gestion des fichiers BMP, plus de niveau de gris, etc.), mais cela fonctionne. Je l'ai développée pour mon projet Sorcery-G, avec en tête la possibilité de la réutiliser pour tout le monde.

Utilisation :

***

#include "libScreenshot.h"

BMP_params bmpParams;

bmpParams.lum0 = 0xFF;
bmpParams.lum1 = 0xE6;
bmpParams.lum2 = 0x33;
bmpParams.lum3 = 0x00;

ls_screenshot(bufClair, bufFonce, &bmpParams);

***

lum0, lum1, lum2 et lum3 sont les valeurs de gris à utiliser pour la conversion (de 0 à 255). Les valeurs indiquées ne sont que des exemples. Testez.

Bon codage !

PS : Merci pour le déplacement


Commentaires :

Pages: Précédente | 1, 2

TratakHors ligneMembrePoints: 131 Défis: 0 Message
Posté le 15-02-2010 à 03:49 | #
Pour l'alignement oui j'en ai discuter avec un pote il y a deux jours qui m'a dit la même chose. Comme j'ai rarement eu à me frotter à l'écriture de fichier en mode binaire, je n'ai pas pensé à ça.

Pour la gestions des fichiers j'ai pensé ajouter à BMP_params quelques membres, pour préciser si on veut sauvegarder sur SD ou en Strorage, un chemin (qui devra être créé s'il n'existe pas) et enfin un nom de fichier avec wildcards (ex : SCR*****.BMP), remplacé au moment de la sauvegarde par un numero zero-filled (SCR00012.BMP), déterminé par la lecture du nom du dernier fichier sauvé. Avec des valeurs par défaut pour les feignasses.

Vu que l'écriture est plutot lente (meme pour 4000 malheureux octets), une barre de progression ne serait pas de trop non plus (mais comme on peut pas toucher aux buffers pendant la conversion, il faut une mini gestion de l'affichage propre à la lib et ca va devenir lourdingue).

Pas une mince affaire

Mais ça devra attendre un peu (à moins qu'un généreux contributeur ne s'y colle) vu que je suis plongé en pleine organisation de données de jeu, et ca commence un poil à devenir complexe (c'est normal que je voie des listes chainées pendant mon sommeil ?)

Merci beaucoup pour vos remarques constructives.

a+ dans l'bus !
PierrotllHors ligneAncien administrateurPoints: 5488 Défis: 41 Message
Posté le 15-02-2010 à 21:09 | #
L'alignement de données ... pourquoi j'ai pas pensé à ça?

Pour ta jauge, il suffit de sauvegarder les buffers ailleurs le temps de la création du bmp (si la mémoire est suffisante).

Rêvé de listes chainées
J'ai déjà rêvé de prog, mais pas à ce point là
Mais des fois il m'arrive de me réveiller en sursaut avec la solution à un problème de la veille
TratakHors ligneMembrePoints: 131 Défis: 0 Message
Posté le 15-02-2010 à 22:12 | #
Ben justement je voudrais que cette lib ai l'emprunte memoire la plus légère possible, puisque réutilisable dans n'importe quel programme. Si je convertit à la volée c'est pour éviter d'avoir à les sauver ces buffers (bon, qui à eux deux prenent quand meme deux fois moins de place que l'equivalent BMP 4bpp, mais on peut théoriquement sauver 4 buffers, donc autant pas prendre de risques).

Mais considerant que si un programmeur utilise cette lib c'est qu'il utilise graylink, on peut supposer que DD/VRAM sont libres et utilisables pour ça (a moins qu'un truc m'ai échappé). Et laisser une option pour desactiver cette barre si ca convient pas.

Je cauchemarde pas encore ça va. Mais comme je me suis dit qu'un jour il faudra bien que mon jeu comporte plus d'un niveau, je me suis lancé tête baissée (comme d'hab) dans la réorgansation des données et me suis retrouvé avec un gros tas de spagetti de structs sauce pointeurs bolognaise (en rajoutant au passage une layer d'affichage décors et une simili gestion de monstres, ainsi qu'une notion de chapitres pour le découpage du jeu). Comme quoi, malgré tout les progrès de l'humanité, on est pas encore arrivé a bout de la puissance ultime du papier et du crayon
KristabaHors ligneMembrePoints: 614 Défis: 22 Message
Posté le 15-02-2010 à 22:34 | #
+1, rien ne vaut un bon vieux brouillon avec un cerveau en bon état qui marche derrière

C'est ça le problème quand on fait du C (surtout après avoir fait de la POO ) : on a tendance à faire des structures de partout

Sinon, pour la DD/VRAM, en réalité la VRAM est à priori non utilisée (quoi qu'il faudrait vérifier, je connais pas super bien le fonctionnement de revolution-fx ) mais le DD, c'est l'écran, donc il est probablement utilisé

Ce que tu peux faire c'est justemment de stopper le gray et d'écrire sur le DD ta barre de progression (t'écris directement sur l'écran en gros) : le fond ne serait plus en niveaux de gris mais t'aurais ta barre
TratakHors ligneMembrePoints: 131 Défis: 0 Message
Posté le 15-02-2010 à 22:51 | #
Je peux pas stopper le gray je suis même pas sencé savoir qu'il y en a un en réalité. La fonction accepte deux buffers mais n'a aucune idée du contexte dans lequel ils sont utilisés ni dans quel état est l'affichage. Mais si j'ecris directement dans DD ca ne touche pas aux buffers normalement (heu ça reste à prouver ça en fait). Reste a savoir comment vont se comporter les Bdisp pendant le gray.

Je sais pas comment ca se passe ici, mais sur HP48 il y avait moyen de déplacer l'affichage vers n'importe quelle zone mémoire, du moment que le premier octet de la zone etait à une adresse paire (ce qui était la clé du niveau de gris et du double buffering d'ailleurs).

Bon, tant pis pour la barre pour le moment, de toutes façons, quand il n'y aura plus que ça à faire

Les structs c'est bon mangez-en par paquets de 10

Pages: Précédente | 1, 2

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