Bonjour à tous, bonne année, mes meilleurs vœux ! Et bienvenu sur le plateau de Planète Casio ! Avec nous ce soir deux invités de marque : KikooDX et Shadow15510. Mais je laisse notre cher présentateur, vous présenter ces deux projets ! Laurent Outan, c'est à vous !
Laurent Outan, vous m'entendez ? Bonjour ! Oui, oui je vous entend très bien.
Alors M. Outan ? Quels projets avons nous aujourd'hui ?
Eh bien, nous avons deux projets, comme vous l'avez dit… le premier de KikooDX parle d…
Ah très bien ça… et donc de quoi parle le projet de KikooDX… M. Chimpa… Outan ?
Comme j'allais vous le dire le projet de KikooDX porte sur un jeu célèbre : Binding of Isaac ! Je vous laisse découvrir les avancées effectuées depuis la semaine dernière :
KikooDX a écrit : Bonjour !
Je vais continuer de faire des mises à jour hebdomadaires sur l'avancement de mon nouveau projet, que je vais abréger TBOI:UR (The Binding of Isaac: Ultra Redux).
Le nom n'est pas permanent.
Depuis la semaine dernière, j'ai rajouté des fonctionnalités sur base quotidienne.
- Les collisions avec les murs. Le jeu charge la carte dans une Str puis la lit et crée une matrice contenant les collisions. Plus rapide à l'exécution, mais rajoute un temps de chargement de une seconde.
- Gestion de la vie et du Game Over. (Attention elle part très vite.)
- Variables de joueur, déterminant sa vitesse de course, d'attaque, ses points de dégâts et ses points de vie.
- Les ennemis sont gérés, je peux en rajouter de façon souple ET ils ne laguent pas trop.
- Attaques du joueur implémentées.
- Le joueur ne peut pas sortir d'une salle tant que le combat est engagé.
- Les salles "nettoyées" ne font pas réapparaître les ennemis quand revisitées.
- La map ne peut être ouverte qu'hors combat. (Toujours F1 pour l'ouvrir.)
- Et enfin, le meilleur pour la fin : le caca est implémenté
- J'ai sûrement oublié des choses, du coup une vidéo au cas où
Je recommande de tester avec et sans overclock, le jeu est jouable dans les deux cas mais est beaucoup plus fluide avec oclock
Controles
Cliquez pour recouvrir
Replay pour se déplacer, OPTN/ALPHA/^/log pour tirer, F1 pour afficher la carte (hors combat) et EXIT pour quitter.
Le jeu doit prendre 5 minutes max. à tester on-calc, je m'appuierais sur vos retours pour la suite A noter que les stats du joueur dans cette version de test sont god tier, il est extrêmement rapide et peu tirer à tous les cycles. Ce ne sera pas le cas dans la version finale.
J'attend surtout des rapports de bugs, j'ai pu en manquer Bug connu : certains murs en bord de map sont manquants. Je le fixe aujourd'hui.
C'est super comme projet ça ! En plus ça fait longtemps qu'on parle d'une adaptation de ce jeu ! Il n'y a encore de topic dédié, Mais n'hésitez pas à laissez vos impré…
C'est bon là, je peux en caser une… ? C'est quand même un monde ça… On me demande de présenter un émission pour vieux neurasthénique et en plus on me laisse pas la faire !
Oui bon ben ça va M. Gorille hein… Je la vous laisse votre émission. Et pis plutôt que de râler, vous feriez mieux d'activer un peu…
Je reprend, en plus vous dites n'importe quoi… C'est super comme projet ça ! En plus ça fait longtemps qu'on parle d'une adaptation de ce jeu ! Il y a même un topic dédié !
Il nous reste le projet de Sahdow… euh Shadow15510. Commencé en début de semaine le projet a tout de suite été épaulé par KikooDX et a un topic dédié ! Je vous laisse (re)découvrir ce projet :
Shadow15510 a écrit :
Bonjour à tous !
J'ai récemment entamé un… nouveau… euh… hm, hem euh… projet ? Enfin celui-là je pense que j'ai une chance de le finir un jour… (-_-')
Bref ce nouveau projet c'est… RimWorld ! Un jeu de survie où le but est de faire prospérer une colonie d'humains dans un environnement hostile, à vous de gérer vos ressources et de construire des infrastructures pour permettre à vos humain de survivre… Il s'agit donc d'un jeu entre survie, gestion et stratégie…
D'autant plus que vous n'êtes pas seul sur la planète… D'autres puissances bien mieux organisées ont déjà colonisé une partie du territoire et l'extraction de ressources est automatisée par des robots dont le but est de garantir le bon déroulement de ces exploitations… Or voila que vous débarquez. Il faudra donc compter sur vous pour vous défendre. Mais peut-être saurez-vous trouver des alliés avec qui échanger ??
De manière plus pratique, la gestion de la météo est finie. Pour l'instant elle est stockée à part en vue d'une future mise en commun. J'ai peur que la météo fasse chuter la vitesse du jeu. Donc c'est codé, c'est plutôt au point, mais je pense le rajouter en dernier pour avoir une vitesse d'exécution maximale.
Bon, assez parler, je vous envoie les premiers screens de ce futur jeu ! :
Concernant quelques petites modifications, j'utilise désormais la police minimini de C.Basic ce qui permet d'avoir deux lignes sur la barre de texte du haut. Les tiles du jeu ne sont pas faite. Je pense en fait faire un dossier contenant toutes les images du jeu au format bitmap. J'ai donc commencé à dessiner quelques tiles avec KikooDX qui m'a offert son temps (@KikooDX : merci encore ! ). Rien de spectaculaire pour l'instant, sauf peut-être les murs :
Un projet qui a déjà évolué vers des graphismes plus évolués… mais la vitesse d'exécution en souffre… Un projet à suivre !
C'est bon, M.Bonobo, je peux terminer ? …Naon. Et arrêter d'écorcher mon nom. Pour finir, voici les programmes de la semaine. On se retrouve très bientôt pour le Jeu du Mois de Noël avec au programme les jeux de Novembre et de Décembre 2019… À la semaine prochaine !
C.Basic has a function to measure program execution time.
When "Exec TimeDsp" of Setup is set to On, the elapsed time is displayed after execution.
The resolution can be changed to 1/32768 seconds with [F3] (%HR).
A sample program for drawing 288 tiles of 16x16 by _Bmp16 is attached.
The drawing data is set in a matrix.
The execution time including PutDisp_DD is 0.053 seconds.
I heard and knew about the mechanism of DMA transfer in the back process before, but I have not adopted it yet.
I think it will help speed up if use it well.
Drawing in C.Basic is a double buffer like in C.
After writing to VRAM prepared by the system, transfer by PutDisp_DD.
SysCall for drawing uses only PutDisp_DD.
The 16-bit color drawing program uses an original library similar to the monochrome library.
VRAM is secured in the stack area separately from the system VRAM for graphics and text for compatibility with the Basic Casio.
They are 4-byte aligned and can transfer long words.
Je continue à développer C.Basic. (Il est compatible avec Basic Casio.)
Overclocking utilitaire Ftune/Ptune2/Ptune3 est également disponible.
Si vous avez des questions ou un rapport de bogue, n'hésitez pas à me le faire savoir.
Sorry, I misunderstood the meaning of the question.
There is no command that only measures parsing or the actual execution time inside a command.
C.Basic can measure only the execution time for command.
This is a method of measuring the execution time in a C.Basic program.
Use the Ticks command to measure with 1/128 second accuracy.
Use the Ticks% command to measure with 1/32768 seconds accuracy.
(There are some errors)
0->Ticks%
...
Ticks%/32768 // seconds of execution time
A sample of yesterday's sample rewritten with the above measurement method is attached.
It runs in integer mode and omitt PutDisp_DD.
Execution time: about 0.038 seconds
In the latest updat 1.43beta,
Execution time: about 0.019 seconds.
Je continue à développer C.Basic. (Il est compatible avec Basic Casio.)
Overclocking utilitaire Ftune/Ptune2/Ptune3 est également disponible.
Si vous avez des questions ou un rapport de bogue, n'hésitez pas à me le faire savoir.
You are welcome.
I'm glad if you use it well.
(Please note that Ticks% cannot be used with SH3 calculators.)
Je continue à développer C.Basic. (Il est compatible avec Basic Casio.)
Overclocking utilitaire Ftune/Ptune2/Ptune3 est également disponible.
Si vous avez des questions ou un rapport de bogue, n'hésitez pas à me le faire savoir.
Sentaro21 a écrit : A sample program for drawing 288 tiles of 16x16 by _Bmp16 is attached.
The drawing data is set in a matrix.
The execution time including PutDisp_DD is 0.053 seconds.
This is pretty good! But then why did you have much worse performance before (quoted below)? Is it related to the improvements in version 1.43?
In an experiment using _Bmp16, a drawing-only program,
Drawing of 288 tiles (16x16) takes 0.2 seconds.
That is about 5fps.
I heard and knew about the mechanism of DMA transfer in the back process before, but I have not adopted it yet.
I think it will help speed up if use it well.
As long as you use Bdisp_PutDisp_DD which uses the DMA (but waits for it to finish), you are in a pretty good situation. The only thing to absolutely not do is transfer by hand.
The 16-bit color drawing program uses an original library similar to the monochrome library.
In this case, it should be fast. 0.053 seconds is not bad at all, I just don't understand why you had 0.2 before.
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
Un jeu de survie où le but est de faire prospérer une colonie d'humains dans un environnement hostile, à vous de gérer vos ressources et de construire des infrastructures pour permettre à vos humain de survivre… Il s'agit donc d'un jeu entre survie, gestion et stratégie… 
Qcm Capitale de maintore
Citer : Posté le 09/01/2020 13:05 | # |
Fichier joint
C.Basic has a function to measure program execution time.
When "Exec TimeDsp" of Setup is set to On, the elapsed time is displayed after execution.
The resolution can be changed to 1/32768 seconds with [F3] (%HR).
A sample program for drawing 288 tiles of 16x16 by _Bmp16 is attached.
The drawing data is set in a matrix.
The execution time including PutDisp_DD is 0.053 seconds.
I heard and knew about the mechanism of DMA transfer in the back process before, but I have not adopted it yet.
I think it will help speed up if use it well.
Drawing in C.Basic is a double buffer like in C.
After writing to VRAM prepared by the system, transfer by PutDisp_DD.
SysCall for drawing uses only PutDisp_DD.
The 16-bit color drawing program uses an original library similar to the monochrome library.
VRAM is secured in the stack area separately from the system VRAM for graphics and text for compatibility with the Basic Casio.
They are 4-byte aligned and can transfer long words.
Overclocking utilitaire Ftune/Ptune2/Ptune3 est également disponible.
Si vous avez des questions ou un rapport de bogue, n'hésitez pas à me le faire savoir.
Citer : Posté le 10/01/2020 08:08 | # |
Fichier joint
Sorry, I misunderstood the meaning of the question.
There is no command that only measures parsing or the actual execution time inside a command.
C.Basic can measure only the execution time for command.
This is a method of measuring the execution time in a C.Basic program.
Use the Ticks command to measure with 1/128 second accuracy.
Use the Ticks% command to measure with 1/32768 seconds accuracy.
(There are some errors)
...
Ticks%/32768 // seconds of execution time
A sample of yesterday's sample rewritten with the above measurement method is attached.
It runs in integer mode and omitt PutDisp_DD.
Execution time: about 0.038 seconds
In the latest updat 1.43beta,
Execution time: about 0.019 seconds.
Overclocking utilitaire Ftune/Ptune2/Ptune3 est également disponible.
Si vous avez des questions ou un rapport de bogue, n'hésitez pas à me le faire savoir.
Citer : Posté le 10/01/2020 08:15 | #
OK nice, I guess than setting Ticks% to 0 at the start of a game cycle and using a simple condition loop would do the job.
Thanks for your answer
Citer : Posté le 10/01/2020 08:37 | #
You are welcome.
I'm glad if you use it well.
(Please note that Ticks% cannot be used with SH3 calculators.)
Overclocking utilitaire Ftune/Ptune2/Ptune3 est également disponible.
Si vous avez des questions ou un rapport de bogue, n'hésitez pas à me le faire savoir.
Citer : Posté le 10/01/2020 09:36 | #
A sample program for drawing 288 tiles of 16x16 by _Bmp16 is attached.
The drawing data is set in a matrix.
The execution time including PutDisp_DD is 0.053 seconds.
This is pretty good! But then why did you have much worse performance before (quoted below)? Is it related to the improvements in version 1.43?
Drawing of 288 tiles (16x16) takes 0.2 seconds.
That is about 5fps.
I think it will help speed up if use it well.
As long as you use Bdisp_PutDisp_DD which uses the DMA (but waits for it to finish), you are in a pretty good situation. The only thing to absolutely not do is transfer by hand.
In this case, it should be fast. 0.053 seconds is not bad at all, I just don't understand why you had 0.2 before.