So far I have tracked my progress, together with some informations about the format, here : http://code.google.com/p/monoxna/wiki/XnaFrameworkAudio.

With what I currently have, I also managed to write a little tool which show some informations about sound bank and their associated wave bank. The code is really ugly ATM but ultimately I will base my implementation for Mono.Xna on it (with the associated cleanup and refractoring of course ). Because a screenie is better than any word, here it is :

I also mailed a guy from the XNA team asking some questions about the format. From what I have seen on forums they aren’t very inclined to give away these informations so let’s see how it ends .

NP: Out in the Fields, Sonata Arctica

I looked quickly at the code added since the last time and it seems to have advanced quite good even though I saw some violations of the coding guidelines . I also noticed that someone (Alan ?) added some comments on my precedent work about possible issues. I will try to look at that ASAP.

I already had some stubs of the Design namespace implemented so I will resume my work on them but more importantly I peeked a little at the Xna.Framework.Audio namespace to understand how it worked. So far I wrote the result of my researchs on a Mono.Xna’s wiki page. Feel free to add things (especially about implementation ideas).

• Yay today I passed my last written exam for the Baccalauréat. Physics/Chemistry was terrific but I found Math easy (which is good because my final mark will depend mostly on this exam mark). Now it just let some practical and oral tests in the following week but it’s not big deal : meaning I will much more time to work on what I like .
• I found some time to add new features to Circ like a revamped parser infrastructure and now Circ take account of its conf file. I pushed my early work on the mirror but it’s still very buggy so I don’t recommend that you upgrade.
• For all Ubuntu performance tuning fan out of there you should try these set of scripts : http://gnomefiles.org/app.php?soft_id=1397 . Basically they remove whitespaces and such from your Gnome’s XML files which improve speed launch of your app and their memory usage.
• Monodevelop 0.14 is out with all the juicy features I described there and more. Yesterday I just discovered that you can know generate automagically properties from a field via the right-click menu. Terrific
• I’m wondering what are the capabitilities of this Thrust thing and if it would run fine on Mono.Xna. Will test it when I find time.
• Tomorrow I have to go to some sort of meeting to be introduced to the job I will make during this summer. Hu who found the dumb idea to make me wake up for 9am when I just finished my exams and when I’m going to a friend’s party this evening …

This lead me to the news of the Tao 2.0 RC2 release that I « quickly » downloaded. « Quickly » because even in the tar.gz package, which is supposed to be more for UNIX folks, Tao devs put every Win32 DLLs dependencies that they could find for Tao and moreover in two different places (14 Mo for nothing) ! (They were also OSX deps).

But well I’m not writing this post to complain on Tao strange relationship with dependencies . Instead I want to point out several problems of Tao under Linux. As you (should) know Tao is P/Invoke wrapper around several multimedia-related libraries like OpenGL, OpenAL, GLFW, SDL etc… . It’s notorious that under Linux there has been always some problems. mine were almost always related to double-freed pointers or corrupted memory. Moreover there are always been some inconsistency in method prototype (bad parameter type generally). In fact only the Tao.OpenGL wrapper is generated automatically via a spec parser, that’s fine because OpenGL is a standard and under the governance of big companies (ATI, NVidia …) that’s why stuff are well done and why there is such thing as a spec file describing every function, enum, typedef and even vendor-specific extensions. But other projects don’t have the time, resources, or just the will to do such a thing. That’s why I had the idea to create a P/Invoke generator that would take a .h file and produce the corresponding P/Invoke .cs file. There is already a tool which do things like this : Swing but the problem is that it force to create c wrappers whereas the P/Invoke system is precisely designed to avoid such things.

Since I didn’t want to create a full-featured C parser in C# I had three possibilities :

• Use some well crafted and illegible Regex to fetch function prototype and struct scheme. The main problem is that they are complicated stuff to look for, like typedef and #define directives.
• Use the same process that before but on a preprocessed source file thus eliminating some difficulties. Problem : the typedef case stays the same.
• Use a dedicated compiler which produce something readable instead of machine code. Fortunately there is a tool out there which do just that : GCC-XML. GCC-XML is a full featured gcc compiler that output XML representing the internal of GCC during the compilation (the GIMPLE tree I think). Personal problem : even if I can use the big facilities of the .NET framework regarding XML support, the output of GCC-XML is still, hum, barely readable for a limited human being like me . But since the common good is more important I decided to go with this solution .

If you are curious here is a sample code that I use like a test for the parser, and here is the result returned by GCC-XML (without options). As you can see there are all possible informations in the XML file like the length of the structure, the alignment, the offset …

I have started to write the XML parser right now so let’s see if the result will be convincing. Stay tuned .

