Forum TI-Planet.org

Bienvenue au club. Jamais réussi à compiler autre chose que le projet 'sample'. Pas pour rien que je disais que selon moi le SDK et sa documentation avaient besoin d'un bon rafraîchissement.
A chaque fois, des erreurs incompréhensibles.

Oh je vois. De ce que je comprends, c'est une erreur qui vient du fait que le SDK contient une version compilée de GCC assez ancienne, qui supporterait mal Windows 10 (je n'ai pas fait de recherches approfondies, mais c'est ce qui a l'air de ressortir).

Pour le coup, je maîtrise trop mal Windows pour envisager de compiler GCC dessus. Je vais essayer de voir si je peux parler à des gens qui en savent un peu plus… ^^'

oui j'arrive à compiler avec cette erreur quelques fois mais je vois bien qu'il y a un problème
un nouveau sdk serait le bienvenu, je vais essayer de mieux le comprendre pour voir les problèmes
j'ai une petite question:
pour les images (selected / unselected) des applications quand j'essaye de les modifier j'ai une erreur lors de la compilation. Quel est le bon format / palette de couleurs ?
Pour les images dans les programmes j'ai remarqué qu'elles pouvaient être codées en listes d'octets en héxadécimal
C'est le seul moyen de mettre des images ? comment la transformer ? avec source coder de cemetech ?
merci

Ça reste assez embêtant d'avoir une erreur à la compilation qui ne dépend pas vraiment du code que tu es en train de compiler… :s
Je suis en train de voir ce que je peux faire pour ça.

Pour ce qui est des icônes, leur format est le suivant : ce sont des bitmaps, de taille 92×64, en format RGB565 (i.e. 16 bits d'information par pixel : 5 pour le rouge et le bleu et 6 pour le vert, c'est le format utilisé un peu partout par la calculatrice).

Pour utiliser des images au sein de tes programmes, les encoder “en hexa” est en effet une des seules solutions (en fait tu as au moins une autre option tout de même, je t'invite à regarder ce sujet, mais je pense que pour la plupart des cas, l'encodage dans le programme est une solution plus agréable à utiliser).
En fait ce que tu veux faire, c'est stocker directement les pixels de ton image ; la Prizm encode chaque pixel sur deux octets (avec le même format RGB565 que pour les icônes). Or, c'est quand même un peu lourd d'avoir deux octets par image : on peut réduire le poids total d'un sprite en utilisant une palette. C'est à dire qu'on va regarder combien de couleurs différentes apparaissent dans le sprite, et si il y en a moins que 256 par exemple (ou qu'on réduit ce nombre à 256 par divers moyen), il peut suffire de repérer les couleurs du sprite par un nombre codé sur un octet, et de le faire correspondre à la couleur réelle en utilisant un second tableau contenant lui les vraies couleurs, mais en une seule fois (c'est la palette).
La routine d'affichage du sprite dépendra alors de l'encodage choisi.
Je ne sais pas si j'ai été très clair, et peut-être étais-tu déjà familier avec ça… ^^
En tout cas, si ça n'est pas hyper clair, et que tu as encore quelques doutes sur la manière dont on peut jouer avec la mémoire vidéo, je t'invite fortement à prendre une routine d'affichage de sprite avec palette, et à la décortiquer un peu, après ça tu devrais avoir les idées assez claires sur la VRAM. (Ça n'empêche pas que je serai toujours content de répondre à des questions si il t'en reste ou que ça se passe mal avec la lecture de la routine hein ! ^^)


Enfin, toujours est-il que ça serait un peu fastidieux de faire ça à la main, donc on peut effectivement passer par d'autres outils ; SourceCoder de chez Cemetech en est un, et il y a aussi le SpriteCoder de Smashmaster que tu peux trouver ici.

Si tu cherches une routine à étudier, tu peux par exemple regarder celle-ci, qui vient de GravityDuck, prend un bitmap codé sur 8bits, et qui a en plus un canal alpha, c'est à dire une couleur (ici mask) dont on décide qu'elle ne sera pas affichée, et qui permet de faire un effet de «transparence» sur le sprite.

