Nombre de visites sur cette page : 47961 Score au progrank : 126 Note actuelle : 10/10 noté 10 fois Vous devez être connecté(e) pour noter (inscription).
Ce programme a été récompensé pour sa qualité par le label Planète Casio.
Description :
Voici l'adaptation fidèle de Gravity Duck pour Prizm.
Votre Dieu vous a confié la tâche délicate de récupérer tous les oeufs en or. Votre unique atout est de pouvoir changer la gravité. 40 niveaux sont à résoudre. Ce jeu se joue à l'aide des touches fléchées pour se déplacer et de SHIFT pour changer la gravité.
Le jeu overclock la calculatrice à 94.3MHz pour gagner un peu de vitesse (aucun risque pour la calculatrice). En quittant le jeu la fréquence du processeur est remise telle qu'elle était avant de lancer le jeu.
Appuyez sur OPTN pour afficher le compteur d'images par seconde.
Pour coller parfaitement au jeu flash il ne manque que la transition entre les niveaux (fondue au noir et apparition/disparition du canard), mais je n'ai plus assez de mémoire disponible pour charger l'animation. Pour cette raison le jeu est en version 0.9 et passera en 1.0 si je trouve un moyen d'ajouter ça.
Aux développeurs : certains fichiers sources peuvent être utilisés tels quels dans vos projets, regardez le README et servez-vous.
Les quelques tests que j'ai faits avec mkg3a posent aussi problème. Dans tous les cas, je crois qu'on n'a pas encore réellement résolu le bug, et je soupçonne une optimisation du compilo qui traîne dans un coin.
L'addin compilé avec -O0 a le bon goût, outre le fait de peser 40ko de plus (ça c'est pas hyper étonnant ceci dit), de provoquer un System Error lorsqu'on essaie de le lancer… (De même d'ailleurs si on ne lui précise pas d'option d'optimisation ; je ne sais pas si c'est strictement équivalent à -O0 : vu la taille du fichier produit, on dirait)
L'addin refuse de compiler avec -O2 ou -O3, avec des erreurs au moment d'assembler, de type :
⋅⋅⋅
/tmp/ccJQrTTV.s:246: Error: symbol `syscall_adress' is already defined
/tmp/ccJQrTTV.s:247: Error: symbol `getVRAM' is already defined
/tmp/ccJQrTTV.s:142: Error: misaligned data
/tmp/ccJQrTTV.s:26: Error: negative offset
/tmp/ccJQrTTV.s:26: Error: pcrel too far
⋅⋅⋅
Ça doit pouvoir se régler en touchant au code. (Ça vient de l'assembleur inline que Pll utilise pour les syscalls, je suppose…)
En revanche avec -O1, l'addin compile bien, n'est pas beaucoup plus gros qu'avec -Os (de l'ordre de 4ko), et effectivement les problème de couleurs disparaissent… J'aurai dû essayer ça plus tôt !
Toujours est-il que je ne qualifierai pas le processus d'«entièrement maitrisé».
On dirait bien que c'est du compilateur, donc. Je pourrai jeter un oeil aux sources des sycalls et du dessin si tu veux... j'ai déjà dû retoucher ML pour la faire marcher. (Aussi bon qu'était PLL, il y a quand même des trucs qu'il a faits un peu vite.)
En fait vu que j'utilise la libfxcg maintenant, l'appel de syscall qu'il faisait n'avait plus beaucoup de sens vu que la bilbiothèque le rend d'emblée disponible : donc en enlevant l'assembleur inline pour le remplacer par l'utilisation de la bibliothèque, ça compile avec -O3 et -O2.
Donc pour résumer :
Avec -O0 ou aucune option : on a un System Error.
Avec -Os ou -O2 : on a le problèmes de couleur.
Avec -O1 ou -O3 : tout semble fonctionner normalement.
Et avec -Os ou -O2, le correctif qui consiste à faire un accès bidon à une couleur de chaque sprite avant de les charger en heap fonctionne, et on peut aussi avoir des couleurs correctes.
Ça te donne déjà quelques pistes : tu peux regarder quelles options de -Os sont ajoutées par rapport à -O1 (l'une d'elles doit introduire le bug), et quelles options de -O3 sont ajoutées par rapport à -O2 (l'une d'elles doit le corriger).
Ensuite, faudra chercher où est le pointeur volatile qui a été oublié ou truc de ce genre.
Le truc c'est que les inclusions ne sont pas aussi propres que ça…
Typiquement, je viens de trouver que -O2 -finline-functions (-finline-functions est une des options ajoutées par -O3 par rapport à -O2) règle le problème des couleurs, là où avec juste -O2 ça ne fonctionne pas. Cependant l'option -finline-functions est aussi ajoutée par -Os, et avec -Os les couleurs ne fonctionnent pas. J'ai l'impression que c'est plus des combinaisons d'option qui rentrent en jeu…
Cependant l'option -finline-functions est aussi ajoutée par -Os, et avec -Os les couleurs ne fonctionnent pas.
Le coup des combinaisons, c'est possible, mais là j'ai quand même un doute. Dans mon manuel :
-Os: Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size.
-Os disables the following optimization flags: -falign-functions -falign-jumps -falign-loops -falign-labels -freorder-blocks -freorder-blocks-algorithm=stc
-freorder-blocks-and-partition -fprefetch-loop-arrays
Donc à mon avis pas de -finline-functions dans -Os. Je me trompe quelque part ?
Edit : Ça m'étonnerait aussi beaucoup sur le principe que cette fonction soit activée avec -Os, pour des raisons évidentes.
Et de plus, ajouter -finline-functions à -Os ne change pas la taille de l'exécutable produit, pas plus qu'il ne règle le problème des couleurs… Donc je tends à penser que l'option est bien ajoutée par -Os…
Hmm... j'ai fait un diff entre les options de -O2 et celles de -O3, l'inlining me paraît être le genre de truc à faire foirer le programme.
Visiblement le plus efficace est encore de regarder dans le code. Tu m'as dit que si tu observais la valeur de la couleur au cours des différents appels de fonctions, comme par magie elle se « fixait » et elle arrivait entière. C'est d'ailleurs ce en quoi consiste ton fix, il me semble.
Tu as regardé à partir de quel appel le fix fonctionne ? (En gros, à quel endroit la valeur est-elle perdue si on ne l'observe pas ?) Ça m'étonnerait que le fix marche juste après que la valeur ait été lue depuis la mémoire, si ?
Bon, en m'appuyant sur les recherches de Nemhardy, j'ai sorti deux-trois vers du code de PLL et j'ai réussi à débugger définitivement le machin !
Je joins à ce post une version g3a fonctionnelle de GravityDuck sur Ggraph 90+E. Je mets aussi les sources dans le suivant.
Le système de chargement de bitmaps pas particulièrement futé était à l'origine du bug. Si vous avez un G90, n'hésitez pas à tester pour nous confirmer si ça marche
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
(De même d'ailleurs si on ne lui précise pas d'option d'optimisation ; je ne sais pas si c'est strictement équivalent à 
