Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » TLT : RPG magique (et un moteur de jeu/rendu expérimental, Azur)
Lephenixnoir En ligne Administrateur Points: 22590 Défis: 149 Message

TLT : RPG magique (et un moteur de jeu/rendu expérimental, Azur)

Posté le 29/06/2021 19:06

Ça fait (très) longtemps que je veux faire un bon RPG temps-réel avec un accent sur la notion de magie, et l'univers (que je développe au papier et dans ma tête par petits bouts depuis quelques années) a donné le nom «TLT» ; c'est juste un acronyme, mais c'est presque devenu coutumier de ne pas donner le nom complet, alors je m'y tiens pour l'instant.

Synopsis

Le cœur du concept c'est la notion de magie de l'univers. Toute l'histoire se passe dans un monde où la magie est un élément naturel et dont l'existence est bien connue, mais qui est très niche parce qu'on n'en connaît pas les principes et que peu de gens arrivent à s'en servir pour faire peu de choses. Vous pouvez imaginer une époque type Renaissance, pas encore d'industrie à proprement parler, mais plus raffinée et intellectuellement développée que du médiéval.

Lorsque des éléments systématiques sur le fonctionnement de la magie sont découverts, élargissant à la fois ses applications et son public, la société se reforme autour de cette science et technologie, et soudain tous les enjeux se mettent à tourner autour : le génie civil, l'armement, les relations politiques et internationales ; mais aussi la gestion de l'énergie, l'automatisation, et l'industrie, qui se créent du fait des nouveaux moyens disponibles.

TLT raconte le début de cette histoire, de la période où la magie est découverte jusqu'aux premiers conflits internationaux majeurs. Parce que sans surprise, c'est l'armement qui profite de la nouvelle technologie en premier, qu'on l'ait voulu ou non.

Théorie magique

La pièce de voûte de tout l'univers donc c'est cette magie. Le but ici c'est bien d'avoir un système de magie «dur», où le pourquoi du comment de chaque usage de la magie est expliqué. Pour résumer la vidéo en une phrase, moins on explique un système de magie (eg. le seigneur des anneaux) moins il est légitime/raisonnable de faire reposer des enjeux importants dessus, sinon on trahit les attentes et connaissances des spectateurs/joueurs. Et donc là je compte bien tout expliquer.

Pour vous donner une idée des grands principes, la magie c'est similaire au calcul mental. Tous les êtres conscients peuvent l'utiliser modulo explications et entraînement. Tout comme on peut retenir et combiner des nombres mentalement quand on fait du calcul, on peut conserver et combiner de l'énergie quand on fait de la magie. Et tout comme on peut écrire, dire, ou mettre en œuvre de diverses façons les résultats des calculs dans le monde physique, on peut aussi manifester l'énergie manipulée de différentes façon dans le monde physique.