Show/Hide spoilerAfficher/Masquer le spoiler

Code: Tout sélectionner

void CopySpriteMasked(char* bitmap, short* palette, int x, int y, int width, int height, short mask)
{
   short* VRAM = GetVRAMAdress();

   int y_index;
   int x_index;
   short * base = y * LCD_WIDTH_PX + x + VRAM;
   for (y_index = height; y_index > 0; --y_index, base += LCD_WIDTH_PX - width) {
      for (x_index = width; x_index > 0; --x_index, ++base, ++bitmap) {
         if (palette[*bitmap] != mask) *base = palette[*bitmap];
      }
   }
}

Merci beaucoup pour ta réponse
je vais étudier tout ça, c'est très intéressant
Cependant j'ai besoin de m'améliorer un peu sur les pointeurs pour bien comprendre leur fonctionnement.
Pour un test je vais déjà essayer de compiler un programme avec une image, ce serait déjà un bon début
Sinon pour le problème de compilation je suis toujours sans idées, je ne comprends pas encore assez le principe. En attendant certains de mes tests fonctionnent, je n'ai pas fini de découvrir tous les syscalls !

Pour le problème de compilation, malheureusement et de ce que je comprends, il n'y a pas vraiment à avoir avoir d'idées j'ai l'impression, c'est juste que le SDK que tu as est un peu trop vieux et semble mal tourner sur les versions les plus récentes de Windows.
Pour y remédier il faut recompiler ce qui constitue la base du SDK, c'est à dire le compilateur et sûrement quelques outils qui vont avec ; j'ai essayé de deux manières différentes pour l'instant, sans succès. :s
J'ai peut-être encore une autre piste pour faire ça mais je suis assez peu à l'aise avec ce genre de grosses manips (compiler un compilateur ça commence à être un truc un peu imposant) sur Windows.

Si jamais tu envisageais de passer un jour à Linux, ça peut être une raison supplémentaire pour t'y plonger, vu que dessus on sait bien faire en revanche ; mais je sais que c'est une solution qui n'en est pas vraiment une pour tout le monde, donc je continue à essayer de voir ce que je peux faire.

Ça aura mis un peu de temps, mais n'ayant pas vraiment réussi à avancer sur la manip' que je comptais faire, j'ai fini par trouver quelqu'un (en la personne d'Intelligide) qui avait déjà réussi à la faire il y a un moment et m'a envoyé le résultat !
J'ai pu donc «repackager» le SDK avec une version de GCC plus récente. Je ne garantis pas que ça résoudra le problème, ni même que ça marchera tout court (je n'ai pas pu tester sur mon ordi… ^^), mais c'est une bonne piste je pense.

(la version «plus récente» du SDK)

Il a pris du poids par rapport à l'ancien en revanche, je ne sais pas si ça vient simplement de la version de GCC, plus récente, ou si des options de compilation ont pu jouer à ce point…

Ce qui serait intéressant, c'est que, avec ce «nouveau» SDK (tu devrais t'y retrouver : à l'usage, rien ne devrait être vraiment différent de l'ancien si tout se passe comme je l'imagine), tu puisses essayer de compiler le projet d'exemple (ce serait un rassurant que au moins celui-ci fonctionne déjà !), et que tu essaies ensuite de compiler un des programmes qui provoquait certaines de ces erreurs peu compréhensibles. Si cela fonctionne, il faut voir à l'usage si elles réapparaissent à un moment ou à un autre ; de toute manière ça ne pourra normalement pas être pire que la première version du SDK que tu as eue, et en plus j'ai envie de croire qu'elles ne reviendront pas !

Si le test est concluant (tu joues un peu le rôle de cobaye finalement, j'espère que ça te va ) j'hébergerai ça de manière un peu plus permanente quelque part !

En attendant si tu as d'autres questions (sur l'exemple précédent par rapport à la mémoire vidéo, ou sur tout autre chose), n'hésite pas.

