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.

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.

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.