Voici mon premier projet sur le SDK fx-9860G. Il s'agit d'une petite adaptation du fabuleux Sorcery, légende de la ludothèque 8 bits. Rennomé pour l'occasion Sorcery-G.
** Mise à jour **
Tout en niveaux de gris, avec deux buffer d'affichage pour la fluidité.
Les sources sont disponibles dans le deuxième fichier.
Controles :
Droite / Gauche / Haut avec [Replay]
[OPTN] : Ramasser / échanger un objet.
[MENU] : quitter.
***
Pour les prochaines versions :
- enemis
- inventaire
- fenêtre de crédit
Merci à tous pour vos encouragements.
Enjoy.
Suite à un vieux bug moisi, j'ai perdu environ 600 lignes de code bien touffu concernant le chargement et l'organisation des données. Rage et désespoir sont au rendez-vous
Bon, comme je vois que quelqu'un cherche exactement ce que Tiles Creator est censé permettre de faire, je me permet quand même de conseiller de faire un tour sur le topic de mon programme.
Je n'ai pas eu le temps de tester avec ce week end de release mais je promet de jeter un coup d'oeuil dans pas longtemps
Bon courage pour la suite, et comme PierotLL, si t'as des questions sur le SDK ou accessoirement sur Tiles Creator, ou que tu veux un avis, n'hésite pas à me MSNer
PS :: si LS, un autre admin ou un connaisseur pouvait me dire comment insérer une adresse contenant des '[' et ']' dans un lien BBcode, par ce que c'est un peu chiant de passer par une redirection
Pour le projet, j'ai réécrit a peu près 70% du code, completement réorganisé les données proprement en struct, et pa mal optimisé l'affichage. Encore deux ou trois détails à regler et je publie une nouvelle version, certainement demain dans la soirée, ou cette nuit suivant le statut de mon insomnie
Premiers essais de niveaux de gris relativement concluant, à deux détails près :
- Le gris clair est un poil trop clair à mon goût. J'ai choisi comme valeurs GrayInit(1452, 3273); que j'ai repris dans des sources gracieusement fournies par Pierrotll. Mais comment bien choisir ces valeur ? Il y a une regle de base à respecter en fonction du temps mis par la boucle principale à s'executer ou comment ça se passe ?
- Plantage de la calculatrice à la sortie du programme, freeze total et bouton restart obligatoire. J'ai pourtant bien mis un GrayEnd(); à la sortie de la boucle... Est-il possible qu'une infime difference entre une 85 et une 95 (dans la ROM ou je ne sais où) puisse faire planter le chose ?
Je place mes trois fichiers sources modifiés en piece jointe si quelqu'un veut y jeter un oeil, voir aux lignes 40->50 de SGEngine.c comment ça se passe.
Je te conseille d'utiliser ces valeurs trouvées par Kristaba : 6987, 3269
Ça donne des gris très stables qui ne font pas mal aux yeux.
Pour éviter le plantage à la sortie du programme, il faut appeler Reset_Calc à la fin. Cette fonction redémarre la calculatrice.
On est hélas obligé de l'utiliser quand on utilise les niveaux de gris. il doit y avoir un truc oublié dans GrayEnd.
Merci pour les valeurs, c'est pas mal du tout. J'imagine qu'il faut être le plus synchro possible avec le raffraichissement de l'écran.
Ca pose un problème de les utiliser dans l'autre sens (3269,6987) ?
Bon il faut vraiment que je pense a vous contacter sur un chat parce que les questions commencent à se faire précises.
J'hésite aussi à implémenter un double buffer pour l'affichage (donc 4 buffers au total). Si je doit le faire autant le faire maintenant peut-être...
@Kristaba : Ton soft est nickel ce dont j'avais besoin 8)
Quelques réponses :
Pour les valeurs des gris, comme tu le dis c'est une histoire de synchronisation avec le rafraichissement de l'écran en gros (probablement pas que l'écran lui-même, le driver d'affichage y joue sûrement, je suis pas sûr), mais personne n'a trouvé d'algorithme miracle pour trouver les meilleurs valeurs ou prédire le résultat de valeurs, donc il faut tester manuellement
J'ai fait un soft pour ça (en 2 buffer et 3 buffer, mais le 3 buffer n'a jamais donné un rendu correct... pour le moment), je vais les mettre en ligne tant qu'à faire, ça permettra peut-être de trouver mieux
Pour l'utilisation dans l'autre sens, aucun problème normalement puisque ça se joue avec des timers cycliques (en gros dit toi que tu fais soit 1, 2, 1, 2 (...) soit 2, 1, 2, 1 (...), ça revient au même ). Par contre, évidemment, les buffers seront inversés (celui qui gère le foncé en (3269, 6987) gèrera le clair en (6987, 3269), normal).
Pour nous contacter en live, je te conseil de te mettre sur MSN. Certes c'est très discutable comme système de communication et ça fait plutôt noob, mais la plus part de la communauté a une adresse
Comme dis plus haut, je me ferais un plaisir, et PierotLL aussi je pense, de répondre à tes questions si tu en as
Pour le double buffering, je te le conseille grandement. En effet comme tu as dû comprendre le système de gestion des niveaux de gris actualise en permanence l'écran, donc si tu n'utilises pas le double buffering dans un jeu il peut arriver par exemple que l'on perçoive le rafraichissement de la map par exemple. Pis à moins d'avoir besoin de beaucoup de mémoire, le double buffering coûte rien (temps d'execution quasiment nul puisqu'il suffit de changer le pointeur représentant le buffer -> pas de copie profonde à faire -> quasiment instantané ).
Pour mon soft, ravi que ça serve, et si t'as des question ou des suggestion n'hésite pas hein, j'suis là pour ça!
Merci pour tes conseils. Je me met sur le double buffer dès que j'ai le temps.
Un autre soucis que j'ai, c'est le chargement des données. Pour le moment il n'y a qu'un niveau et quelques sprites, tout est codé "en dur". Mais quand je commencerais à faire d'autres niveaux, il faudra que je me pose la question du chargement. Et là j'avoue que j'ai aucune idée de comment les stocker sans toutes les charger en RAM d'un coup. A part creer un fichier de donnée externe, ce que j'aimerais éviter dans la mesure du possible (mais plus j'avance et plus je me dis que je ne vais pas avoir le choix). Autrement j'ai pensé toute les coller à la fin de l'executable après la compil, mais pareil je ne connais pas assez le format pour ne pas tout casser. Si quelqu'un à une idée la dessus ?
Sinon je n'ai pas d'adresse MSN, je vais en creer une, ça sera plus pratique.
@pierotll : Au début j'utilisait Reset_Calc() sans trop savoir pourquoi, juste parce que je l'avais vu dans un exemple de revolutionFX. Je l'ai retiré parce que j'ai remarqué que cela détruit les matrices, les listes ect. Ce qui n'est pas très cool. Comment cela se passe, ça redemarre direct la machine dès que l'instruction est rencontrée ou on a le temps de sortir du programme proprement ?
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