J'agite les mains pour expliquer où exactement est l'énergie quand on «calcule» et comment la conversion avec les énergies du monde physique se font (si quelqu'un connaît un modèle compatible avec la physique moderne je prends). Mais une fois que cette partie est admise on peut rentrer dans le cœur du sujet.

Dans ce monde qui vient de découvrir la magie, l'enjeu majeur consiste à la systématiser (rendre son comportement reproductible avec le plus de fidélité possible) puis à la passer à l'échelle (construire des systèmes magiques de plus en plus complexes). Comme c'est un humain qui «calcule» chaque sort, il y a besoin de techniques pour rendre le procédé aussi simple que possible ; simplification des règles de «calcul», représentations visuelles, etc.

La version actuelle de la théorie (la plus prometteuse pour l'instant) consiste en une seule primitive de «calcul» qui déplace de l'énergie selon une règle aussi simple que possible. La primitive s'appelle un limiteur asymétrique (le nom est compliqué à cause de la longue lignée d'objets l'ayant précédé) et ressemble à ça.


L'énergie attend dans les entrées en haut. Lorsque c>0, le limiteur peut être activé, auquel cas l'énergie traverse du haut vers le bas. La valeur c est le «contrôle» du limiteur, il indique quelle quantité d'énergie est autorisée à traverser. L'entrée est i₁+i₂, et du coup la sortie c'est min(c, i₁+i₂). Toute l'énergie qui n'est pas autorisée à traverser est rejetée sur le côté. L'énergie du contrôle ressort telle quelle, d'où le trait direct qui traverse sur le dessin.

C'est pas hyper simple, mais quand on sait qu'avec juste une combinaison de ces limiteurs on peut construire une partie de l'arithmétique, de la logique booléenne, du stockage/des mémoires, des horloges et des systèmes synchrones, sans même supposer que les limiteurs sont activés en même temps ou à intervalles réguliers, je dirai que c'est pas mal.

J'ai pas mal de résultats très prometteurs sur cette théorie, mais comme je ne me fais pas confiance pour prouver des sorts complexes au papier je prépare un simulateur pour valider mes résultats !

Gameplay

Le gameplay doit servir l'histoire et l'expérience du protagoniste, qui ne sont pas entièrement définis, donc les mécaniques sont vraiment pas fixées ; mais voilà des idées.

Magie. Le but majeur du jeu (et le point le plus dur) c'est d'intégrer une notion de magie toute théorisée dans un RPG. Je voudrais que le joueur puisse découvrir et apprendre à utiliser le système de magie en même temps que le protagoniste, et concevoir des sorts au cours du jeu.

Bien sûr il n'est pas question de faire assembler des limiteurs asymétriques (ce serait horrible ), mais de présenter une version plus haut niveau de la chose. Un peu comme si je présentais Scratch au joueur après avoir inventé le transistor, si vous voulez.

Cette partie se clarifiera sans doute quand j'aurai atteint des aspects vraiment haut niveau du système de magie ; pour l'instant j'ai surtout travaillé sur le partie abstraite («calcul») et pas encore sur les interactions avec le monde physique, donc ça reste indéterminé. Mais il y a plusieurs options permettant au joueur de s'investir au niveau qui lui convient, donc je suis assez confiant que ce sera intéressant à jouer.

Combat. L'histoire impose pas mal de combat, et ça colle pas mal au style du Action-RPG aussi, donc ce sera probablement la mécanique principale pour accompagner la magie. J'aimerais être économe en mécaniques pour ne pas m'éparpiller, donc je pense que les statistiques et techniques de combat seront limitées aux équipements portés et à un arbre de compétences, sans système de niveau/XP (les points de compétences étant distribués au cours du scénario).

Initialement je voulais faire reposer l'intégralité du système de combat sur la magie, mais il est trop compliqué de formaliser de façon convaincante dans un sort (qui n'est qu'un diagramme) toutes les directions physiques («vers l'arrière»), ou les formes (sphère, cylindre), ou les timings. Du coup, je m'appuie à la place sur les entrées du joueur ou les compétences de combat physique (une liste fixe) pour exprimer ces notions, ce qui me donne un mélange de combat physique et de magie.

Environnement. J'aimerais pouvoir utiliser la magie pour autre chose que le combat, parce que l'univers s'en sert aussi dans plein d'autres situations (rien que le génie civil par exemple), mais je ne sais pas si j'arriverai à trouver des tâches/actions raisonnables pour réaliser ça.

Scénario. Le jeu sera probablement assez linéaire pour coller à l'histoire (genre Half-Life premier du nom), ce qui me permet aussi de définir assez peu de lieux et de me concentrer sur les mécaniques.

Aspects techniques et plan

Récemment j'ai infiltré KikooDX et Masséna (ils disent qu'ils m'ont «pris en stage» mais j'aurai le dernier mot !) pour avoir tous les protips de développement de jeux vidéos, vu que mon domaine c'est plutôt le genre gint et que les méthodes sont vraiment pas les mêmes. x)

J'ai vraiment pas les réflexes qu'il faut pour aller vite mais je m'accroche, vous verrez apparaître rapidement un petit jeu de combat marrant (co-op avec Masséna) si j'arrive à me concentrer dessus.

