Posté le 27/11/2019 15:12
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 115 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 05/02/2022 20:59 | #
Ok merci !
Ajouté le 06/02/2022 à 18:47 :
Il y a une limite de taille pour un Addin, pour Graph 90 ?
Car je veux mettre beaucoup d'image
Albert Einstein
Citer : Posté le 06/02/2022 18:49 | #
2 Mo pour la taille de l'add-in en lui-même (le g3a). Et après tu as limite de taille du tas (environ 550 ko) pour les images créées dynamiquement.
Pense à utiliser des profils compacts (p4 ou p8) pour gagner de la place.
Citer : Posté le 06/02/2022 18:53 | #
Ok, c'est quoi vraiment les différences entre les profils r5g6b5a, p8 ou p4 ?
Albert Einstein
Citer : Posté le 06/02/2022 19:08 | #
En rgb565a chaque pixel est stocké sur 16 bits (2 octets), dont 5 bits de rouge, 6 bits de vert et 5 bits de bleu. Une des 2¹⁶ valeurs est réservée pour la transparence.
En p8 il y a une palette de 256 couleurs possibles, et chaque pixel est stocké sur 8 bits (1 octet), indiquant la position dans la palette où se trouve la couleur du pixel.
En p4 c'est pareil mais il n'y a que 16 couleurs possible et chaque pixel est stocké sur 4 bits (1/2 octet).
Si ton image a moins de 16 couleurs, utilise p4. Sinon, utilise p8. Il n'y a que très rarement besoin de rgb565 ou rgb565a.
Edit : p8 est bien sûr quasiment 2 fois plus compact que rgb565a et p4 est 4 fois plus compact que rgb565a.
Citer : Posté le 06/02/2022 19:27 | #
ok je vais mettre en p8 alors merci pour les explications.
Sinon je cherche à faire un fwrite(array, size, sizeof * array, fp); mais en python.
En gros j'ai une liste d'entier en python que j'aimerai convertir en fichier "test.txt" que je transfère dans la casio et qui pourra être lû avec :
{
FILE* fp = fopen((const char*)path, "r");
fread(array, size, sizeof * array, fp);
fclose(fp);
}
problème c'est que j'arrive pas à trouver sur internet le moyen d'encoder avec python
Albert Einstein
Citer : Posté le 06/02/2022 19:37 | #
Réponse en deux secondes, je vais manger:
l = [1, 2, 3]
with open("test.txt", "wb") as fp:
fp.write(b''.join(struct.pack('>i', n) for n in l)
Citer : Posté le 06/02/2022 19:40 | #
ha ok ! merci ! J'avais vu avec le module array mais ça fonctionnait pas.
Bon app
Ajouté le 08/02/2022 à 00:26 :
j'aimerai agrandir une zone de l'écran comme si c'était un zoom mais ce zoom doit être fait avant l'update de l'écran mais j'ai un soucis.
Voici mon code :
dclear(C_WHITE);
//affichage de ce que je veux zoomer qui se situe en haut à gauche
....
///
//Calcule du zoom (en gros je récupère le pixel et je lui redonne de nouvelle coordonnées):
for (int x = (gameManager->ScreenSize->x / 3)-1; x >=0 ; x--)
{
for (int y = (gameManager->ScreenSize->y / 3)-1; y >=0; y--)
{
int index = 396 * y + x;
drect(x*3, y*3, (x * 3)+3, (y * 3)+3, gint_vram[index]);
}
}
dupdate();
Problème ça fait pas ce que je veux, certaines images sont bien zoomer mais d'autre non.
Je suppose que ça doit avoir un rapport avec les Profiles des images
Albert Einstein
Citer : Posté le 08/02/2022 08:44 | #
Ce n'est pas un problème de profil (la VRAM est toujours en 16-bit), c'est parce que tu écrases le dessin au fur et à mesure. Ton drect() il modifie des pixels que tu n'as pas encore agrandis.
Pour faire ça simplement il faut mieux utiliser 2 VRAM différentes, regarde avec dgetvram() et dsetvram() ; tu en as 2 de base, tu n'as qu'à dessiner dans une, ensuite les échanger, et faire ta copie entre les deux ensuite.
Note : ce sera lent comme ça, mais c'est inévitable. Mets la boucle y à l'extérieur et la boucle x à l'intérieur pour faciliter le travail du cache. Idéalement il faudrait que tu fasses dessiner à gint direct en trois fois plus petit, mais ce n'est pas possible actuellement (c'est une des faiblesses de l'API de dessin).
Citer : Posté le 08/02/2022 23:14 | #
Autant pour moi, ma fonction était correct c'est juste que je l'avais mal placé et ça faisait n'importe quoi
c'est parce que tu écrases le dessin au fur et à mesure
Non justement j'avais prévu le coup en faisait la boucle commençant par la fin, ce qui fait qu'il n'y a aucun chevauchement.
Sinon j'ai un autre problème, je voudrait faire la même chose qu'un peu plus haut mais avec quelques modifications.
J'aimerai faire un truc de ce style là mais je doute que ça marche :
Python :
import struct
class TestC:
def __init__(self):
self.entier = 0
self.chaine = ""
self.BOOL = True
self.Array = []#liste d'entier
Lst = [TestC(),TestC(),TestC()]
with open("test.txt", "wb") as fp:
fp.write(b''.join(struct.pack('>i', n) for n in Lst))
C++ :
class TestC
{
public:
int entier;
unsigned char* chaine;
bool BOOL;
int* Array;
};
void load_Lst_TestC(unsigned char* path, TestC** array, int size)
{
FILE* fp = fopen((const char*)path, "r");
fread(array, size, sizeof * array, fp);
fclose(fp);
}
En gros j'aimerai stocker un Groupe de données, dont les types sont différents. Je veux pas forcément que ça soit un fichier binaire, ça peut être du Json, mais je veux pouvoir encoder depuis python pour ensuite le récupérer sur la casio.
Albert Einstein
Citer : Posté le 09/02/2022 05:07 | #
encore que Redcmd a beaucoup étudié le trucs et trouvé des bonnes pistes d'amélioration
As Lephenixnoir said
It is possible to change the contrast (of the whole screen only), but currently we do not have a way to find the initial value
You can change contrast releatively by using GetKey() with SHIFT and UP/DOWN keys and the PutKey() syscall
There was a way to set the contrast to absolute values, tho IDK how in newer calculators
Creating grayscale is rather simple
The display runs at 64Hz so simply refreshing the screen every 1/64 of a second will give the illusion of 'gray'
Problem is that the pixels are both very slow and not slow enough
The 'ghosting' effect of the pixels doesn't last long enough at lighter shades and lasts too long at dark shades
Which means theres only 3 'good' shades of gray, with only one being excellent (plus white and black adding up to 5 shades)
Most shades flickier alot or are just black
All you need is a precise clock to trigger the screen refreshes. TMU works perfectly for this. (SetTimer() only runs in multiples of 25ms (1/50sec), not the 16.66ms(1/64sec) we need)
The screen update function needs to run as soon as possible at the start of the cycle; as the more code that runs between the timer and the screen refresh increases the chance of a interrupt firing and randomly adding massive amounts of delay causing the screen to flickier randomly and dramatically.
Because we cannot easily use interrupts outselves, the game must run in the same loop and at a multiple of 64 times per sec
Or you can just use Gints grayscale/interrupts
Overclocking does reduce the flickering a bit, simply because it decreases the time between the timer and screen refresh
But it does not change the display update speed. I was hoping this was possible, but it seems its not
It does change the TMU's timings, so that must be taken into account
Citer : Posté le 09/02/2022 08:58 | #
My bad, j'arrêtais pas de lire la valeur initiale de x/y comme la position du sous-écran alors que le sous-écran est bien à 0,0.
Thank you very much for the summary Redcmd, I shall look forward to implementing that in gint, as the current method wastes a lot of CPU power.
Citer : Posté le 06/04/2022 09:42 | #
J'ai une question, est-ce qu'il y a moyen de charger une liste mais dont on ne sait pas sa taille ?
dans le style :
void load_Array(unsigned char* path, int* array,)
{
FILE* fp = fopen((const char*)path, "r");
fread(array, sizeof * array, fp);
fclose(fp);
}
Albert Einstein
Citer : Posté le 06/04/2022 09:46 | #
Non. En C, un tableau n'a une taille qu'à la compilation au mieux. Quand tu mets int *array en paramètre ton programme ne contient véritablement qu'un pointeur vers une zone mémoire où charger les int, et aucune information de taille.
Si tu veux faire ça, il faut sauvegarder la taille dans le fichier et ensuite la relire (ou la deviner à la taille du fichier mais ça ne marchera plus dès que tu mettras autre chose dedans).
{
FILE *fp = fopen((const char*)path, "r");
int size;
fread(&size, sizeof size, 1, fp);
// Attention à l'endianness
fread(array, sizeof *array, size, fp);
fclose(fp);
}
Bien sûr à la sauvegarde il faut avoir la taille à dispo et l'écrire aussi.
Citer : Posté le 06/04/2022 09:57 | #
Mais du coup si je veux utiliser ce script pour encoder la liste :
import struct
l = [1, 2, 3]
with open("test.txt", "wb") as fp:
fp.write(b''.join(struct.pack('>i', n) for n in l)
Il faut que je fasse une modification pour utiliser ta fonction ?
Albert Einstein
Citer : Posté le 06/04/2022 10:27 | #
Oui il faut commencer par écrire la longueur :
l = [1, 2, 3]
with open("text.txt", "wb") as fp:
fp.write(struct.pack('>i', len(l))
fp.write(b''.join(struct.pack('>i', n) for n in l)
Au passage .txt c'est pas un choix idéal pour un fichier binaire.
Citer : Posté le 06/04/2022 10:32 | #
Ok, c'est cool de pouvoir faire ça.
Je supposes que c'est .bin le mieux
Albert Einstein
Citer : Posté le 06/04/2022 10:35 | #
Non. En C, un tableau n'a une taille qu'à la compilation au mieux.
Mmm. Et malloc() ?
Citer : Posté le 06/04/2022 23:11 | #
Encore pire.
Je sais pas si ça va clarifier, mais bon. Ceci est un tableau de longueur 8 :
Ce tableau contient 8 entiers, et sa représentation en mémoire c'est la représentation de ces 8 entiers les uns à la suite des autres. Chaque entier occupe 4 octets, le tableau occupe donc 32 octets. La valeur 8 n'est inscrite nulle part en mémoire, et à l'exécution le tableau est mélangé avec d'autres données (de la pile, du tas, etc) donc il est impossible de savoir où il commence et il s'arrête juste en observant la mémoire à l'exécution. Tu peux juste savoir où il commence si tu as accès à la variable, puisque c'est comme ça que les variables marchent.
La taille du tableau n'existe que pendant la compilation, après quoi tout est aplati/mélangé. Ainsi, quand tu écris :
int nb_elements = sizeof(array) / sizeof(array[0]); // = 8
Ça marche parce que le compilateur remplace tout le calcul par int nb_elements = 8, et rien ne se passe à l'exécution. Le 8 est déjà fixé dès la fin de la compilation ; le programme ne calcule rien.
Si tu avais un tableau de taille inconnue, cette technique ne marcherait pas puisque le compilateur ne connaît pas la taille :
{
int nb_elements = sizeof(array) / sizeof(array[0]); // erreur!
// ...
}
C'est pour ça que tu es obligé de passer la taille en paramètre aussi :
{
// ...
}
Avoir un int *array c'est pareil que un int array[], compte tenu de la façon dont les variables marchent ça te dit juste où le tableau commence ; ton programme sait comment lire les valeurs (elles sont toutes les unes à la suite des autres après la première), mais pour connaître la taille il faut la garder toi-même.
malloc() c'est exactement comme si tu as un int *array. Mais là c'est encore pire puisque de toute façon la taille ne peut pas être connue à la compilation (elle est calculée dans le paramètre de malloc()) donc tu peux même pas espérer que le compilateur t'aide avec le trick du sizeof. Tu dois la traquer toi-même :
int sum_up_to_n_squared(int n)
{
int nb_elements = n * n;
int *array = malloc(nb_elements * sizeof *array);
for(int i = 0; i < nb_elements; i++)
array[i] = i+1;
int total = sum_of_array(array, nb_elements);
free(array);
return total;
}
Citer : Posté le 06/04/2022 23:26 | #
Cela dit en passant c’est a cause de ce genre de limitations qu’ont été développés les containers de la STL pour le C++, et notamment le std::array (bon ok en fait le gros problème c’est surtout le risque lecture/écriture au delà des bornes du tableau, mais c’est intimement lié)
Farhi, je peux te conseiller de tester la libustl si tu as le courage, ça devrait te simplifier la vie.
Citer : Posté le 06/04/2022 23:27 | #
std::vector aurait été une bonne réponse, std::array non parce que tu fixes juste la taille à la compilation
Citer : Posté le 06/04/2022 23:33 | #
Exact, mais std::array t’empêche a coup sur d’écrire au delà de la limite du tableau.
Je sais pas si tous les compilateurs C sont capables de voir a la compilation ce genre de problème avec int tableau standard