Auteur/autrice : killan

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 😉

• LibK est équipé d’un rendu texture, utilisé par l’éditeur et nous fait de jolis screen live
• FontBitmap et FontSystem sont réunis sous une interface vide IFont qui sera utilisé plus tard par OGTexte.
• OGMessage a été résolu théoriquement et nous allons voir appaître une 2ème boucle de rendu (bricolée). sera utilisé aussi par un OG semblable à message avec la faculté de recevoir une valeur (OGMessage lui aura la possibilité de contenir un OGCheck genre « ne plus afficher ce message »)
• les OG ont une propriété ‘visible’ et une gestion de focus sera bientôt ajoutée

Le chargement des CR s’est vu « Threadée » ce qui nous permet d’afficher le CR charge pendant le chargement du CR visé. Evidemment ceci était prévu mais sans CR à charger pour tester ce n’était pas facile… C’est donc le CR gen qui est à ça version 2 qui nous permet d’apercevoir un minim instant le CR charge.

La Version 2 du CR gen c’est quoi ? Au lieu de contenir le générique celui-ci vale chercher dans un fichier (XML), cequi permet de pouvoir modifier le texte sans devoir recompiler le CR (très intéressant pour de petites modif/ajout) de + il crée une liste d’élément ce qui nous permet de faire un petit bout de code propre bouclé au lieu du « tout écris ». Enfin, il ne calcul que les élément visible dans la zone de l’écran : gain de performances, même si ce CR est tout petit.

Version téléchargeable : note, il n’y aura pas forcément une version par jour, là j’attaque le CR jeu de Liebesstein, je dois revoir la structure fichier puis je coderais ça surement ce w-e.

Captures :