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é)
De retour après un petit long moment d’absence, mais cependant pas les mainsvide puisque depuis hier je me suis jetté sur l’éditeur de niveau de Liebesstein, maisavant il y avait une chose à faire : les plugins !
Le principe :
Nous avons GRAK, il se lance et fonctionne, un programmeur décide d’ajouter des fonctionnalités de type controle (non-graphique OG) pour par exemple faire un editeur, un analyseur de code, une trace live, un interpreteur de script etc…
Il va créer un composant (un control), l’ajouter dans le répertoir Plugins (ou ailleurs si l’envie lui prend, c’est prévu) ensuite il va modifier le fichier de configuration plugins.conf.
Au démarrage, GRAK va charger la fenêtre plugins qui chargera les plugins listé dans son fichier plugins.conf, ajoutera un onglet nommé et ajoutera le composant dans cet onglet, le rendant disponnible.
Explication en images :
Le plugins obtient un accès vers GRAK pour, par exemple, consulter les données centralisées (but principal). Inversement GRAK a un moyen de communiquer vers le plug-in grâce à une interface IPlugin.
Cependant GRAK, ne pouvant pas prévoir quel type de communication il va devoir faire face, utilisera une méthode commune et maléable : Alerte.
Cette méthode remplace les événements et le transfert de données.
Un cas concret :
On veu récupérer la position d’un objet qui est dans le monde 3D, afin de le déplacer peut-être.
Au clic le CR est prévenu et exécute ses méthodes (si besoin), on place les données dans la table de centralisation des données, on ajoute une ligne pour prevenir le plugin (par son nom + une action [clic])
Ce dernier sera donc prévenu d’une action, ici « clic » et dans ce cas ira chercher les données placées afin de les afficher ou modifier
Du CR vers le Plug-in il y a la méthode Alert (événement unique paramètré)
Du plug-in vers le CR il n’existe pas de lien directe
Explication de ce choix :
Le Plug-in est un élément d’analyse ou de controle
Le CR est un élément d’affichage et donc à chaque tour de rendu, tout les X rendu ou tout les x ‘temps’ il raffraichira ses données tout seul
Zou on revient en avant, OGTexteEditable est de nouveau un OG, qui réécrira Draw et qui manipulera un IFont.
OGTexte n’était pas une bonne base, car lui est multiligne. D’ailleurs il a été amélioré, on peut accéder au DrawTextFormat de FontSysteme ce qui fait que si le texte dépasse il est masqué, avant il dépassait et était visible.
Donc voilà les points 2 et 3 de la news précédente qui sont revu et le 1 qui reste actuellement à faire.
Suite au prochain numéros.
Le graal, mon graal, ça peut paraître simple, mais c’est l’objet Zone de texte. C’est donc lui le dernier élément basique à subir l’OGisation.
1) J’ai pu observer que le Draw général n’est pas du tout en cascade. Si vous avez un objet A contenant un objet B, B sera bien mis par rapport à A et A par rapport à l’écran. Mais si on a C contenu par B. Il agira comme s’il etait contenu par le fond. Il n’y a pas de remontée dans la hierarchie d’appartenance. C’est gros comme soucis même si pour le moment on fait sans, mais dès qu’on aura les listes deroulantes ou des panels, boum bam dans le baba… (et il est pas au rhum)
2) OGTexteEditable n’est pas un OG, c’est un dérivé d’OGTexte, 1ere fois que ça arrive 🙂 ce sera un OGTexte amélioré pour afficher un curseur (problème) et qui gèrera en interne les événements clavier (la redistribution focus fonctionne parfaitement). Le Draw multi-redéfini ?
3) Il va falloir revoir/accentuer le système de découpe du texte d’OGTexte. Vérification vertical à contrôler et horizontale à la lettre et plus au mot. Gérer un décalage horizontale (quand on ecris vers la droite dans un trop petit espace …)
Quel beau programme non ?
Tadaaa la boîte à message fonctionne !!!
La seconde boucle de rendu a été rendue simplifiée grâce à la structure initiale en + des testes de contrôles permettent de garder l’affichage total sans différé avec controle total ET limité à la boîte de message.
En gros tout fonctionne magnifiquement !!!
Plusieurs corrections ont eu lieu, Méthodes ajoutées etc etc 🙂 Vive LibK !!!
La voilà enfin, après une petite absence obligée, j’ai enfin fini le code visuel d’OGMessage.
Reste à faire le code de la boucle secondaire de rendu et le blocage général et on y sera enfin 🙂
Anecdote : je viens de remarquer qu’OGMessage n’est pas basé sur une OGFenetre et donc n’est pas déplacable… mais en a-t-on besoin ? Si oui, on modifiera, cela n’est pas trop compliqué.
(Oubliée lol) Capture d’OGTexte :
OGTexte est fait et fonctionne pas mal, j’ai pu cependant remarquer une vieille erreur au sujet des textures, obligé d’utiliser des puissances de 2 pour les dimenssions, à force de testes on verra ce qui sera possible ou non, comme pour le moment y a pas de graphisme réellement jene peu le dire actuellement.
OGMessage suite à OGTexte devrait être quasi prêt, en tout cas son affichage (code) est fini mais pas encore testé, il restera en suite la 2eme boucle de rendu à coder etc…
La gestion du focus et du clavier sur l’objet ayant le focus fonctionne.
Un pti mot pour dire que ça avance 😉