Attention ça mord !!!

Je n’ai pas abandonné le projet Nahyan, loin de là, juste une mauvaise passe du fait de ne pas savoir ce qui convient comme language, plateforme etc.. bref les premières questions à se poser avant de développer…

C’est maintenant que je me dirige vers Python, PyOpenGL et divers. Sous eclipse avec le module PyDev.

Pourquoi Python et plus mono : portabilité. Et comme une des conditions de Nahyan c’est son exécution inconditionnelle ça joue beaucoup.

De plus Python offre beaucoup de choses intéressantes (mais pas d’IDE convaiquant jusque là). De plus Myst Uru a été fait avec et c’est une pure merveille (étant fan ça convainc).

Nous voilà donc prochaînement parti dans cette nouvelle aventure définitivement conssacrée sans détour à Nahyan ! (si si je vais m’y tenir)

Les premières nouvelles devraient voire le jour d’ici peu connaissant mon intenable envie d’essayer Python par quelques exemple…

Tao, Mono & Co.

Non je ne parle pas chinois, du moins pas encore mais je me porte (plutôt bien).

Mono permet de faire du .net sous nunux et mac en + de windows bien sur.

Tao c’est la lib comparable à DirectX, mais portable avec OpenGL, OpenAL, ODE, etc.. que du bonheur en perspective.

En gros ? On repart à zéro en mode portabilité, du moins on espère !

Bureau devra être controllé afin d’utilser OpenGL au lieu de DX, le traitement d’image ne devrait pas en souffrir de trop espérons le.

NTerrain, lui, devra etre fortement refait afin de remplacer DX par OGL et de tenir compte du framework Mono avec GTK (ce qui change pas mal d’habitudes prise avec la base de C# selon microsoft).

La boucle est bouclée

NTerrain connaissait un bug assez problématique : modifier une extrémité de la zone modifiait également les derniers points de celle-ci et quand on clic sur les derniers points ils ne bougeaient pas…

Ceci a été baptisée mémoire en boucle vu que les points du début et de la fin fusionnaient à un endroit.

J’ai donc tué le méchant <= pour y mettre un <... ça parrait con mais dans +200 lignes utilisant 2 systèmes différents pour manipuler 2 fois 2 données qui sont en rapport l'une par rapport à l'autre... bref ça été dur surtout après 2 mois sans voir ce bout de code ^^ Enfin soit c'est corrigé ! De plus l'update de la zone a été optimisé, mais l'affichage n'est toujours pas temps réel malgrés tout. Dans un avenir proche : menu de l'applic et fenêtre d'options partielles du pinceau 🙂

Mais heu… tu m’as fait peur !

Oui une véritable frayeur… en effet !

J’ai compilé le premier essai de la bibliothèque de contrôles graphique (Bureau), qui remplace cette partie de Lib’K, le tout amélioré, complèté, etc… Mais au moment de tester l’ensemble sur le PC test « sain » de puces et de mémoires, pan ca ne va pas…

Et mer**-credi… en fait DX est composé de « sous-version » (allez voir dans votre répertoire : C:\WINDOWS\Microsoft.NET\DirectX for Managed Code\) vous y trouvez plusieurs répertoire et ceci est variable d’un pc à l’autre. (ce répertoire ne se créer que si vous avez installez le framework .net 1.1 AVANT)

Donc le gros problème est de faire un programme qui s’exécute avec la sous-version que tout le monde a… sauf que personne à la même… J’ai 2 x 2908 + 1 x 2905 et mon pc de dev les ayant toutes… mouai bon…

Après moultes recherche on définis :

– installer le .net 1.1
– installer la derniere version de DX9.0c, cad celle de février 2007 ayant les 11 sous-version, nous décidons également de bosser avec la sv11.
– ensuite là le programme s’exécute sans problème

Nous sommes toujours en phase de test afin de pas dire, ni se baser, sur de sombres théories…

Bureau

Parlons de Bureau. Actuellement contient un ogImage qui est la nouvelle base à tout objet graphique. Un bouton a un fond coloré ou texturé et ceci est valable pour tout les OG.

J’ai redéfinis le système d’événement et ai apporté, sous mon influence web, des notions CSS dans les propriétés de ce bouton.

Ainsi une classe Bord et une classe Contour (contenant 4 Bord) voient le jour. Le système de background de l’objet est précis au pixel prêt, suite à une réécriture du système de préparation intégrale. Les événements sont pret mais vont déjà subir une amélioration : l’accrochage au événements de manière automatique, ainsi que la gestion de parentée qui se faisait en 2 temps précédemment.

Pour mieu comprendre l’état actuel

07-03-02-nterrain-og-3

PAN ! Mauvais départ…

Un pti mot pour parler de l’avancement du projet malgrés les difficultés de temps libre ^^

J’ai débuté le programme de modélisation des terrains et d’habillage de ceux-ci. Après un mauvais départ le programme est bien parti 🙂

Quant au reste de l’équipe, ça papot’ sur les cahier des charges des 2 autres programmes.

Voilou pour les petites nouvelles 🙂

Phase 2

La décision est tombée fin 2006, les projets GRAK et Liebesstein sont arrêtés.

Les tests ont étés satisfaisants et la production de Nahyan peut commencer.

L’ancienne équipe des programmeurs de PDT c’est réunie d’elle même quand l’idée fut diffusée. Jetdail (ex-Fish) et K-you forment désormais la section réseau et messagerie.

A cela viennent s’ajouter des infographistes qui contribueront grandement à l’élaboration des premières bibliothèques d’objets et de textures.

Les cahiers de charges sont déjà en cours de rédaction et le premier calendrier est établit. Espérons seulement qu’il sera tenu.