Nouveautés :
A faire :
On en est à remplir le niveau d’objets divers.
Tadaaa grande nouveauté, GRAK gère un système de langue.
2 fichiers : le fichier pour grak concernant les erreurs (logs) et un autre fichier propre à l’application développée.
Il est impératif qu’une ligne option>langage se trouve dans le setup.conf, si les fichiers existent pas tampis.
Il suffira donc que qqun decide de traduire les fichiers (mode xml) et en avant la musique
2ème nouveauté : le calcul du FPS par la boucle d’Action principale. On affichait du 200-250 fps avec le premier monde de Liebestein 🙂
Editeur de Liebesstein : suite 🙂
De plus j’ai amélioré la fenêtre de plugins pour qu’elle s’adapte à une taille idéale (donnée par le plugins en dur)
Le système de texture n’a été fait qu’en partie (liste XML des fichiers à chargé) ne pouvant pas encore définir le fonctionnement générale. Nous avions parlé d’un CR de chargement générale et pour le moment c’est l’Editeur qui charge les textures. CR à mettre en place donc.
Nous nous rappellerons (pour les bon vieux fans) le moteur Y (2002 – histoire de Nahyan). La salle (en capture), sauf le renfoncement, est un clin d’oeil à la salle de test de ce moteur. Une forme en L. Mais à l’époque par face murale il y avait 2 triangle et pas 2 x bloc, comme notre système actuel.
Captures :
Premier souffle de l’éditeur 🙂
Captures :
Les ETI ça n’a pas marché, les problèmes rencontrés et l’utilisation de ces effets là ne justifient pas de passer + de temps sur le sujet (en tout cas actuellement).
On avisera directement des effets HLSL. J’ai déjà une idée de multi-rendu-texture pour appliquer plusieurs effet independant sur le resultat final. Nous verrons ça plus tard donc.
Dans l’immediat on va se concentrer sur l’Editeur de Liebesstein.
1er ETI le fondu au noir, et ben non ça ne vas pas :
Sinon les effets s’empilent bien, s’exécutent bien aussi… c’est déjà ça.
Pour vous montrer ça je cherche un moyen de créer une vidéo directement par GRAK.
ETI : Effet(s) par Traitement d’Image(s)
Une nouvelle idée, et oui encore 🙂 découvrons-la
Actuellement chaque CR fait son rendu, si on veut quelque chose de special, chaque CR doit contenir le code. Dans notre idée de généraliser/centraliser grâce à GRAK et LibK j’ai eu une idée concernant les effets visuels.
Par exemple faire un fondu au noir, au blanc, en noir et blanc, ce genre d’effet mono image
Mais vu qu’on généralise on pourrait imaginer un fondu enchainé entre 2 CR, etc…
Comment ?
Un CR fait un rendu texture, donc pas directement à l’écran mais dans une texture en mémoire, on envoie celle-ci à GRAK en lui donnant un ID (0 = premier plan classique)
Le CR precise le ou les effets à appliquer successivement. Les effets se baseront sur une durée de vie ou une condition de fin et iront chercher la/les texture(s) à utiliser.
Dans le cas d’un fondu au noir, on prend la texture en 0 et on modifie l’image directement.
Dans le cas d’un fondu enchainé, le CR qui se termine se place en , le CR qui prend la main (ne sachant pas quel effet est là avant lui) ira betement se taper en 0 et GRAK au passage verra qu’un effet est a appliquer et fera ce qu’il faut.
Dans le cas du fondu enchainé, d’autre technique diverse existent.
Les ETI sont lourd en calcul car pur traitement d’image
Plus tard on pourra p-e imaginer, remplacer ou combiner les ETI avec les effets HLSL, mais on y est pas encore. D’abord faire du lourd, pur, compatible sur toutes les cartes graphique, puis du + beau 🙂 performant high-tech qui pète 🙂
Résultats :
J’ai adpaté GRAK à cette structure et ai permis le fait de ne pas utiliser les ETI, si on desire faire des rendu simple ou autre, les ETI sont optionnel.
Actuellement seul l’éditeur de niveau qui utilisait déjà un rendu texture, passe par un ETI null (le fait d’afficher sans effet, rendu centralisé)