J’ai repris le développement de l’éditeur de niveau du jeu.
J’ai installé le système de gestion des objets et je vous ai fait une belle capture toute mimi de la version 0.8 de l’éditeur.
Pour le moment ça liste les objets, sélectionne + recadrage caméra et ça les supprime sur demande, déjà pas mal pour une belle apres-midi.
I-boo s’empacte pour votre plus grande facilité, il contient en un seul bloc tout les fichiers dont il a besoin : langues, image, et autres…
Téléchargeable
V 0.7 de l’éditeur on peut définir le début et la fin du niveau à l’aide de fleches de couleur (bleu et rouge) placable à la souris et au clavier.
Un problème à été découvert au niveau des blocs (murs) et est en cours decorrection : quand on ne dessine plus d’objet le système ne reçoit plus l’information de métériaux (à priori c’est de ça qu’il sagit) ce qui fait que soit il fait noir de chez noir (et c’est pas une question de lumière, j’ai tout testé) soit il fait clair (selon toujours que je chipote aux matériaux standard).
Donc pour le moment hors lumière il fait clairet je vais cherche une solution pour transformer les murs en objets ce qui me semble etre une bonne solution équivalente au système actuel.
A suivre donc…
i-boo a été traduit en wallon et s’est vu garni d’une belle icone (disponible)
Je vous présente i-boo, l’installateur des logiciels daaboo.net
Il a une fiche donc je vous invite à aller la visiter et ne pas tout répeter ici et il est même téléchargeable.
A propos de téléchargeable, GRAK a été le premier à être empaqueté pour i-boo, il est disponible sur sa fiche, vous pouvez vous amuser à tester i-boo en installant GRAK… je l’ai fait au moins 100 fois en cherchant un bug.. installer, désinstaller, installer, désinstaller…, très amusant… la démo de liebesstein suivra dès qu’il en sera capable.
Une v2 d’i-boo est déjà en cours d’analyse en fonction de l’expérience que l’on va avoir avec la v1 + les idées d’améliorations déjà imaginées.
GRAK a eu une petite mise à jour concernant son itnitialisation (-init), il ne posera plus de problème de lancement et est quasi invisible.
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…
L’éditeur est capable de lire la nouvelle version des fichiers monde (fml), cad qu’ils prennent en compte les objets.
Lecture/sauvegarde et affichage sont fait et se portent bien, reste à pouvoir ajouter/supprimer/modifier les objets… encore un bazard prise de tête en perspective lol