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.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » Petit jeu fxSDK graph 90 - bug pénible
Slyvtt Hors ligne Maître du Puzzle Points: 2313 Défis: 17 Message

Petit jeu fxSDK graph 90 - bug pénible

Posté le 13/11/2021 21:14

Hello,

j'essaye de faire tourner mon proto de jeu (hors concours CPC 28), mais sur l'émulateur CG-50 il se plante de manière aléatoire sans que je comprenne pourquoi (les contrôles ne fonctionne plus).

Je ne sais pas d'où vient le bug, Car il y a pas mal de choses que je découvre avec le fxSDK.

Est-ce qu'une âme charitable pourrait regarder et m'aider à trouver le bug ?

J'ai mis les sources dans le fichier zip joint ainsi que le .g3a.

Question subsidiaire, comment debuggez-vous vos applications ? D'habitude je fais soit du GDB, soit des printf soit des output dans des fichiers, mais là je me sens un peu coincé.

Merci pour vos conseils, infos ...

Ciao

Sly

Fichier joint


Slyvtt Hors ligne Maître du Puzzle Points: 2313 Défis: 17 Message

Citer : Posté le 14/11/2021 14:38 | #


Bon,

j'ai crois savoir d'où vient le souci.
Je pense que le problème vient de la fonction de "ray-casting" qui est vraiment trop gourmande.
Je vais donc essayer de "l'alléger" un peu pour voir si ça résout le schmilblick ...

A plus

Sly

Ajouté le 15/11/2021 à 08:50 :
Après moultes galères, la source du bug a été isolée, elle provenait bien de mes routines de primitives graphiques avec gestion de la transparence.

Cette fois c'est OK, j'ai donc une base graphique qui gère le canal alpha sous la forme (R,G,B,A) avec chacune des composantes entre 0..255.
Il faudrait je pense à terme les convertir en ASM afin de booster les performances, mais globalement ça va pas trop mal.

A ce stade cela donne :



Je continue de prendre en main de SDK.
Et bien entendu, vu que le débogage de plantages est terminé, je peux passer au fond du problème : développer le jeu en lui même ...

Ciao

Sly
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir Hors ligne Administrateur Points: 24262 Défis: 170 Message

Citer : Posté le 15/11/2021 08:55 | #


Désolé de pas avoir regardé, un autre cas est encore sur le feu. Content que tu aies trouvé, au moins c'était bien de ton côté...

Question subsidiaire, comment debuggez-vous vos applications ? D'habitude je fais soit du GDB, soit des printf soit des output dans des fichiers, mais là je me sens un peu coincé.

Tu peux utiliser GDB sur l'émulateur, même si c'est expérimental je dirais : https://www.planet-casio.com/Fr/forums/topic16575-1-fx-cg50-manager-plus-gdbserver-debuggez-vos-add-ins-et-casiowin.html

Sinon personnellement je fais du dprint() quand vraiment ça va pas et sinon de l'introspection. Si tu veux tu peux aussi envoyer du texte en USB à ton ordinateur si tu testes avec une vraie calto. Sur l'émulateur il n'y a pas beaucoup mieux je crois. Le système de fichiers tu verras vite que c'est plus une plaie qu'un outil, il est notamment extrêmement lent en écriture (~1 Mo/minute), avec un petit coût en plus côté gint.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Slyvtt Hors ligne Maître du Puzzle Points: 2313 Défis: 17 Message

Citer : Posté le 15/11/2021 09:43 | #


Lephenixnoir a écrit :
Désolé de pas avoir regardé, un autre cas est encore sur le feu. Content que tu aies trouvé, au moins c'était bien de ton côté...

