Couple questions.

Dec 3, 2011 at 5:34 PM

This seems great, I'm really excited to see ANX grow, and am interested in it for its theoretical performance increases over xna (using sharpDX)

I do have a few questions though.

Will ANX have its own content builder, similar to how XNA creates its ".xnb" files? If so will it support custom content processors?

Is there going to be native support for the FBX sdk, so we can load FBX files as models in our content (same for .X models)?

Other than those few questions I pretty much fully satisfied to se how things are going.

Very impressive work so far.

Coordinator
Dec 3, 2011 at 9:46 PM

Thank you :-)

To make things easy we use the ContentImporter, -Processors and -Writers of XNA because it works very well and the only disadvantage of this is, that building content is windows only. So you are able to extend the content pipeline with all the extensions created for your xna projects. We have recreated all the readers of the content pipeline which will do a transparent remapping of the types of XNA to the ANX types. In future (after the 1.0 version) we have some ideas to recreate the whole content pipeline for real multi platform build time support and for further extensions of the content pipeline concept.

 

Dec 14, 2011 at 8:36 PM

Since I´m a fun of SharpDX, I will be following this project.

> In future (after the 1.0 version) we have some ideas to recreate the whole content pipeline for real multi platform build time support and for further extensions of the content pipeline concept.

I have implemented my own ContentManager for XNA which is independant of XNA's xnb header and way faster than the built-in one for all supported platforms. So my advice is, when you re-implement the content pipeline also try to modify the header construction in a way that any project can read the same content by providing a GUID or something.

Coordinator
Dec 14, 2011 at 8:43 PM

The platform independent content reading is not a problem. We are already able to read XNA generated content under Linux, MacOs X, Windows Phone, XBox and Windows. It is even fast. For most of the formats (Textures, Effects, Buffers) there is very little overhead and good compression. The XML-Content-Serialization is not the best one. A binary format is faster most of the time.

The problem is generating this content. Reading FBX files, generating tangent information and such things are not a trivial task. It is a real big project on it's own. And since the content generation is already working (under windows) this is ok for now. We are able to build on windows and run on many platforms already.

What do you mean exactly with "try to modify the header construction"? Do you see any problems that we maybe didn't see?

 

Dec 14, 2011 at 8:46 PM

I will follow this conversation by email. :)