Hey I don’t know why I wouldn’t also blog about Mono.Xna since things there are also moving on.
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.
- Press My Buttons !
Salut garuma,
c’est duff,
je suis plutot d’acord avec ce que tu dis et c’est aussi ce qui m a fait lacher Mono.XNA.
Alan ne s’en occupe pas trop car mono lui prends beaucoup de temps et pour les autres c’est la meme chose avec d’autre projet.
Donc pas de reel leader.
Coté design. J’ai commencer a vouloir faire une doc dans le wiki du content pipepline mais ca a vite tourner au cochemard tellement c’est complexe. Donc, on a besoin de plein de personne pour lire les fichier venant du piepline et essayer de comprendre ce qu’ils contiennent. C’est extremement compliqué et ca va demander beaucoup de temps. Mais pour cela il faut du mond e et des personnes motivés.
Personnellement, je pense que plutot que s’occupé des babiole facile a codé, il faut faire des doc et reflechir a l’intégration du content pipeline (notament la parti vertex shader qui est propre a directX) pour pouvoir avoir quelquechose de compatible.
Car sinon, on va s’appercevoir très tard des problèmes et devoir tout refaire.
Why are unit tests not sufficient? If we can test known behaviours from MSXNA, and duplicate this behaviour in Mono.Xna, I’d say that is sufficient. I’m happy to hear a valid argument to the contrary.
Essentially what we are following is a TDD process. We build the test to exercise a particular feature, run it against MSXNA to verify correctness and then implement it in Mono.Xna to duplicate.
We have a design – it’s called Microsoft.Xna, with plenty of public documentation. We have two cross-platform frameworks to abstract the API – SDL.NET and Tao. What additional design would you like to see?
I have contributed to SDL.NET and Rob Loach is a senior of Tao, so we can continue to evolve these frameworks to help with Mono.Xna.
I agree that the content pipeline is going to be the hardest to implement.
I have nothing against TDD, in fact Mono.Xna gave me the chance to actually learn how to use effectively NUnit in a project (I’m a contributor to Mono.Xna and Tao too
).
As for MS XNA you don’t have a design, you have a public API and thus stubs on Mono.Xna. Ok writing test let you check the behavior of both implementations but it doesn’t guarantee the _quality_ of your implementation, you just can’t rely on tests for that. Moreover there are simply things that you can’t test : when I was trying to implement the Input part with Rob I just couldn’t test input behavior even when I used some internal SDL function, it was a complete nightmare.
IMHO The design-time part of a project is the most important one in the development cycle and my feeling is that in Mono.Xna it has just been skipped or ignored (some people were actually willing to do it). For example until Alan wrote some guideline in his blog (http://monotorrent.blogspot.com/2006/12/in-similar-theme-to-my-last-post-im.html && http://monotorrent.blogspot.com/2006/12/i-started-working-on-mono.html) some of the parts that were already written in Mono.Xna were very ugly even if it would have surely passed all imaginable tests, it was just unmaintainable and slow. Don’t forget that Mono.Xna also wants to target console were things are substantially different than a PC, there may be some considerations on memory usage and things like that, considerations that doesn’t appear in any design document or book of specifications.
On a side note and as I described some posts later Tao tends, for reasons unknown to me, to be really buggy on other system than Windows (the API have also some imperfections). I also don’t like the idea of Mono.Xna being dependent of a toolkit like SDL because : I don’t like SDL (it’s more a personal taste here) and because, IMO, something is portable if it’s independent from the underlying working layer (just imagine that SDL becomes unmaintained/unavailable on some platform and that we want to port Mono.Xna to a toolkit like Allegro or maybe a combination of other Tao libs like Glfw+DevIL+OpenAL… what would you do then with all your direct calls to SDL.NET ? Write a proxy ?).
That said, it just represents my personal opinion and you are free to do as you wish. I just hope that it won’t backfire at you later.