Se gratter la tête est toujours formateur et permet de comprendre où on a fait la bêtise pour ne plus la faire. Ici dans mon cas "simplement" une erreur classique; écriture en mémoire dans une zone non prévue (l'erreur de débutant). A vouloir attaquer la mémoire directement pour accélérer les routines graphique de transparence, un "<" qui était en fait un "<=" dans le code !!!

D'ailleurs, j'ai pas trouvé de "librairie" graphique de primitives de ce style dans gint/fxSDK, en développant quelques routines supplémentaires, ça pourrait vous intéresser pour le SDK ? A ce stade ça gère chaque canal sur un "unsigned char", mais si besoin je peux faire les versions sur des "unsigned int" fusionnés (RGB565) afin d'être dans la philosophie de gint::dpixel. Faut juste me dire. Tel que je le comprends, pour l'instant le SDK est très orienté "plateformer" et ce sont principalement les copies de "tiles" qui sont implémentées via dimage/dsubimage (qui envoient du bois d'ailleurs soit dit en passant ).

Lephenixnoir a écrit :
Tu peux utiliser GDB sur l'émulateur, même si c'est expérimental je dirais : https://www.planet-casio.com/Fr/forums/topic16575-1-fx-cg50-manager-plus-gdbserver-debuggez-vos-add-ins-et-casiowin.html

Oui j'ai vu ça ce matin, faut que je me penche dessus.

Lephenixnoir a écrit :
Sinon personnellement je fais du dprint() quand vraiment ça va pas et sinon de l'introspection. Si tu veux tu peux aussi envoyer du texte en USB à ton ordinateur si tu testes avec une vraie calto.

Pour l'instant j'ai pas le hardware, mais logiquement c'est pour bientôt . Merci SynchroDonjon (et Pavel d'avoir choisi la Graph 35 ).

D'ailleurs; dois-je m'attendre à une différence de vitesse significative entre le vrai hardware et le simulateur ? Ca tourne pas trop mal pour un puzzle game sur l'émulateur, j'espère qu'il en sera de même sur un vrai hardware, sans avoir besoin de "PTune" avant.

Lephenixnoir a écrit :
Sur l'émulateur il n'y a pas beaucoup mieux je crois. Le système de fichiers tu verras vite que c'est plus une plaie qu'un outil, il est notamment extrêmement lent en écriture (~1 Mo/minute), avec un petit coût en plus côté gint.

C'est gravé physiquement dans la pierre avec un marteau et un burin ? La vache, ça pique les yeux de lire ça de nos jours ...
Il faudra de toute manière que j'implémente des input/output pour les lectures/sauvegarde de niveaux. Mais bon ce sera très petit en taille (des simples fichiers TXT de quelques Ko au maximum).

Comme toujours, merci pour ton aide précieuse Lephe

Ciao

Sly
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir Hors ligne Administrateur Points: 24262 Défis: 170 Message

Citer : Posté le 15/11/2021 10:08 | #


D'ailleurs, j'ai pas trouvé de "librairie" graphique de primitives de ce style dans gint/fxSDK, en développant quelques routines supplémentaires, ça pourrait vous intéresser pour le SDK ? A ce stade ça gère chaque canal sur un "unsigned char", mais si besoin je peux faire les versions sur des "unsigned int" fusionnés (RGB565) afin d'être dans la philosophie de gint::dpixel. Faut juste me dire. Tel que je le comprends, pour l'instant le SDK est très orienté "plateformer" et ce sont principalement les copies de "tiles" qui sont implémentées via dimage/dsubimage (qui envoient du bois d'ailleurs soit dit en passant ).

Ça peut être très cool ! Il y a quelques considérations ici. Note qu'il y a MonochromeLib qui traîne déjà pour les formes plus compliquées ; pour la transparence on n'a rien en effet.

Le côté "platformer" n'est pas particulièrement voulu, c'est surtout que gint fournit les trucs les plus fondamentaux sous forme optimisée et puis y'a une affinité pour les platformers par ici.

Je suggère juste de faire attention à la vitesse parce que y'a vraiment moyen de taper dans du très lent. J'ai pas trop vu ton code mais bien sûr les divisions sont à bannir, multiplications à factoriser, etc. Surtout si tu traites beaucoup de couleur d'un coup (eg. un sprite semi-transparent). On est à la limite entre ce qui se fait bien et ce qui doit se faire attentivement.

D'ailleurs; dois-je m'attendre à une différence de vitesse significative entre le vrai hardware et le simulateur ? Ca tourne pas trop mal pour un puzzle game sur l'émulateur, j'espère qu'il en sera de même sur un vrai hardware, sans avoir besoin de "PTune" avant.

C'est à voir, on est généralement à la limite des 30 FPS sans overclock dans les platformers par exemple. L'attitude générale c'est "la majorité des choses on peut les faire, mais si c'est non-trivial il faut les faire attentivement". Tu auras tout le temps de voir venir cela dit, y'a une lib pour mesurer les perfs et plein d'outils d'optimisation.

Slyvtt a écrit :
C'est gravé physiquement dans la pierre avec un marteau et un burin ? La vache, ça pique les yeux de lire ça de nos jours ...
Il faudra de toute manière que j'implémente des input/output pour les lectures/sauvegarde de niveaux. Mais bon ce sera très petit en taille (des simples fichiers TXT de quelques Ko au maximum).

C'est le tradeoff - le précédent fs était fait maison, beaucoup plus rapide mais aussi tellement limité qu'on pouvait pas implémenter le standard C avec. Par exemple tous les fichiers devaient avoir une taille fixée à la création, on ne pouvait pas écrire un nombre impair d'octets (limitation de leur configuration de la ROM pour leur défense), on ne pouvait pas modifier un fichier créé (enfin on pouvait changer les 1 en 0 mais pas l'inverse), j'en passe et des meilleures. Là je crois que le fs est un fs normal (c'est du FAT, Yatis connaît tous les détails) c'est déjà ça. Perso je préfère fonctionnel à rapide, même si c'est vrai que du coup on a pris l'habitude de pas trop s'en servir.

