Catégorie : grak

ODE est une librairie physique très intéressante, libre et utilisable en C# / Direxct X.

Muni de cette nouvelle arme, nous devrions avancer un peu plus dans nos projets.

Aucunes informations actuellement concernant l’intégration d’ODE.

Suite à d’autres recheches plusieurs points concernant LibK devront être repensé avant d’être codé, surtout concernant la gestion des objets. Actuellement il resteront donc dans une lib à part.

Je sais que plus rien n’a avancé, mais rien n’est abandonné je vous rassure !

Petit test de distribution des 2 projets GRAK et Liebesstein en cours pour voir si tout se passe bien sur des plateformes publiques.

Le premier résultat à été tout à fait fonctionnel. Pourvu que ça dure…

Tiny, mascotte fort connue des programmeurs DirectX fait son entrée chez nous.

Tiny est un fichier X animé, en me basant sur le code du SDK de DirectX + de l’ajout HLSL traduit du C++ vers le C# par Steve Lanuit + de mes ajouts pour le choix des animations, j’ai pu l’introduire parmis nous.

Mes améliorations du code ne sont qu’a leur début car cette classe ObjetXanime a besoin de beaucoup de modification pour la rendre générique.

De plus je vais réécrire Lobj de la librairie Libesstein et réunir objet simple et objet animé sous une seule classe mère dans LibK si possible (car la structure des objets animés est fort fermée) : gérer leurs textures de manière à opérer des modifications facilement et gérer leur ombres (d’ailleurs pour les objets animés ça va pas être facile)

Voilà le menu des opérations, Lobj sera une descendance de la classe mere et plus directement d’ObjetX.

C’est grâce à Flip que notre fouttu probleme d’ombre qui se projettait n’importe où a été réglé…

En fait moi je transformais les matrices dans l’ordre -X -Y -Z, comme quand je fait le rendu (mais en inverse : X Y Z) alors qu’il fallais également inverser l’ordre des matrices et donc obtenir -Z -Y -X… c’est con mais important.

Merci Flip.

Prochainement je publierais un article conssacré aux ombres AVEC les transformations. A venir donc…

Crevé, exténué… 1 semaine de fouille, de retournement de code, de forums et autres brols pour enfin y arriver…

Remontons le temps et resituons nous en main 2005 (stage à l’INPRES) ou je devais faire le moteur de rendu d’animations truc bidul « Animator 4D »…

J’ai pleuré en voyant le code de Jack Hoxley en c++, bric à brol illisible… 2 jours m’ont dégouté de ce code et j’ai donc échoué/abandonné… c’est aussi a cette époque que j’ai voulu faire une bounding box qui tenait compte des rotations/proportions (ce que j’ai réussi il y a peu).

Vendredi passé, après une nuit tourmentée à réver de tout ça, je me suis dit, même si la liste des chose à faire était longue et aux priorités variables : « tampis, le prochain Graal sera ces fouttues ombres !!! »

Et vlan en avant pour relire le code d’Hoxley, de théorie sur gamedev.net et autres, puis un autre code barbare qui fonctionnait bien aussi, tjr en c++6, avec des lectures de données et interpretations perso… la folie pour retirer un truc générique… Pour finir je reprend ma classe ShadowVolume d’Animator 4D, je trouve 1-2 erreurs, qui découle des debuggage intensif mais le résultat… c’est pas vraiment ça…

Dans la foulée je trouve sur mdxinfo.com un code d’ombre simple, c’est l’adaptation un peu modifiée du code d’Hoxley… je vérifie avec mon code… aucunes erreurs apparentes : le problème ? la compilation des projets foirait + les transformation et préparation des vecteurs concernant la lumière…

Ensuite est venu, pour parfaire le rendu, la définition d’une lumière, comprendre son mécanisme pour jouer sur la précision de son atténuation, etc… La encore il aura fallu quelques heure de debug car le paramétrage du device n’était pas conforme et on avait des trucs du genre :

Apres donc 1 semaine d’insomnie et de prise de tête nous y sommes enfin.

Voici le résultat actuel :

Il subsiste toutefois une erreur.

La transformation sur l’axe Y (en rotation) fonctionne, le positionnement aussi… mais la rotation sur X et Z donne des résultats incohérent :

Je cherche toujours donc… en attendant il serait temps de reprendre l’éditeur de Liebesstein et de finir l’implémentation des objets…

Dernière capture :

Correction du bug :

A part un nouveau bug découvert (modif de texture sans alpha concervé), j’ai commencé l’ajout des fonctionnalités liées aux objets 3D, ainsi LibK sait lire un fichier X simple, optimise le chargement des textures et s’occupe du rendu.