Bonsoir,
J'ai testé la "nouvelle" version du SDK mais lors de l'exécution du make j'ai une erreur:

ça serait juste un dll manquant, je ne l'ai pas dans l'ancienne version.
Sinon je continue de découvrir les fonctions et de m'améliorer en C
Cependant en ce qui concerne les images je n'arrive pas à les convertir en RGB565, cela provoque toujours des erreurs de compilation.

Pour la dll manquante, essaye d'ajouter ce fichier dans le répertoire bin du sdk. Je sais que ça a l'air d'être la bazar pour l'instant, mais j'ai vraiment rien pour tester le résultat final, donc ça se fait par tatonnement un peu… ^^'

Lorsque tu parles des erreurs de compilation sur les images, tu parles des icônes ou de l'utilisation de sprites au sein même du programme ?
Si c'est au sein du programme, tu aurais un exemple de code provoquant une telle erreur ?
Si c'est par rapport aux icônes, je ne sais pas trop, ça doit dépendre du logiciel que tu utilises pour éditer tes icônes, le mieux est peut-être de partir des icônes d'exemple et de les éditer en essayant de ne pas changer le format d'enregistrement.

Bonsoir,
je suis content j'ai trouvé une solution pour le message : WARNING: Couldn't compute FAST_CWD pointer.
cela avait un rapport avec cygwin, j'ai réussi à trouver un dll à jour grâce à ce site:
https://cygwin.com/ml/cygwin/2017-01/msg00408.html
C'est cygwin1.dll

Pour ce qui est des images je parlais des icônes (nomées selected / unselected par défaut). je suis en train d'explorer certains programmes pour réussir à mettre des images dans un programme sans succès pour (l'instant ... )

Code: Tout sélectionner

1 [main] [ 2696 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
sh3eb-elf-gcc -MMD -MP -MF C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/build/test.d -Os -Wall -mb -m4a-nofpu -mhitachi -nostdlib   -IC:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/build -IC:/Users/xt17/Desktop/PrizmSDK-0.3/include -c C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c -o test.o
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c: In function 'getStrn':
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c:7:5: warning: implicit declaration of function 'DisplayMBString' [-Wimplicit-function-declaration]
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c:11:19: error: 'KEY_CTRL_EXE' undeclared (first use in this function)
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c:11:19: note: each undeclared identifier is reported only once for each function it appears in
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c:14:25: error: 'KEY_CTRL_EXIT' undeclared (first use in this function)
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c:19:13: warning: implicit declaration of function 'EditMBStringChar' [-Wimplicit-function-declaration]
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c:22:13: warning: implicit declaration of function 'EditMBStringCtrl' [-Wimplicit-function-declaration]
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c: In function 'askQ':
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c:28:25: error: storage size of 'fill' isn't known
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c:35:5: warning: passing argument 3 of 'PrintXY' discards 'const' qualifier from pointer target type [enabled by default]
C:/Users/xt17/Desktop/PrizmSDK-0.3/include/display.h:28:6: note: expected 'char *' but argument is of type 'const char *'
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c:28:25: warning: unused variable 'fill' [-Wunused-variable]
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c: At top level:
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c:38:6: warning: return type of 'main' is not 'int' [-Wmain]
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c: In function 'main':
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c:42:5: warning: implicit declaration of function 'Bdisp_AllClr_VRAM' [-Wimplicit-function-declaration]
C:/Users/xt17/Desktop/PrizmSDK-0.3/projects/example/src/test.c:47:5: warning: implicit declaration of function 'PrintMini' [-Wimplicit-function-declaration]
make[1]: *** [test.o] Error 1
make: *** [build] Error 2

Lorsque je veux compiler des codes d'anciens programmes je suis confronté à une liste d'erreurs souvent, il y aurait une différence au niveau de la norme c ? Car si les sources sont bien celles d'origine je devrais pouvoir le compiler par moi-même