Pour les sauvegardes, éditeurs de niveaux, etc. ça pose absolument aucun problème, juste avoir un écran avec une barre de progrès ou un truc du genre parce que c'est pas instantané.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Slyvtt Hors ligne Maître du Puzzle Points: 2313 Défis: 17 Message

Citer : Posté le 15/11/2021 10:47 | #


Lephenixnoir a écrit :
Ça peut être très cool ! Il y a quelques considérations ici. Note qu'il y a MonochromeLib qui traîne déjà pour les formes plus compliquées ; pour la transparence on n'a rien en effet.

Pour le moment mes routines sont très orientées "SDL-like" car c'est de là que je viens, mais je vais regarder ce qui existe déjà. Mon zinzin est limité à la CG-50/Graph 90+E, j'ai oublié de préciser

Lephenixnoir a écrit :
Je suggère juste de faire attention à la vitesse parce que y'a vraiment moyen de taper dans du très lent. J'ai pas trop vu ton code mais bien sûr les divisions sont à bannir, multiplications à factoriser, etc. Surtout si tu traites beaucoup de couleur d'un coup (eg. un sprite semi-transparent). On est à la limite entre ce qui se fait bien et ce qui doit se faire attentivement.

Pour le moment c'est "optimisé" level 1 je dirais : pas de division, mais en étant malin, on peut faire un "bit shift", et les multiplications sont factorisées (une par canal) :
De même quand le canal Alpha vaut 0, on skip le point (car totalement transparent) ou si canal Alpha vaut 255 alors on enclenche une routine fast pixel sans transparence. Mais globalement la transparence gérée en software reste un truc lourd en calculs.
Ca donne ça IRL (si tu vois des choses à améliorer, n'hésite surtout pas, car ne connaissant pas le proc, il y a peut être mieux à faire) :


/* draw a pixel at coordinates (X,Y) of color (R,G,B) */
/* all color values (R,G,B) to be in the range 0..255 */
void _fastPixelRGB( unsigned int X, unsigned int Y, unsigned char R, unsigned char G, unsigned char B )
{
       if ( X<DWIDTH && Y<DHEIGHT)
       {
              unsigned int color = (((R>>3) << 11) | ((G>>2) << 5 ) | (B>>3));
              gint_vram[ Y*DWIDTH + X ] = color;
       }
}

/* return the color of the pixel at coordinates (X,Y) */
/* modifies R,G,B given as parameters */
/* all returns R,G,B are in range 0..255 */
void _getPixelRGB( unsigned int X, unsigned int Y, unsigned char *R, unsigned char *G, unsigned char *B )
{
       if (X<DWIDTH && Y<DHEIGHT)
       {
            unsigned int color =  gint_vram[ Y*DWIDTH + X ];
            *R = (((color >> 11 ) & 0b11111 ) << 3);
            *G = (((color >> 5) & 0b111111) << 2);
            *B = ((color & 0b11111) << 3);
       }
}

void _calculateBlendRGBA( unsigned int X, unsigned int Y, unsigned char *R, unsigned char *G, unsigned char *B, unsigned char A )
{
        unsigned char Ro, Go, Bo;
        _getPixelRGB( X, Y, &Ro, &Go, &Bo );
        *R = Ro + (((*R-Ro)*A) >> 8);
        *G = Go + (((*G-Go)*A) >> 8);
        *B = Bo + (((*B-Bo)*A) >> 8);
}

void _pixelRGBA( unsigned int X, unsigned int Y, unsigned char R, unsigned char G, unsigned char B, unsigned char A )
{
       if (X<DWIDTH && Y<DHEIGHT)
       {
           if (A==0) return;
           else if (A==255) _fastPixelRGB( X, Y, R, G, B );
           else
           {
                  unsigned char Rf = R;
                  unsigned char Gf = G;
                  unsigned char Bf = B;
                  _calculateBlendRGBA( X, Y, &Rf, &Gf, &Bf, A );
                  _fastPixelRGB( X, Y, Rf, Gf, Bf );
           }
       }
}

On pourrait gagner un peu des cycles en splittant la fonction _getPixelRGB en 2 (une _getPixelRGB comme écrite actuellement pour appel direct par l'utilisateur et une_fastGetPixelRGB en static void pour appel depuis la fonction _calculateBlendRGBA pour faire sauter le test de X<largeur et Y<hauteur, sachant que ce test est fait dans la routine _pixelRGBA auparavant).

J'ai encore énormément à découvrir dans le SDK et les outils à disposition, mais clairement "y'a moyen de moyenner"

@+

Sly
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir Hors ligne Administrateur Points: 24262 Défis: 170 Message

Citer : Posté le 15/11/2021 10:53 | #


C'est pas mal déjà. Je soupçonne que tout est inliné de toute façon donc le test des bornes ne sera fait qu'une fois. L'approximation légère dans le >> 8 est tout à fait acceptable. Tu gagnerais sans doute à ne pas utiliser trois variables différentes pour les couleurs, une union entier/tableau semble appropriée.

Sinon ouais essaie de limiter la quantité que tu en mets à l'écran et tant que tu remplis pas toute la surface avec ça devrait le faire en termes de perfs.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Slyvtt Hors ligne Maître du Puzzle Points: 2313 Défis: 17 Message

Citer : Posté le 15/11/2021 12:34 | #


Lephenixnoir a écrit :
C'est pas mal déjà. Je soupçonne que tout est inliné de toute façon donc le test des bornes ne sera fait qu'une fois. L'approximation légère dans le >> 8 est tout à fait acceptable. Tu gagnerais sans doute à ne pas utiliser trois variables différentes pour les couleurs, une union entier/tableau semble appropriée.

Sinon ouais essaie de limiter la quantité que tu en mets à l'écran et tant que tu remplis pas toute la surface avec ça devrait le faire en termes de perfs.

Pour le moment c'est pas en inline, mais c'est prévu, on gagnera les "calls" à chaque itération.
Oui, je préfère mon approx ">>8" (soit diviser par 256) que me prendre une division par 255 . Le proc sera content ...

J'ai par contre une question métaphysique : dans gint, je comprends que la fonction dpixel gère le RGB565 comme du RGB5(0+5)5 (le bit en plus du vert n'est pas utilisé) donc toutes les composants sont sur 0..31 au lieu de R&B sur 0..31 et G sur 0..63.

Je suis parti sur l'optique de tout faire en "vrai" RGB565, mais du coup il y a un "biais" entre ma fonction pixel et dpixel de gint.
Y vois tu un problème ? As tu une préférence ou c'est complètement "open" du moment que c'est cohérant ?

Perso j'aime bien le vrai RGB565 qui rend les teintes un peu "greenish" quand on use du canal vert sur les 6bits au lieu de seulement 5bits, mais certains n'aiment pas du tout.

Sly
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir Hors ligne Administrateur Points: 24262 Défis: 170 Message

Citer : Posté le 15/11/2021 12:44 | #


Pour le moment c'est pas en inline, mais c'est prévu, on gagnera les "calls" à chaque itération.

Oh ne t'inquiète pas le compilateur il inline tout seul. Là tu vois avec -O2 déjà _getPixelRGB() et _calculateBlendRGBA() se font inliner automatiquement. _fastPixelRGB() est un peu trop gros pour qu'il le fasse sans réfléchir, mais rends-la static et pouf il dégaine (puisqu'en static après l'inlining il peut supprimer la fonction d'origine, ce qui annule l'inconvénient de dupliquer le code).

J'ai par contre une question métaphysique : dans gint, je comprends que la fonction dpixel gère le RGB565 comme du RGB5(0+5)5 (le bit en plus du vert n'est pas utilisé) donc toutes les composants sont sur 0..31 au lieu de R&B sur 0..31 et G sur 0..63.