So as Miguel said on his blog, Mono.Xna is now « mature » enough to run Rob’s Pong.

As the  »  » suggests, I’m not comfortable anymore with the idea that Mono.Xna is getting more and more mature. In fact it’s totally the contrary : I’m more and more suspicious towards Mono.Xna. Even though there are great people behind it (Antti, Alan, David Hudson…) the project lack a consistence IMHO. Still now I don’t really know who is the « Game Master » behind Mono.Xna nor did I see the skeleton of a real organization behind it. Actually Mono.Xna appears to me more like a big mess than a shiny piece of code. Things are quickly (doesn’t influence the patch length though )  hacked upon the stubs without a common talk or a design plan from the team. What I fear is that all this work will ultimately result in nothing because of its crappiness (writing unit tests isn’t sufficient). Maybe at some point we will be able to just stop the « hackers folly », design a correct infrastructure and fork the existing code where possible in the new design.

For the moment things are still easy because SDL.NET helps a lot (I’m still unconvinced that tying Mono.Xna so deeply in SDL.NET is a good idea but that’s another matter). But things will get exponentially harder when the Content Pipeline, for example, will need to be implemented.

Mono.Xna a bien avancé, dernièrement Rob et duff ont travaillé sur les classes Texture2D et SpriteBatch qui devraient nous permettre d’atteindre notre deuxième milestone à savoir jouer au jeu de Pong de Rob . Les bibliothèques SDL.NET et Tao ont été également mise à jour mais il semblerait qu’elle pose problème sous Linux (faut que je vois si ça vient de Mono ou de Tao).

Circ a avancé, j’arrive maintenant à me connecter à un serveur IRC . D’ailleurs je prévois de renommer la bibliothèque IRC qui va avec Circ sous le doux nom de CIL (Circ’s IRC library) qui est aussi le nom officiel du langage IL utilisé par Mono/.NET (encore une dédicasse aux anti-Monoïstes de service je suppose ).

Edit: Par hasard je suis tombé sur la page du framework Telepathy que je connaissais déjà de nom mais que je n’avais jamais vraiment étudié à fond. Cependant j’ai trouvé que le projet Tapioca fournissait des bindings C# pour Telepathy qui propose entre autre un accès IRC. Ce qui me ramène à l’idée que même la bibliothèque IRC que Circ utilisera devrait être interchangable (mais normalement si mon PAC est bien fait il n’y aura pas de problème )

Pour Mono.Xna nous utilisons SDL.NET qui est un wrapper au niveau de Tao.Sdl qui est lui même un binding de la bien connue bibliothèque SDL. SDL est utile dans le sens où elle abstrait les opérations, comme le support des joysticks, sur pas mal de système différent. Le revers de tout ça est que ce qui est permis est assez limité : une fois qu’on a passé le cap de l’état des bouttons on peut difficilement faire plus.

Ainsi pour cette opération très spéciale qu’est le maniement des retours de force du gamepad de la 360, il faut utiliser les API natives. Pour Windows pas de souci, un peu de Googling et j’ai trouvé la lib XInput qui a été visiblement créée pour être utilisé en interne par XNA. Du côté de MacOS X j’ai aussi trouvé quelques pistes dans la documentation mais le maniement est plus délicat (l’API semble permettre des choses puissantes, les vibrations y sont représentés par des effets qui sont paramétrables etc…, mais elle est plus complexe). Et comme tout bon Linuxien qui se respecte je me devais de faire marcher l’histoire sous le système Pingouin jusqu’à que je ne trouve… rien. Le kernel (et pas Xorg comme je le pensais au début) supporte bien les joysticks mais bizarrement c’est le même ordre de fonctionnalité que SDL (étrange, étrange ). Pour être plus honnête il semble bien y’avoir une fonction obscure qui permet d’envoyer des informations bas niveau au joystick mais elle est tellement bas-niveau qu’il faut manipuler directement les bits ce que je ne peux pas faire vu mon peu d’expérience assembleur/système ou simplement le fait que je n’ai pas de contrôleur XBox 360 (si vous avez un cadeau à faire … ). Bref Linux de ce côté là est à mon avis en retard (vis à vis de ces concurrents Windows et MacOS X).

Ca y’est Mono.Xna est capable de faire quelque chose d’utile (« utile » est à relativiser ) grâce à super Rob . En effet la dernière version SVN fait tourner (de son petit nom) SimpleExample. Je vous ai mit une vidéo en bas (fait par moi donc très bof). Vous pouvez aussi allez voir le blog d’Alan.

Lien vers la vidéo.

PS : comme c’est fait avec VLC il se peut que ça marche qu’avec VLC