Brols de Killan

C’est l’époque des déménagements, liebesstein déménage, quitte le foyer natal sécuritaire et prend son indépendance… quoique il reste bien accroché à GRAK et restent sont bien lié via des écris registré.

Explication simple : pour jouer à des jeux en flash il vous faut le jeu et le plugin flash installé, on ne vous redonne pas le plugins avec chaque jeu.

En montant un cran plus haut en restant simple : exemplede java, vous avez le JRE sur votre pc et les applications java l’appelle pour fonctionner

Et de manière complete :

1) regarder l’image suivante et la garder sous les yeux 🙂

2) avant correspond à la partie gauche de l’image (séparé par la ligne noire 😉 )

tout était réunit, tout le monde se connaissait et était rassemblé dans le même répertoire

3) globalisation, je ne veu pas redistribuer grak avec tout les jeux, 1 installation utilisable pour toutes les applications

on va séparer le coeur vital GRAK

l’exe et les dll système
+ 1 répertoire lngs contenant les fichiers langues des erreurs pour le fichier de logs 🙂
+ 1 répertoire crs pour contenir des crs élémentaire : vide et charge

4) vous installez le jeu Liebesstein

là vous aurez votre répertoire quelque part sur votre pc et il contiendra

des répertoires basique propre au jeu : captures (d’écran), fmls (monde du jeu), mp3s, textures
+ 1 répertoire plugins
+ 1 répertoire conf
+ 1 répertoire lngs contenant cette fois les fichiers langue du jeu
+ 1 répertoirecrs avec les CR du jeu (et meme vide et charge si pas oublié)

+ 1 batch (bas de l’image pour le détails) qui pour cette 1ere version appelle grak avec les paramètres

+ 1 répertoire créé DANS le rep de GRAK (la nomenclature de ce rep est strict et contiendra à priori 1 seule dll utilisée pour l’application/jeu)

dans notre cas les CRs et le plug-in ont besoin d’infos communes centralisées dans cette dll supplémentaire (et pour des raisons technique doit se trouver dans le rep de gra dans un rep du meme nom que la dll…)

5) dans un avenir pas lointain un programme lancera le jeu/application au lieu du batch, celui-ci pourra vérifier les mise à jour, la stabilité du système, et autres brol préparatoires sympa et utile (evidemment ceci reste propriétaire au jeu, le batch est le minimum à respecter pour que ca fonctionne)

6) note concernant le point 3), quand GRAK s’installe il peut être exécuté en mode initilalisation : d:grakgrak.exe -init ce qui aura poureffet d’écrire ou de réparer le registre windows pour dire ou se trouve GRAK

comma ça le lanceur du point 5) pourra constituer dynamiquement le chemin d’accès à GRAK

Voilà donc un bon pas en avant dans l’idée framework

A venir comme déjà dit la relecture des OG + la conception de la classe objet

Je me suis aussi lancé dans l’analyse spatiale des points et des plans pour élaborer des systèmes de colision précis voir également des modifications des mayage des objets. On verra bien 🙂

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.

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…

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 🙂

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 :

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