Je suis parti sur l'optique de tout faire en "vrai" RGB565, mais du coup il y a un "biais" entre ma fonction pixel et dpixel de gint.
Y vois tu un problème ? As tu une préférence ou c'est complètement "open" du moment que c'est cohérant ?

C'est bien du RGB565 partout. Il n'y a que le macro C_RGB() qui considère le vert sur 5 bits par homogénéité. Je préfère que tu sois cohérent avec l'API, ce qui tombe bien puisque c'est bien du RGB565.

Au fait tu peux donner des noms type "d*" à tes fonctions si tu veux, du genre dpixelRGBA() ou autre. Ça ne me pose pas de problème de les considérer comme une extension des fonctions de dessin natives (et de surveiller la compatibilité dans le futur).

Perso j'aime bien le vrai RGB565 qui rend les teintes un peu "greenish" quand on use du canal vert sur les 6bits au lieu de seulement 5bits, mais certains n'aiment pas du tout.

Je suis pas sûr de ce que tu veux dire par là, mais note que l'écran de la Graph 90+E n'est pas un écran plasma avec des couleurs super fidèles (en particulier il n'est pas très saturé à mon goût) donc je suis pas sûr que les subtilités se voient. :P
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Slyvtt Hors ligne Maître du Puzzle Points: 2313 Défis: 17 Message

Citer : Posté le 15/11/2021 13:15 | #


Lephenixnoir a écrit :
Oh ne t'inquiète pas le compilateur il inline tout seul. Là tu vois avec -O2 déjà _getPixelRGB() et _calculateBlendRGBA() se font inliner automatiquement. _fastPixelRGB() est un peu trop gros pour qu'il le fasse sans réfléchir, mais rends-la static et pouf il dégaine (puisqu'en static après l'inlining il peut supprimer la fonction d'origine, ce qui annule l'inconvénient de dupliquer le code).

OK nickel

Lephenixnoir a écrit :
C'est bien du RGB565 partout. Il n'y a que le macro C_RGB() qui considère le vert sur 5 bits par homogénéité. Je préfère que tu sois cohérent avec l'API, ce qui tombe bien puisque c'est bien du RGB565. Au fait tu peux donner des noms type "d*" à tes fonctions si tu veux, du genre dpixelRGBA() ou autre. Ça ne me pose pas de problème de les considérer comme une extension des fonctions de dessin natives (et de surveiller la compatibilité dans le futur).

Ca marche, je vais en profiter pour ajouter quelques primitives et je t'enverrai le code, tu pourras si besoin le remouliner "à ta sauce" pour le verser dans le Gitea de gint à l'occasion.

Je suis pas sûr de ce que tu veux dire par là, mais note que l'écran de la Graph 90+E n'est pas un écran plasma avec des couleurs super fidèles (en particulier il n'est pas très saturé à mon goût) donc je suis pas sûr que les subtilités se voient. :P

Logiquement en "vrai" RGB565, la couleur maximale (donc le blanc en théorie), est en fait R=0b11111000 (=248) G=0b11111100 (=252) et B=0b11111000 (=248) soit (248,252,248). La composante G est donc légèrement plus prononcée que les composantes R&B, ce qui donne une très légère "chaleur" à l'image (mais c'est hyper subtil), d'où l'appelation "Greenish screen". D'où la question , mais c'est du chipotage je te l'accorde. Cela dit, c'est toujours une question à se poser dans on travaille avec ce mode RGB565 car on a vite fait de rendre des morceaux de code incompatibles entre eux si on ne fait pas attention.

Une variante très sympa du RGB565 pour les jeux est le ARGB1555 qui code chaque couleur sur 5bits et garde le bit fort pour avoir une transparence nulle ou totale. Mais je ne l'ai hélas jamais vu implémenté dans un hardware correspondant.

Sly
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir Hors ligne Administrateur Points: 24262 Défis: 170 Message

Citer : Posté le 15/11/2021 13:51 | #


Logiquement en "vrai" RGB565, la couleur maximale (donc le blanc en théorie), est en fait R=0b11111000 (=248) G=0b11111100 (=252) et B=0b11111000 (=248) soit (248,252,248).

Je vois, mais ça c'est si l'écran en interne il utilise vraiment du RGB888 et qu'il n'applique pas de correction, aucun n'étant garanti.

(Note aussi du coup sur la question des maximums que dans ton blend tu multiplies au plus par 255 mais tu divises par 256 donc tu assombris un poil. Tu l'as peut-être vu.)

Une variante très sympa du RGB565 pour les jeux est le ARGB1555 qui code chaque couleur sur 5bits et garde le bit fort pour avoir une transparence nulle ou totale. Mais je ne l'ai hélas jamais vu implémenté dans un hardware correspondant.

Dans bopti (le système derrière dimage) j'ai trouvé que le compromis n'en valait pas la peine et j'ai implémenté à la place un format appelé rgb565a qui réserve une valeur 16 bits à l'alpha et tout le reste est en RGB565. Tu as accès à ça dès que tu utilises fxconv. C'est un peu exotique mais les couleurs sont mieux préservées.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Pavel Hors ligne Membre Points: 30 Défis: 0 Message

Citer : Posté le 15/11/2021 15:55 | #


Slyvtt a écrit :

Pour l'instant j'ai pas le hardware, mais logiquement c'est pour bientôt . Merci SynchroDonjon (et Pavel d'avoir choisi la Graph 35 ).


Je vois que j'ai bien choisi mon lot

Une petite remarque. L'émulateur fourni par CASIO est plus lent que la vraie calculatrice, il est donc tout à fait possible que ton jeu fonctionnera bien sur la calculatrice sans optimisations supplémentaires.
Slyvtt Hors ligne Maître du Puzzle Points: 2313 Défis: 17 Message

Citer : Posté le 15/11/2021 18:03 | #


Pavel a écrit :
Je vois que j'ai bien choisi mon lot

Une petite remarque. L'émulateur fourni par CASIO est plus lent que la vraie calculatrice, il est donc tout à fait possible que ton jeu fonctionnera bien sur la calculatrice sans optimisations supplémentaires.


Oui j'avoue que j'étais content que tu prennes la Graph 35 (même si je m'en serai accommodé) car la Graph 90 me tentait bien.

Merci pour l'info, je vais laisser en l'état pour le moment, sans forcément chercher à booster les performances, mais plutôt viser la maintenabilité du code. Si a terme le besoin de performance se fait sentir, je me mettrai alors les mains dans le cambouis pour optimiser à fond.

Je me tâte à regarder si une compilation/conversion de la SDL (1.2) est jouable ou pas, ça pourrait être cool d'avoir cette librairie pour le portage de jeux. Mais je sais pas évaluer à l'instant "t" ce que cela implique en terme de taf. Typiquement une grosse part du boulot pourrait être reprise de l'énorme avancée de Hoffa fait pour porter la lib sur la nSpire, mais en adaptant au hardware de la CG-50 (video et clavier + gestion mémoire spécifique avec heap très limité).

Mais ça fait pas mal de chose dans la "TODO list", entre la STL et la SDL faut pas être trop gourmand.

Ciao

Sly
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir Hors ligne Administrateur Points: 24262 Défis: 170 Message

Citer : Posté le 15/11/2021 18:57 | #


Tu verras les perfs que je t'aurai envoyé la machine du coup (ce qui ne devrait pas tarder ).

Pour la SDL 1.2 ça devrait être possible. Faut juste voir si tu veux émuler l'API ou ajouter une target à la lib. En tous cas je pense que c'est faisable, c'est juste qu'il y a pas beaucoup de grands chantiers en ce moment.

Au passage le tas est pas si petit que ça, 512 + 128 kio de base, et tu peux piquer de la RAM ailleurs s'il le faut (jusqu'à 6 Mo en cas de grosse grosse panique).

Mais oui la STL c'est déjà assez solide.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Slyvtt Hors ligne Maître du Puzzle Points: 2313 Défis: 17 Message

Citer : Posté le 15/11/2021 20:21 | #


Lephenixnoir a écrit :
Tu verras les perfs que je t'aurai envoyé la machine du coup (ce qui ne devrait pas tarder ).

Cool, j'ai hâte de voir la bête.

Lephenixnoir a écrit :
Pour la SDL 1.2 ça devrait être possible. Faut juste voir si tu veux émuler l'API ou ajouter une target à la lib. En tous cas je pense que c'est faisable, c'est juste qu'il y a pas beaucoup de grands chantiers en ce moment.

L'idée est de rajouter une cible pour se servir au maximum de l'existant et juste ajouter localement un "patch" pour brancher les fonctions proprement au hardware. D'après ce que je comprends (mais je peux être complètement dans le faux), la réécriture de la SDL consiste principalement à rediriger les aspects "vidéos" et "claviers", sachant qu'on peut faire en sorte de s'appuyer sur gint. Sur la nSpire, c'est cette philosophie qui est employée, et je trouve ça super pratique. La SDL est vraiment bien conçue dans le sens où il y a un header pour chaque sous-module de la lib (audio, video, mouse, keyboard, CDROM, ...), chacun activable via un #define dans un fichier de configuration par architecture/machine. Par exemple pour la CG-50, tu indiques que tu trash divers modules via par exemple dans le fichier SDL_config.h

#define SDL_AUDIO_DISABLED    1
#define SDL_CDROM_DISABLED    1
#define SDL_JOYSTICK_DISABLED    1
#define SDL_LOADSO_DISABLED    1
#define SDL_THREADS_DISABLED    1


in fine la lib est compilée en prenant en compte seulement les modules demandés. Par contre il faut tout de même faire en sorte que les modules à implémenter soient bien compatible avec le matériel.

Lephenixnoir a écrit :
Au passage le tas est pas si petit que ça, 512 + 128 kio de base, et tu peux piquer de la RAM ailleurs s'il le faut (jusqu'à 6 Mo en cas de grosse grosse panique). Mais oui la STL c'est déjà assez solide.

Ca c'est hyper intéressant car l'intérêt d'une lib comme la SDL, c'est d'avoir moultes ressources à manipuler, d'où besoin de pas mal de mémoire.

Je pense qu'il y a moins de boulot sur la SDL que sur la STL. Je pense que je vais me pencher sur la SDL en premier car la STL, c'est vraiment un gros morceau, surtout que vous m'avez refroidit Pavel et toi sur le filesystem. Donc il va vraiment falloir faire les choses proprement et de manière réfléchie.

A plus

Sly
There are only 10 types of people in the world: Those who understand binary, and those who don't ...

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

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