La Revue des Projets – 213
Posté le 11/07/2021 22:23
Bonsoir à toutes et à tous ! Ce soir, pas de résultat pour la 1KBCJ#5 mais votre traditionnelle, régulière et ponctuelle Revue des Projets. Comment ça, le dernier numéro date d'avant-hier ? Bref, ce soir nous allons brièvement parler du projet de RPG entamé depuis belle lurette par Lephenixnoir, j'ai nommé TLT.
Derrière l'acronyme énigmatique de
TLT se cache le projet ambitieux d'un RPG en temps réel jouable sur calculatrices et ordinateurs. À la base de ce jeu se trouve la
magie, un élément important régit par des règles complexes mais puissantes.
Lephenixnoir nous concocte donc toute une "physique" de la magie, modulable et logique, et donc explicite (e.g les phénomènes magiques et l'utilisation de cette énergies sont justifiées et explicables).
Le jeu se déroulera dans un monde proche de la Renaissance, en plein essor magique.
Aujourd'hui,
Lephenixnoir nous parle un peu plus de son projet. Tout d'abord, il continue à travailler sur sa théorie magique et a développe une application pour vérifier ses théorèmes. Encore très rudimentaire, elle a été développé avec OpenGL et
Dear ImGui.
Lephenixnoir nous éclaire sur la nature de ce bien étrange schéma :
Lephenixnoir a écrit :
Ici les deux limiteurs sont du stockage d'énergie (à cause de la boucle entre la sortie de rejet et une des entrées, qui empêche l'énergie de sortir sauf exactement ce qui est demandé), et ils sont liés d'une façon que si on active le limiteur de gauche on a un transfert gauche→droite et si on active le limiteur de droite on a un transfert en sens inverse (en supposant qu'il y a de l'énergie dans le circuit au début).
Plus récemment, ce mage noir des calculatrices nous annonce ni plus ni moins que le moteur de jeu tournera à
60 fps (images par secondes), contrairement aux jeux actuels (ne tombez pas dans le piège de la
publicité mensongère de KikooDX). En effet, la fonction
dupdate() utilise actuellement le DMA, suffisant pour attendre 30 fps mais pas vraiment plus.
Lephenixnoir nous propose alors d'utiliser alternativement la XRAM, une mémoire de 8192 octets contenue dans le CPU, permettant un accès beaucoup, beaucoup plus rapide (de 10 à 20 fois plus rapide !). Ainsi, il serait possible de stocker les données d'affichage (VRAM) dans la XRAM afin de gagner en temps d'accès et donc en fluidité... L'inconvénient majeur étant que l'écran nécessite 177 kio de données.
La question sera donc maintenant de savoir comment stocker ces 177 kio dans les minuscules 8192 octets de la XRAM... À suivre...
Bonne chance à toi Lephe' !
On se retrouve la semaine prochaine pour une prochaine RdP ainsi que les résultats de la 1KBCJ#5. Bonne soirée à toutes et à tous !
Depuis la dernière RdP, 2 programmes ont été postés :
grosse carte de
Superkd, un Proof-of-Concept de compression de données dans des matrices addressés aux experts en Basic Casio.
AMONG US de
Endium999, qui aurait mieux fait de s'appeller directement "AMOGUS"
Lire la RdP précédente :
La Revue des Projets – 212
Besoin d'aide ? Une idée ? Un projet ? Un article !
Citer : Posté le 11/07/2021 22:31 | #
Merci pour cette revue ! J'ai comme l'impression que la dernière était il y a peu de temps
Je ne vais pas mentir, je ne comprends pas beaucoup ce schéma. Mais en même temps c'est compliqué d'imaginer cette mécanique complexe sans y mettre les mains directement !
La XRAM semble très intéressante, je suis persuadé que tu vas réussir à faire de la magie noire avec ! Bon courage
(Et de toute façon, vous pouvez pas dire le contraire)
MultipliCasio
RDM Calculs
Back Mirror
A Switch To The Top C
Citer : Posté le 12/07/2021 08:41 | #
Voilà une petite explication pour les curieux.
Si on prend un AL (limiteur asymétrique) tout seul, comme ceci :
alors on a trois entrées contenant de l'énergie (c, i_1, i_2) et le comportement est : « quand c>0 et que j'active l'AL, une énergie de i_1+i_2 traverse l'AL pour atteindre la sortie u dans une limite de c, et le reste est rejeté dans r ». (La sortie de rejet a un petit rond pour l'identifier.)
La partie importante dans le diagramme de la RDP c'est que la sortie de rejet est connectée à une des entrées. Ça veut dire que quand on active l'AL, de l'énergie peut sortir par u dans la limite de c, et le reste est rejeté... et renvoyé dans l'AL. C'est comme si le reste n'était jamais sorti.
Ce mécanisme fait de l'AL un réservoir d'énergie, où chaque fois qu'on envoie de l'énergie dans i_1 elle est ajoutée au stockage et chaque fois qu'on active l'AL avec un contrôle c on retire de l'énergie dans la limite de c (s'il y en a moins, on retire tout).
Et ensuite pour obtenir le diagramme de la RDP, c'est assez facile : on branche la sortie de l'un sur l'entrée de l'autre, ce qui donne deux réservoirs d'énergie qui se déversent l'un dans l'autre chaque fois qu'on active un des deux contrôles.
Citer : Posté le 12/07/2021 09:43 | #
Merci beaucoup pour ces explications claires !
J'ai mieux compris que sur le topic pour être honnête ^^'
Citer : Posté le 12/07/2021 12:00 | #
ça ressemble beaucoup à des transistors en soi
Citer : Posté le 12/07/2021 12:03 | #
Oui, il y a une bonne ressemblance. Une différence c'est qu'on spécifie via le contrôle combien d'énergie on veut. Contrairement par exemple à un circuit électronique qui «tire» du courant, ici on matérialise la quantité d'énergie à transférer et on la «pousse» par l'entrée de contrôle. Ça peut paraître négligeable comme détail mais ça simplifie beaucoup les histoires de dépendances/propagations dans les cycles, qui étaient un sacré casse-tête quand je cherchais des modèles