A la suite d’une aprem de codage sur les objets animés qui depuis l’année passée s’acharnent sur moi et suite à mes précédentes idées de contrôle absolu sur les objets le + possible : la gestion des objets composés et animés se fera via nos systèmes.

Le système de boucle des musiques avait une faille qui a été corrigée. (quand un CR se charge et ajoute une musique à la liste et qu’en même temps GRAK veut vérifier les musiques à boucler…)

Concernant la réduction de face pour le 320*240, on oublie, faudra voir ça avec le bloc effet.

La musique est bouclée (loop), les événements de directsound ne se lançaient pas alors j’ai refait le système à ma sauce et lui fonctionne. Ca permettra aussi d’ajouter des fonctionnalités (délais, effets [fondu, …], …)

Le CR charge était buggé par ma faute, je l’ai réparé (vive les backups)

J’ai aussi déterminé l’origine d’une exception (erreur) mais qui sera à mon avis inévitable (chargement/déchargement simultané, données supprimées alors que d’autres les appelles => exception (ceci souvent en cas d’erreur [cas du CR harge]))

En voulant faire la vidéo je me suis rendu compte d’un bete truc, pour faire une vidéo le + fluide possible, il faut la faire en bonne taille (320*240). J’ai donc dit à GRAK de démarrer dans cette résolution et là… catastrophe !

Le menu déborde et est en dehors de la fenêtre, pareil pour le générique, bref pareil pour tout ce qui est 2D… car la 3D, elle, reste identique bien proportionnée par rapport à l’écran.

C’est normal vu que une image appliquée à l’écran ne va pas changer subitement de taille du fait que notre fenêtre elle change de taille.

LE problème est donc la proportion et ceci est lié à l’idée de projection. La 3D est projetée dans l’espace par rapport à la vue et donc restera proportionnel à la taille de l’écran (ici je schématise très fort). La 2D elle n’est pas et ne sera pas projetée.

A l’époque c’était facile les jeux n’avaient qu’un seul mode graphique/résolution. Puis on a varier, donc que faisait-on ? On prévoyait le jeu pour la résolution minimum, mais je me vois mal faire le jeu pour du 320*240, je le ferais plutôt pour du 800*600, mais les vidéos elle sont capturée en 320*240.

Il nous faut donc une solution : une résolution alternative pour le rendu.

En travaillant avec des rendu-textures, celles-ci sont projettées sur une face à l’écran pour être vue.

Actuellement, si on lance le jeu en 800*600, nous projettons le rendu (le monde) et la 2D dans une texture de rendu établie en 800*600 qui sera à son tour projetée sur une face.

Si maintenant on désire garder une proportion minimum de l’ensemble lorsque l’on diminue la résolution il va falloir jouer sur le seul élément variable dans ce cas : la texture de rendu : sa taille.

Nous démarrons donc en 320*240, notre jeu est fait pour du 800*600 et la carte graphique est ok pour cette résolution en mémoire. Nous créerons la texture de rendu non pas en 320*240 comme au démarrage mais en 800*600. Ce rendu sera donc projetée sur une face 320*240 ce qui écrasera l’image (sans pertes dans ce cas là) et nous auront notre porportion concervée.

Ceci est fort technique je l’avoue mais comme ça vous savez un truc en + qui sera dans GRAK 🙂 Tout ça juste pour faire des vidéos en gros lol

Ceci sera prochaînement mis au point et enfin on pourra faire une vidéo intégrale de ce qui existe actuellement.

Je reviens à la charge avec les bureaux et l’éditeur de ceux-ci.

A quoi ça sert ?

Un bureau sert à gérer des fenêtres, boutons et autre objets graphique, bref les OGs de LibK.

L’écriture d’un bureau est longue, abstraite et pénible (je le sais par expérience) autant écrire le contenu d’un Widows Form à la main…

L’éditeur est donc l’homologue de Visual Studio (en + simple et basique) adapté pour les OGs de LibK pour leurs intégration facile dans les projets GRAK.

Une future super classe de LibK : Bureau, sera le siège de la gestion des événements et rendus de cette couche. (capte et redistribue les événements, gère le rendu)

En découlera une classe auto-générée de base par l’éditeur selon vos désirs.

Ajoutez votre nouvelle classe bureau à votre projet de CR et inscrivez-le dans le gestionnaire de bureau de GRAK et le tour est joué.

Cette nouvelle classe contiendra le squellette suivant :

– décalaration de vos OGs et modification des propriétés de ceux-ci
– arborescence père-fils des OG entre eux
– écriture des fonctions vierge des événements désirés des OG (via l’éditeur : cases à cocher pré-établies par défaut)
– tout le code est indenté et #regionné selon la hiérarchie père-fils

Ceci devrait définir la première structure fiable d’OGs

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 🙂