Ce que j'ai concrètement, en ignorant les idées :
  • Des documents décrivant la théorie des limiteurs asymétriques ;
  • Des notes sur l'univers avec en particulier un chapitre de narration qui raconte la fin de TLT (qui est plus le début de l'histoire principale de l'univers) ;
  • Un moteur de rendu (... dans le futur, de jeu, mais pour l'instant de rendu) qui supporte SDL sur PC, SDL/emscripten dans le navigateur, et gint sur Graph 90+E avec des méthodes pétées. Des détails arriveront plus tard.
  • Et le début d'un simulateur pour valider les résultats théoriques.

Programmer les grandes lignes du jeu (map, combat, physique, etc) n'est pas particulièrement difficile, mais comme les détails de la magie auront beaucoup d'influence dessus je me précipite pas.

Voilà voilà, maintenant que j'ai un topic je posterai des update sur tout ce qui tourne autour de ce jeu, vu que j'ai toujours un pied dans un des aspects.

@RDP avant que j'oublie.

Fichier joint


Shadow15510 Hors ligne Administrateur Points: 5401 Défis: 16 Message

Citer : Posté le 26/08/2021 23:28 | #


Aow, une sorte de OpenGL façon Casio du coup ?
"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

Lephenixnoir En ligne Administrateur Points: 22590 Défis: 149 Message

Citer : Posté le 26/08/2021 23:30 | #


Dans le code interne un peu oui. Mais bon pour l'utilisateur c'est comme l'API gint (azrp_clear(), azrp_subimage(), etc) et pour le développeur c'est beaucoup d'optimisation de code assembleur, ce qui est je suppose le plus proche qu'on puisse trouver d'un GPU sur la plateforme
Shadow15510 Hors ligne Administrateur Points: 5401 Défis: 16 Message

Citer : Posté le 26/08/2021 23:31 | #


Ok ok, ben bon courage xD
"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

Lephenixnoir En ligne Administrateur Points: 22590 Défis: 149 Message

Citer : Posté le 24/09/2021 23:06 | #


Je pense que ce topic mérite une update rapide même s'il y a surtout des changements en coulisses et rien de flashy...

J'ai continué mon architecture de rendu pétée en ajoutant progressivement les formats d'image. Au post précédent j'avais seulement une version 16-bit (RGB565) ; depuis j'ai implémenté le 16-bit avec transparence (RGB565A) et deux variantes de l'indexé 8 bits (P8_RGB565 et P8_RGB565A). Le format P8 en lui-même était trop lent donc j'ai décidé de l'optimiser et le décliner, et les résultats sont au rendez-vous.

Pour information, le temps asymptotique nécessaire pour chaque pixel est de :
  • RGB565 : 1 cycle/pixel ou 2 cycles/pixel (selon si l'alignement est favorable)
  • RGB565A : 4 cycles/pixel (j'ai tenté pas mal de version à 3, en vain)
  • P8_RGB565 : 3 cycles/pixel
  • P8_RGB565A : 4.5 cycles/pixel

Ça ne se voit pas d'ici, mais c'est de l'assembleur de qualité et je suis assez fier de toutes les petites techniques utilisées pour gratter tous les bouts que je peux (que je détaillerai dans le topic d'optimisation quand j'en serai à l'assembleur). Ces optis ne sont pas que pour TLT puisque c'est implementé dans le moteur de rendu, qui sera clairement réutilisable s'il y en a qui se sentent tentés.

J'ai aussi progressé sur le simulateur de magie, plutôt sur le côté flashy cette fois (pas encore trop sur la mécanique de la simulation), je garde ça pour un prochain post
Lephenixnoir En ligne Administrateur Points: 22590 Défis: 149 Message

Citer : Posté le 24/03/2022 13:37 | # | Fichier joint


Salut, je reviens sur ce sujet, qui est indirectement mon sujet de référence pour Azur, le moteur de jeu de TLT qui contient entre autres mes expérimentations avec l'affichage super rapide.

Dans le cadre du plan d'extension du traitement d'images pour gint 2.8, je vais me défaire du code de rendu actuel de bopti pour récupérer celui d'Azur, qui est bien plus élégant et optimisé. Je viens de passer un peu de temps à quantifier à quel point exactement.

Je ferais bien une visualisation un peu détaillée, mais je n'ai pas trop le temps dans l'immédiat, donc je joins le fichier de données et je fais un résumé ci-dessous. Notez que c'est Azur vers la XRAM que je teste là, pas vers la VRAM, donc ce n'est pas encore représentatif de ce que gint 2.8 apportera comme accélération à dimage().

J'ai testé quatre scènes essentiellement :
  • img_tree est une collection de sous-images d'une image 32x35 (petite donc)
  • img_rogue contient trois rendus d'un screen de Rogue Life de 376x57 (très horizontal)
  • img_tileset répète 7 fois une image verticale de 48x208
  • img_war c'est du full color immense, 350x193, affichée une seule fois

Dans l'ensemble, Azur (avec le rendu fragmenté en XRAM) va plus vite, ce qui n'est pas une surprise. Le truc étonnant, c'est que sur les 30 combinaisons de scène/format Azur est plus lent sur 3, avec le plus gros écart étant img_tree en P8 avec transparence.

engine="bopti/RAM" format="P8_RGB565A" scene="img_tree" time=1265
engine="azur/XRAM" format="P8_RGB565A" scene="img_tree" time=1829 cmdgen=96 sort=249 shaders=1484

Je pense qu'il y a quelque chose qui m'échappe dans les interactions entres les sauts et le reste du code. Tel que je le vois, bopti prend 8 cycles CPU par pixel transparent alors qu'Azur devrait prendre 4.5 cycles par pixel au plus. Un peu de debuggage en vue donc, je pense !

Sur les 27 autres, Azur va plus vite et parfois de très loin. Ici on passe de 9 ms à 5.8 ms :

engine="bopti/RAM" format="P4_RGB565A" scene="img_rogue" time=9021
engine="azur/XRAM" format="P4_RGB565A" scene="img_rogue" time=5823 cmdgen=52 sort=140 shaders=5631

Le plus violent est une accélération de 2.73x, sur la même scène toujours en P4 mais sans la transparence :

engine="bopti/RAM" format="P4_RGB565" scene="img_rogue" time=9101
engine="azur/XRAM" format="P4_RGB565" scene="img_rogue" time=3330 cmdgen=55 sort=145 shaders=3130

Il y a un certain nombre de résultats que je ne comprends pas, surtout avec img_tree (ce qui est con parce que beaucoup d'add-ins font du rendu de cette façon, avec plein de petites sous-images) donc je vais régler ça avant de continuer.

Quand ce sera un peu prêt je testerai avec Azur dans la VRAM (ce qui sera intégré à gint 2.8) et je vous ferai des graphiques plus jolis.
Kikoodx Hors ligne Labélisateur Points: 2979 Défis: 11 Message

Citer : Posté le 24/03/2022 14:12 | #


Cool de voir du progrès ! Est-ce que le nouveau système de rendu permettrait de faire de l'upscaling natif (dont tu avais discuté la théorie sur la shout il y a un bail), ie. dessiner sur une VRAM de 198x112 et obtenir du 396x224 à l'écran ?
mi lape ala.

J'suis un méga chômeur
Lephenixnoir En ligne Administrateur Points: 22590 Défis: 149 Message

Citer : Posté le 24/03/2022 14:34 | #


Le système de rendu d'Azur (XRAM etc), oui. J'ai prévu un upscale x2 et x3, et les perfs devraient s'améliorer à peu près en proportion (ie. on ne va pas matérialiser l'image x2 ou x3 en RAM avant d'envoyer avec le DMA). Mais le système de rendu natif de gint (2.8 ou pas) ne peut pas faire ça pour l'instant. C'est pas que c'est impossible techniquement, mais pour que les perfs tiennent il faut upscale à l'envoi, donc envoyer avec le CPU, et pour l'instant les envoies RAM → écran avec le CPU sont super lents (envoi normal : 25 ms, contre 11 ms avec le DMA). Si ça se débloque dans le futur, alors ce sera sans doute possible avec le système natif à VRAM aussi.

Ajouté le 24/03/2022 à 23:35 :
Update rapide : aujourd'hui j'ai commencé à passer mon code d'Azur au crible de la mesure au cycle près (qui est implémentée dans gintctl). J'ai commencé avec le premier format non trivial, à savoir P8_RGB565.

gintctl m'a révélé que la boucle centrale de P8_RGB565 faisait 7 cycles au lieu de 6, contredisant mon calcul.

Le premier truc fun, c'est que mon calcul était correct mais que l'exécution déraillait d'une façon ou d'une autre et que la bonne solution pour obtenir les 6 cycles désirés c'est d'ajouter un nop. Oui, rajouter une instruction qui ne fait rien peut rendre le programme plus rapide. Vous vous attendiez à quoi, du bon sens ? Pff, amateurs.

Le second truc fun, c'est que malgré un impact très précisément mesurable dans gintctl, j'ai très précisément mesuré l'absence d'impact dans mon add-in de benchmark avec exactement zéro accélération sur l'affichage des images. C'est le bon moment pour préciser que dans la scène que j'affiche il y a 10220 pixels soit 260 µs de boucle critique (à 118 MHz), et même si on compte l'overhead c'est pas normal que le truc complet prenne 1270 µs. Conclusion il y a certainement un bottleneck ailleurs, et donc je vais chasser ça.

Désolé si ça avance pas vite pour gint 2.8, mais on peut pas faire des jeux qui passent littéralement plus de 85% de leur temps à faire du rendu et ne pas aller chercher ces speedups. Enfin si on peut, mais pas moi. Bref, on se retrouve demain pour de nouvelles folies.

Ajouté le 25/03/2022 à 11:03 :
Conclusion il y a certainement un bottleneck ailleurs, et donc je vais chasser ça.

En fait je suis un peu stupide, ça sautait aux yeux dans les données. Remarquez que P4 est plus rapide que P8 :

engine="azur/XRAM" format="P8_RGB565" scene="img_war odd" time=8451 cmdgen=52 sort=181 shaders=8218
engine="azur/XRAM" format="P4_RGB565" scene="img_war odd" time=4877 cmdgen=53 sort=181 shaders=4643

Pourtant la fonction de rendu en P4 est plus complexe, alors que se passe-t-il ?

La réponse, c'est les accès à l'image sont lents. Les images sont dans l'add-in, en ROM ou en RAM, et aller les lire est long. Le bottleneck est là : il ne suffit pas de traiter les données vite et de les écrire vite, il faut aussi les lire vite. P4 est plus rapide parce que le format est 2 fois plus compact, donc il y a 2 fois moins de données à lire. Le fait que ça aille presque 2 fois plus vite fait donc un peu peur, puisque ça montre à quel point ce bottleneck est limitant !

J'y avais pensé à plusieurs occasions mais c'est un problème sans solution parfaite puisqu'on a 5-10 kio de mémoire rapide disponible avec Azur et souvent beaucoup, beaucoup plus de données graphiques. Ce n'est pas inutile pour autant ; par exemple, les tilesets de Rogue Life font 2-3 kio donc on pourrait les mettre en mémoire rapide et voir les FPS bien grimper.

Je vais étudier aujourd'hui (sans doute sur quelques jours en réalité) quelles options on a pour maximiser la vitesse de lecture parmi les mémoires assez grandes qu'on a ; par exemple, s'il y a des différences entre la ROM et la RAM, avec ou sans le MMU, avec ou sans prefetching...

Cela explique aussi pourquoi les images gagnent moins que tout ce qui est purement génératif/calculatoire. azrp_clear() avec Azur prend 400 µs, soit 6 fois moins que dclear() version DMA et 15 fois moins que dclear() version CPU (!). Ça montre bien que dès qu'on n'est plus limités par la vitesse de lecture, la force de l'assembleur optimisé et la vitesse de la XRAM s'expriment, et on peut gagner beaucoup - bonjour effets calculatoires/couleurs/saturation/lumière etc.
Slyvtt Hors ligne Community Manager Points: 832 Défis: 0 Message

Citer : Posté le 25/03/2022 11:25 | #


Du coup est-ce que tu pourrais gagner du temps sur un "dclear" partiel (entre ligne 0 et ligne Y) et sur une primitive de type dhline qui sont purement calculatoires ?
Lephenixnoir En ligne Administrateur Points: 22590 Défis: 149 Message

Citer : Posté le 25/03/2022 11:36 | #


Oui et oui. Un dclear() partiel c'est vraiment pareil qu'un dclear() mais avec moins de mémoire à remplir. On notera quand même qu'Azur est avantagé sur ce point, parce que la méthode utilisée par gint (avec le DMA) est obligée de remplir des lignes entières. Pour n'effacer qu'un rectangle il faut utiliser le CPU et l'écart commence à sérieusement grandir (speedup x15 pour Azur).

Edit : Si tu as ça pour OutRun tu peux déjà le remplacer par un dma_memset() plus petit et gagner une proportion correspondante des 2.5 ms nécessaires pour effacer tout l'écran.

Pour dhline(), et même n'importe quelle ligne, là aussi on va gagner. Le temps de calcul en lui-même n'aura sans doute pas beaucoup d'impact (surtout sur dhline() vu qu'il n'y a aucun calcul !), par contre Azur va gagner parce qu'écrire dans la XRAM va plus vite qu'écrire dans la RAM. Et encore dhline() est assez gentil pour gint parce que c'est un mode d'accès qui est favorable pour le cache. Si on remplissait l'écran à coup de dvline() ça se ferait encore plus sentir.

Je suis plus sûr des chiffres parce que c'est de mémoire, mais actuellement pour assombrir tout l'écran (avec l'approximation c = (c & 0xf7de) >> 1 pour chaque pixel, fait sur 2 pixels d'un coup) c'est infaisable dans la VRAM, ça prend genre 20-30 ms, alors qu'avec Azur ça se joue si ma mémoire est bonne à 2 ms.

Ultimement, il est correct de dire que pour les images bopti approche déjà le bottleneck donc il n'y a pas énormément à gagner, et le modèle mémoire inhabituel d'Azur gagne donc plutôt ailleurs. Ça m'arrange pour TLT, mais ça limite les gains qu'on peut espérer pour gint 2.8. Dans tous les cas, je vais récupérer toutes les perfs que je peux sur les images et on verra ensuite comment les add-ins peuvent exploiter ça.
Slyvtt Hors ligne Community Manager Points: 832 Défis: 0 Message

Citer : Posté le 25/03/2022 12:39 | #


Oui pour le dma_memset "réduit", je fais ça déjà, je gagne 1/3 de l'écran grosso-modo.
Lephenixnoir En ligne Administrateur Points: 22590 Défis: 149 Message

Citer : Posté le 31/03/2022 22:55 | #


Bon, j'ai des nouvelles. En gros en ce moment j'essaie de traquer les perfs - de comprendre comment les cycles de dessin dans la procédure optimisée d'Azur se multiplient en µs, et comment les µs se multiplient en dizaines, centaines et en ms dans la logique du programme.

Il va sans dire que... c'est compliqué. Par exemple :

  • La XRAM et la YRAM sont des zones mémoire très rapides de 8 ko chacune, qui peuvent répondre au processeur en 1 cycle. Je m'en sers beaucoup dans Azur. Mais elles sont en fait séparées en deux pages de 4 ko chacune, et il y a un délai chaque fois qu'on change de page ; je n'ai pas encore mesuré mais je crois que ça répond alors en 2 cycles. Dans un de mes tests, j'ai par hasard chargé une image à cheval sur les deux moitiés de la YRAM, de sorte que la lecture de la palette était sur la première page et la lecture des pixels sur la deuxième. Les deux n'arrêtent pas d'alterner durant le dessin : résultat, je passe de 1290 µs à 1760 µs - 36% d'écart.
  • La RAM a un cache de données, très pratique, qui fait 32 kio et permet d'accéder en un cycle (!) aux données récemment utilisées. S'il est bien utilisé, le cache est aussi performant que la XRAM en écriture (hors conflit de page) ; 118 millions d'accès par seconde (puisque 118 MHz le CPU), soit environ 450 Mo/s en lisant des longs. Mais en écriture, il ne semble rien faire (même en mode write-back) : la vitesse est limitée à 29 Mo/s alors que la XRAM monte à 450 Mo/s. C'est pour ça qu'Azur démonte tout sur dclear(). Mais comme le cache est parfait en lecture ça signifie qu'une RAM bien gérée pourra tout à fait servir pour stocker des images (ce qui est cool parce que la XRAM/YRAM c'est serré !).

Il faut donc faire attention à plein de petits détails pour comprendre exactement ce qui se passe. Je ne dis pas qu'il faudra faire ça pour avoir un jeu qui tourne bien, mais j'ai besoin de passer par là pour savoir comment programmer la choucroute.

Je vais prendre le temps de tout bien noter sur la bible et plus tard le topic d'optimisation.

En tous cas, le travail fait sur Azur sera bénéfique dans l'ensemble c'est sûr ; mais j'ai un peu peut qu'on soit limités par la vitesse de la VRAM (comme je l'ai mentionné "RAM en écriture = torture"). C'est pour ça que je passe un peu de temps au passage sur Azur : si la VRAM n'est pas sauvable y'aura toujours moyen de changer de moteur...

Ajouté le 02/04/2022 à 12:30 :
J'ai mis à jour la bible avec quelques infos en plus :


LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2022 | Il y a 72 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