Auteur/autrice : killan

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 :

Tadaaa (faire comme 20th century fox)

C’est juste pour dire que le CR générique a été fait et que j’ai encore amélioré / corrigé / chipoter / bidouiller des trucs 🙂 anti-bugs, passage de CR, perte du device (et oui ça arrive…)

Version téléchargeable