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 !
@KikooDX : j'ai mis le lien je savais pas qu'il existait
Je compte bien y arriver pour RimWorld, malheursement le jeu est vraiment lent pour le moment… Je vais le continuer, mais si c'est vraiment trop lent, je ne sais pas si je vais le terminer…
"Ce n'est pas parce que les chose sont dures que nous ne les faisons pas, c'est parce que nous ne les faisons pas qu'elles sont dures." Sénèque
Mais te laisse pas démotiver comme ça par un problème de vitesse. x)
Et puis au pire tu overclockes, c'est pas dramatique. Enfin C.Basic doit permettre de faire mieux.
Je suis déjà en C.Basic ^^' et je tourne à environ une image par seconde… m'enfin en même temps, à chaque frame j'ai 288 tiles à mettre à jour… Je continue le projet comme prévu…
"Ce n'est pas parce que les chose sont dures que nous ne les faisons pas, c'est parce que nous ne les faisons pas qu'elles sont dures." Sénèque
Oui oui, tu utilises déjà C.Basic. Mais avec ça tu dois pouvoir te rapprocher plus du niveau d'un add-in que d'un programme Basic sans problème. Genre tes 24x12 tiles qui couvrent l'écran, on peut les dessiner à 20 FPS sans problème dans un add-in, donc tu dois bien pouvoir le faire fluide.
Tu as bien utilisé les fonctions de dessin VRAM pour ensuite afficher au dernier moment ?
@Shadow15510
I'm happy to see the progress of the project.
However, 1fps is too slow.
How large a sprite are you drawing?
Which command are you using?
Can you reduce the number of sprites drawing in the loop?
Is there too much screen transfer as Lephenixnoir says?
Are you using the Cls command? It will cause to be slow.
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.
I must actualize all tiles at each frame… I use _ClearVram, DrawMat with _DisplayVram… I have two possibility, on the one hand, I can put each tile in a matrix, and using a switch in the two for, on the other hand I can put the tile on the tileset in live in one line and juste use two for…
"Ce n'est pas parce que les chose sont dures que nous ne les faisons pas, c'est parce que nous ne les faisons pas qu'elles sont dures." Sénèque
Ok!
As a remedy, DrawMat is slow, so please use the _Bmp/_Bmp8/_Bmp16 command.
They are the fastest bitmap drawing commands that are several times faster.
And drawing 288 tiles every time is inefficient,
Draw only the tiles that have changed, and the other tiles as the background.
If further speeding of the command is possible, I'll try to improve it.
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.
I think layering is a true way of optimization. To make Pokémon Obsidienne, I distinguished the two types of objects : mobile and immobile tiles. All you need is update the mobile tiles, and you put the rest in a whole bitmap file.
"Quand je dis à la cour : "Sautez ! ", tout le monde me demande "jusqu'où ?" " Dijkstra - The Witcher
Lightmare a écrit : I think layering is a true way of optimization. To make Pokémon Obsidienne, I distinguished the two types of objects : mobile and immobile tiles. All you need is update the mobile tiles, and you put the rest in a whole bitmap file.
From my experience in C the main cost of rendering is from writing to VRAM and not the logic of the program. In fact, handling transparency by checking each pixel is not any slower than just copying a fully opaque bitmap because the speed of the RAM cannot keep up with the full-speed writing. C.Basic might not be that fast though.
Sentaro21 a écrit : And drawing 288 tiles every time is inefficient,
Draw only the tiles that have changed, and the other tiles as the background.
This is true, however I believe fluidity can be achieved without going so far. (?)
If I remember well, Shadow want scrolling in his game so Lighmare's solution (a basic of game drawing optimisation) doesn't fit.
Give up scrolling Shadow ?
(Sentaro21 : HS question, is there a way to cap FPS in C.Basic?)
@Lephenixnoir
Even in the case of C.Basic, transparent color processing does not make a big difference.
However, compared to C, the optimization is insufficient, so there is a difference in processing speed, especially in integer mode.
In order to increase FPS, it is necessary to simplify the entire processing itself, including image processing.
@Kikoodx
There are scroll commands.
_Hscroll 16
_Vscroll 16
It can be processed full screen at 30fps speed.
To control FPS, use the following commands in a loop:
TicksWait -8 // 8/128 seconds
This keeps up to about 15 fps in the loop.
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.
I don't scroll… but I use TicksWait -4 to stabilize speed at 32 fps _Bmp 16 works my "game" is a little more fast, but it's still too slow… The DotPut function doesn't fully work : some times, the output matrix is fully black… And DotTrim causes some crash in double for : the program run but nothing append…
"Ce n'est pas parce que les chose sont dures que nous ne les faisons pas, c'est parce que nous ne les faisons pas qu'elles sont dures." Sénèque
Sorry for bugs of DotPut/DotTrim.
These commands are based on the monochrome version, so bugs remain.(some fixed in 1.42beta)
For drawing data and drawing screen,
What kind of processing do you expect?
by the way,
In an experiment using _Bmp16, a drawing-only program,
Drawing of 288 tiles (16x16) takes 0.2 seconds.
That is about 5fps.
Is it possible to reduce the number of tiles to draw per loop?
Or is it possible to set a priority and skip the loop and process it little by little, instead of processing all the tiles at once?
This is a game program ported for C.Basic,
(It may not be helpful ...)
By processing little by little in one loop,It is designed to maintain 50FPS. http://pm.matrix.jp/CB/ALIENCG.zip
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 : by the way,
In an experiment using _Bmp16, a drawing-only program,
Drawing of 288 tiles (16x16) takes 0.2 seconds.
That is about 5fps.
I think this is good already. Due to the amount of data that needs te be copied when using 16-bit mode, you cannot hope to do better than ~40 FPS even in C. Also for this game in particular, I suppose 3-4 FPS might be enough right now?
What do you think is creating this gap between C.Basic and add-ins? I am willing to contribute a bit to enhance the performance of C.Basic in that regard, because I have spent a lot of time doing it in my own code and I think the rewards for all C.Basic users are worth it.
Thanks!
Depending on the content of the game, I think 3~4FPS may be enough.
Also, I don't think it needs to update everything with the same FPS.
I think that the high and low FPS parts can be combined.
I don't think the graphics command itself is much different from C.
However, I think that there will be a big difference compared with C when processing complex formulas and combining multiple commands.
There is a bit of redundancy due to parsing and versatility.
I think the optimization it will speed up a bit.
In addition, I think that the biggest effect of speeding up is that the required screen transfer (PutDisp_DD of SysCall) is a heavy process that determines the rate at 90FPS, so I think that the FPS will rise if this becomes even faster.
Is there a way to make the transfer even faster?
I think it's important how to make each process lighter and simpler, not to mention using integer mode for speeding up in C.Basic.
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.
However, I think that there will be a big difference compared with C when processing complex formulas and combining multiple commands.
There is a bit of redundancy due to parsing and versatility.
Indeed, this is to be expected. Could you maybe measure the cost of parsing and executing a loop similar to a tile renderer that does not actually render the images?
In addition, I think that the biggest effect of speeding up is that the required screen transfer (PutDisp_DD of SysCall) is a heavy process that determines the rate at 90FPS, so I think that the FPS will rise if this becomes even faster.
Sending data to screen takes 11ms, as you have seen. Normally you can just let it be and optimize the rest unless you have a very intensive application. There is no known way of making that faster apart from overclocking. However, if you have enough memory to use 2 VRAMs, then you can let the DMAC send your rendered VRAM to the screen and start rendering the next frame immediately to the other VRAM (triple buffering). Because the DMAC can work in parallel of the CPU, you are free to do whatever you want until the transfer is complete. When used correctly, this technique can bring down the transfer time to virtually zero!
(Technical note: the DMAC will make constant memory accesses during 11 ms. Any memory accesses you make while the transfer is being done will slow down the DMAC by one cycle. So the transfer time will only be 0 if you have 11 ms of work to do that does not involve the memory, or uses different memory areas than common RAM.)
You can use the OS stack to store additional VRAMs. I personally store both of my VRAMs in the system stack!
-
I am able to render full-screen images in ~25ms in an add-in (396x224 = 88k pixels), which compares with the ~200ms that C.Basic needs to render the tiles (288x16x16 = 73k pixels). I am curious about the rendering pipeline. Could you explain to me what happens when you request an image to be rendered? Is the image loaded from a file? If yes, is it cached? How does the copy to VRAM occur? Do you benefit from the possibilty of writing two pixels at once using longwords during the copy?
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.
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 05/01/2020 18:03 | #
Merci Shadow, mais il y a bien un topic (un peu vide certes).
https://www.planet-casio.com/Fr/forums/lecture_sujet.php?id=16073
J'avais oublié de le préciser désolé ^^'
Pour RimWorld, de rien je le rappelle je me suis basé sur les textures de bases pour les deux sprites que je t'ai fait
Citer : Posté le 05/01/2020 19:04 | #
Yah, deux trucs vraiment sympas ! Je vais essayer de tester TBOI...
RimWorld c'est un genre tout nouveau sur Planète Casio ou presque ! Bon courage
Citer : Posté le 05/01/2020 19:59 | #
@KikooDX : j'ai mis le lien je savais pas qu'il existait
Je compte bien y arriver pour RimWorld, malheursement le jeu est vraiment lent pour le moment…
Citer : Posté le 05/01/2020 20:01 | #
Mais te laisse pas démotiver comme ça par un problème de vitesse. x)
Et puis au pire tu overclockes, c'est pas dramatique. Enfin C.Basic doit permettre de faire mieux.
Citer : Posté le 05/01/2020 20:02 | #
Je suis déjà en C.Basic ^^' et je tourne à environ une image par seconde… m'enfin en même temps, à chaque frame j'ai 288 tiles à mettre à jour… Je continue le projet comme prévu…
Citer : Posté le 05/01/2020 20:08 | #
Oui oui, tu utilises déjà C.Basic. Mais avec ça tu dois pouvoir te rapprocher plus du niveau d'un add-in que d'un programme Basic sans problème. Genre tes 24x12 tiles qui couvrent l'écran, on peut les dessiner à 20 FPS sans problème dans un add-in, donc tu dois bien pouvoir le faire fluide.
Tu as bien utilisé les fonctions de dessin VRAM pour ensuite afficher au dernier moment ?
Citer : Posté le 06/01/2020 10:30 | #
@Shadow15510
I'm happy to see the progress of the project.
However, 1fps is too slow.
How large a sprite are you drawing?
Which command are you using?
Can you reduce the number of sprites drawing in the loop?
Is there too much screen transfer as Lephenixnoir says?
Are you using the Cls command? It will cause to be slow.
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 07/01/2020 18:34 | #
I not use Cls
I must actualize all tiles at each frame… I use _ClearVram, DrawMat with _DisplayVram… I have two possibility, on the one hand, I can put each tile in a matrix, and using a switch in the two for, on the other hand I can put the tile on the tileset in live in one line and juste use two for…
Citer : Posté le 08/01/2020 06:27 | #
Ok!
As a remedy, DrawMat is slow, so please use the _Bmp/_Bmp8/_Bmp16 command.
They are the fastest bitmap drawing commands that are several times faster.
And drawing 288 tiles every time is inefficient,
Draw only the tiles that have changed, and the other tiles as the background.
If further speeding of the command is possible, I'll try to improve it.
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 08/01/2020 06:47 | #
I think layering is a true way of optimization. To make Pokémon Obsidienne, I distinguished the two types of objects : mobile and immobile tiles. All you need is update the mobile tiles, and you put the rest in a whole bitmap file.
Dijkstra - The Witcher
Citer : Posté le 08/01/2020 08:24 | #
I think layering is a true way of optimization. To make Pokémon Obsidienne, I distinguished the two types of objects : mobile and immobile tiles. All you need is update the mobile tiles, and you put the rest in a whole bitmap file.
From my experience in C the main cost of rendering is from writing to VRAM and not the logic of the program. In fact, handling transparency by checking each pixel is not any slower than just copying a fully opaque bitmap because the speed of the RAM cannot keep up with the full-speed writing. C.Basic might not be that fast though.
And drawing 288 tiles every time is inefficient,
Draw only the tiles that have changed, and the other tiles as the background.
This is true, however I believe fluidity can be achieved without going so far. (?)
Citer : Posté le 08/01/2020 08:45 | #
If I remember well, Shadow want scrolling in his game so Lighmare's solution (a basic of game drawing optimisation) doesn't fit.
Give up scrolling Shadow ?
(Sentaro21 : HS question, is there a way to cap FPS in C.Basic?)
Citer : Posté le 08/01/2020 11:44 | #
@Lephenixnoir
Even in the case of C.Basic, transparent color processing does not make a big difference.
However, compared to C, the optimization is insufficient, so there is a difference in processing speed, especially in integer mode.
In order to increase FPS, it is necessary to simplify the entire processing itself, including image processing.
@Kikoodx
There are scroll commands.
_Vscroll 16
It can be processed full screen at 30fps speed.
To control FPS, use the following commands in a loop:
This keeps up to about 15 fps in the loop.
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 08/01/2020 12:03 | #
@Kikoodx
There are scroll commands.
_Vscroll 16
It can be processed full screen at 30fps speed.
To control FPS, use the following commands in a loop:
This keeps up to about 15 fps in the loop.
Whaaaat. I should read that doc sometime soon
I was thinking about a fluid FPS system, taking in account the time spent processing and drawing.
Citer : Posté le 08/01/2020 18:15 | #
I don't scroll…
Citer : Posté le 09/01/2020 07:08 | #
Sorry for bugs of DotPut/DotTrim.
These commands are based on the monochrome version, so bugs remain.(some fixed in 1.42beta)
For drawing data and drawing screen,
What kind of processing do you expect?
by the way,
In an experiment using _Bmp16, a drawing-only program,
Drawing of 288 tiles (16x16) takes 0.2 seconds.
That is about 5fps.
Is it possible to reduce the number of tiles to draw per loop?
Or is it possible to set a priority and skip the loop and process it little by little, instead of processing all the tiles at once?
This is a game program ported for C.Basic,
(It may not be helpful ...)
By processing little by little in one loop,It is designed to maintain 50FPS.
http://pm.matrix.jp/CB/ALIENCG.zip
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 09/01/2020 09:34 | #
by the way,
In an experiment using _Bmp16, a drawing-only program,
Drawing of 288 tiles (16x16) takes 0.2 seconds.
That is about 5fps.
I think this is good already. Due to the amount of data that needs te be copied when using 16-bit mode, you cannot hope to do better than ~40 FPS even in C. Also for this game in particular, I suppose 3-4 FPS might be enough right now?
What do you think is creating this gap between C.Basic and add-ins? I am willing to contribute a bit to enhance the performance of C.Basic in that regard, because I have spent a lot of time doing it in my own code and I think the rewards for all C.Basic users are worth it.
Citer : Posté le 09/01/2020 11:24 | #
Thanks!
Depending on the content of the game, I think 3~4FPS may be enough.
Also, I don't think it needs to update everything with the same FPS.
I think that the high and low FPS parts can be combined.
I don't think the graphics command itself is much different from C.
However, I think that there will be a big difference compared with C when processing complex formulas and combining multiple commands.
There is a bit of redundancy due to parsing and versatility.
I think the optimization it will speed up a bit.
In addition, I think that the biggest effect of speeding up is that the required screen transfer (PutDisp_DD of SysCall) is a heavy process that determines the rate at 90FPS, so I think that the FPS will rise if this becomes even faster.
Is there a way to make the transfer even faster?
I think it's important how to make each process lighter and simpler, not to mention using integer mode for speeding up in C.Basic.
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 09/01/2020 11:48 | #
There is a bit of redundancy due to parsing and versatility.
Indeed, this is to be expected. Could you maybe measure the cost of parsing and executing a loop similar to a tile renderer that does not actually render the images?
Sending data to screen takes 11ms, as you have seen. Normally you can just let it be and optimize the rest unless you have a very intensive application. There is no known way of making that faster apart from overclocking. However, if you have enough memory to use 2 VRAMs, then you can let the DMAC send your rendered VRAM to the screen and start rendering the next frame immediately to the other VRAM (triple buffering). Because the DMAC can work in parallel of the CPU, you are free to do whatever you want until the transfer is complete. When used correctly, this technique can bring down the transfer time to virtually zero!
(Technical note: the DMAC will make constant memory accesses during 11 ms. Any memory accesses you make while the transfer is being done will slow down the DMAC by one cycle. So the transfer time will only be 0 if you have 11 ms of work to do that does not involve the memory, or uses different memory areas than common RAM.)
You can use the OS stack to store additional VRAMs. I personally store both of my VRAMs in the system stack!
-
I am able to render full-screen images in ~25ms in an add-in (396x224 = 88k pixels), which compares with the ~200ms that C.Basic needs to render the tiles (288x16x16 = 73k pixels). I am curious about the rendering pipeline. Could you explain to me what happens when you request an image to be rendered? Is the image loaded from a file? If yes, is it cached? How does the copy to VRAM occur? Do you benefit from the possibilty of writing two pixels at once using longwords during the copy?
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.