Vexel

Après plusieurs jours de discussion sur forum, de recherches interminables, de lecture et relecture du code d’initialisation de GRAK, j’ai enfin réussi a refaire fonctionner le SwitchMode, cad le passage entre un mode fenêtré ou un mode plein écran pendant que GRAK s’exécute.

De plus, si, à la fin du programme, le jeu est en plein écran, il le remet en fenêtré de tel sorte que vos programmes (explorateur de fichier, navigateur, msn, winamp, …) reprenne leur positions initial. (Pour info la position des autres fenêtre change lorsque l’on passe en plein écran dans une résolution differente)

A venir en matière de correction : la relecture complete des OG.

en-cor-ection

Le chargement sonore a été accéléré, on passe par un autre device prioritéaire (comme on aurait du faire depuis le début), enfin soit ça va + vite et c’est tant mieu !

GRAK a été utilisé pour la réalisation d’un petit programe bibitif : le jackpot-afond qui a été utilisé lors de la soirée d’embassade annuel de l’Ordre de la Questure Raymaldienne. Ce même programme a déjà été repris et utilisé par d’autres Ordres ! youhou 🙂 Ce logiciel se trouvera un jour dans les téléchargements. A venir donc…

ich speak internazional

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 🙂

[E]x[TI]nction

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.

ETI mologie ?

1er ETI le fondu au noir, et ben non ça ne vas pas :

  • Le rendutexture n’est pas modifiable, je cherche un moyen de copier cette fouttue texture
  • Si même j’utilise une texture (imposée) le fondu au noir se fait proprement, mais envahit la mémoire à chaque traitement et ne décrois jamais… crasse crasse crasse et je ne sais pas nettoyer ça (je cherche encore)

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 telephone maison

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é)

Plug-ins (dildo ?)

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 :

06-03-31-plugins

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

Retour vers le futur

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.

A la recherche du graal !

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 ?

OGMessage et le rendu

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 !!!