Posté le 31/12/2020 13:23
RDP 195 RDP 196
Le projet avance toujours en alternance avec JTMM2 : si je ne fais pas de commit sur JTMM2 quelques jours d'affilé cela signifie que je travaille sur Sunrise. Ce jeu utilise énormèment d'opérations et de logique, j'ai remarqué qu'il tourne beaucoup plus vite sur 90+E que 35+E II ! Le Basic de la 90+E est donc presque deux fois plus rapide, mais le raffraichissement de l'écran (qui arrive après chaque opération de dessin) est lui plus lent que celui des calculatrices monochromes. Pour donner une idée, en l'état actuel le chargement d'un écran prend environ 3 secondes sur 90+E et 7 secondes sur monochrome.
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 242 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 31/12/2020 13:25 | #
Ton nouveau jeu Just Too Tricky Mechanics 2 ?
Pas surprenant, le proco va plus vite et l'écran plus lentement.
Citer : Posté le 10/05/2021 15:03 | #
Salut salut, j'avais complètement oublié ce projet et je suis prêt à parier que vous aussi
Masséna m'a posé quelques questions sur le stockage de map pour son prototype, et je me suis rappelé que même si ce projet est abandonné, le code existant pourra être utile à certains. Si vous rêvez d'un open world sur calto avec environnement destructible et persistant, j'ai déjà fait le moteur. Enjoy.
=> https://gitea.planet-casio.com/KikooDX/noon2
Pour tester on-calc, choppez SUNRISE.g1m et lancez ~SG.
Vous pourrez voir que la map de 21609 cases pèse 37080 octets.
Le code n'est pas très optimisé, mais c'est un joli prototype/POC de ce que l'on pourrait faire en Basic.
Voici la partie du log IRC où j'explique à Masséna quelles méthodes sont disponibles pour ce type de stockage et leurs avantages et inconvénients. C'est vraiment le truc but, certains mots ne sont pas adaptatés mais ça explique en partie pourquoi j'ai fait ça.
2021-05-10 14:12:35 KikooDX Il y a 20 Str sur la calculatrice, pouvant contenir 255 octets chacune
2021-05-10 14:12:58 KikooDX 4802 / 255 ~= 19
2021-05-10 14:13:27 KikooDX Si tu fais des feats de folie, le truc tiendrait dans les 20 et serait rapide et opti. Mais ce serait bien galère, je ne te le recommande pas.
2021-05-10 14:14:31 KikooDX Si on prend la méthode simple dans une matrice (càd une case de matrice = une tuile en jeu), le truc pèserait 57624 octets
2021-05-10 14:14:58 KikooDX C'est beaucoup trop lourd, vient la méthode tordue.
2021-05-10 14:15:16 KikooDX En utilisant des puissances et de la décomposition, tu peux stocker plusieurs tuile de jeu dans une case de matrice.
2021-05-10 14:15:47 KikooDX Faudra choisir le nombre de valeurs différentes qu'une tuile peut avoir, mais je me souviens qu'avec 26 ou un truc du genre je pouvais en mettre 7 par case
2021-05-10 14:16:01 KikooDX Ce qui donne 8232 octets pour le même contenu ici
2021-05-10 14:17:03 KikooDX Vu que tu veux faire un POC, la méthode simple (faire des sous-programmes qui set et get des cases) est la meilleure, parce que c'est le plus lisible. Ce sera extrêmement lent, mais le monde sera continu une fois généré.
2021-05-10 14:19:07 KikooDX J'ai retrouvé mon code de Sunrise, je vais l'upload pour que tu puisses voir si nécessaire.
2021-05-10 14:20:33 KikooDX Il n'est pas optimisé partout, mais loin d'être dégueulasse.
2021-05-10 14:22:45 KikooDX En l'occurence j'ai 147 chunks de 21x7 stockés, je te dis le poids une fois la génération terminée
2021-05-10 14:31:24 KikooDX Je suis en train de convertir le tout en .txt, gimme a minute
2021-05-10 14:43:47 KikooDX Yep la map fait 37080 octets
2021-05-10 14:44:01 KikooDX C'est très propre quand on considère ses dimensions absurdes