This project is read-only.

What do you want next?

Dec 15, 2011 at 1:21 PM

Hey guys...

First: Thank you for reading this post and visiting our project page. We appreciate your interest in our project.

Please take the time and drop some words in this thread. Please tell us, what you excpect from this project. What do you need to work with this project? What is the most important for you?

Thank you for your time :-)


Jan 2, 2012 at 4:03 PM


Thanks for the work you are doing.

I'm a game dev working on XNA (project Arcane's Tower defense : and we look forward to see what anx will become.

I haven't tried to use anx at this time but I will test it as soon as possible. I will follow your project very closely.

I love to create game using c#/xna and if we could port our games to other plateforms using anx it could be awesome.

Good luck

Jan 2, 2012 at 5:27 PM

If I were to use this project, it would be primarily to support casual game development on the WinRT/Metro/DirectX11.1 platform. I'm not really all that interested in cross-platform support on Mono for Linux/iOS/Android since mono isn't free on android/ios, although having that option is definitely a plus.

My requirements:

  • Project templates for metro style applications.
  • Samples, that work, on Metro/WinRT
  • Stability.
  • Code should also be readable/documented enough that I could fix a last minute bug myself if I found one. Especially on the C++ side of things.
  • I use primarily SpriteBatch and not much else, but supporting arbitrary shaders and geometry would open up a lot for certain types of games I want to make.
  • Source code compatibility with Xna on windows phone and/or xbox is of priority importance. XBox isn't my primary market, but it needs to stay an option. If I have to make any #if XNA_BUILD .... #else .... blocks in the code, I'll just have to write another abstraction layer on top of ANX. If you diverge from XNA standard, make sure it's for good reason, and make attempts to provide a compatibility layer/fallbacks as needed.
  • Ability to compose an XNA "surface" in a XAML "shell" is an optional secondary requirement. Performance for this scenario should be within 10% of the performance of the non-XAML version, if possible. If that's not possible due to WinRT/XAML limitations, then don't waste time on this scenario since I won't use it if it's too slow. Any solution involving copying of raw frame buffer data into a WriteableBitmap would probably qualify as "too slow" unless there is some magic sauce behind the WinRT blackbox. All of that buffer stuff changed in WinRT/XAML so I have no idea what's fast/slow anymore heh.
  • Both SoundEffect and Song APIs.
  • Traditional XInput API.

Bonus points for:

  • In addition to basic SpriteFont support, possibly a dynamic text rendering API that doesn't require font sprite sheets to be pre-made by the content pipeline. This is needed for example if you have an in-game multiplayer chat feature and support international users. So, to render arbitrary unicode text, with SpriteFont you need to either filter the glyphs users can use, or package a 100MB+ sprite sheet with all the unicode glyphs you'll ever want to use. A dynamic sprite rendering API would allow arbitrary unicode glyphs to be rendered and cached as needed. On WinRT/Metro renderer, you'd implement this with DirectWrite/Direct2D for example, but it should be setup to easily support other text rendering engines on different platforms (including SpriteFont fallback on XNA for windows phone). 
  • Better synergy with the SlimDX team/project. 
  • Less focus on DirectX10, more focus on DirectX 11.1. 
Jan 3, 2012 at 4:50 AM

I'd love to have a tool like XACT, or the ability to use XACT.  I think it is a severely under-rated tool, and love most of it to death (there are some things I don't like).  For ease of use, I'd like to continue using it when I switch to ANX next project.

Jan 3, 2012 at 8:16 AM

Wow, that's a bunch of good points :-)

I want to write some comments:

I think the code is readable but currently does not have many documentation. I will mark this as a low priority point. The C++ side of things is totally out of our scope because it depends heavily on SharpDX (Windows), OpenTK (MacOs, Linux, Windows, Android, iOS), MonoDroid (Android) and MonoTouch (iOS). As you are mostly interested in Metro-Style apps SharpDX is the important thing (this is our main focus, too). The code is generated automatically by parsing the Header files of the DirectX-SDK. The author of SharpDX, Alexandre Mutel is very helpful with this.

As for the source code compatibility: This is our main focus. We want 100% compatibility and it will be possible (it already is) to convert projects by exchanging the namespaces of the using-statements and replacing the Effect-Content-Processor by our own one. If you want to use OpenGL you have to write GLSL shaders. For DirectX 10, 11 and 11.1 there are some minor changes necessary in the HLSL code.

The XNA "surface" stuff is very interesting for editor applications and such things. I want to provide a mechanism and a native ANX way of rendering to WinForms (as this is compatible with Linux and MacOs by using Mono) and to XAML surfaces. I'm not really sure what's the best way to provide such features as this does not have the highest priority.

As for the "Traditional XInput API": Most of the XNA input handling is already working: Keyboard, GamePad and Mouse is working but the capabilities structures are not finished. Touch input is another open point. This one is using XInput as this is our default input system.

As for the bonus points:

Font Stuff: Yes, this is a very interesting topic. I will look sometime soon into this and try to come up with a good solution.

Better synergy with SlimDX team/project: Can you explain this point further? I think we have totally different focuses...

Focus on DirectX 11.1: Yes, this is important as "Metro-Style" is one of the main goals of this project. We start with the DirectX10/11 RenderSystem because XNA 4.0 has often a 1:1 relationship API wise. This is a good way to ensure a consistent behaviour. It is not much effort necessary to move on to DirectX 11.1 / Metro from there. I will spent much more work in this soon, but I have to purchase a dedicated machine for Windows 8 first, as the virtual machine is much too slow.


@electroflame: Everything what you are able to do with XNA/XACT will be possible in ANX too. Currently we are searching for a coder for the sound stuff, as we are all busy with other things.


Thanks to both of you for your suggestions...


Jan 3, 2012 at 2:52 PM

Oh, and some more requirements I forgot to mention:

  • Solution and project structure that opens and builds "out of the box" in the Visual Studio 2011 beta Express SKU for windows 8 developer preview. I'm guessing this is on your todo once you get the new machine?
  • Readme.txt explaining the solution structure, what the purpose of each directory is, etc... just a high level summary for "what am I looking at?" kind of questions. I'm currently a bit lost as to what each piece is outside of the ANX.Framework project and the samples.
  • As far as documentation goes, priority is just getting the high level architecture documented. Like, how does ANX handle arbitrary rendering engines, or how do I plug in a shader pipeline for my rendering engine. The details are obviously fluid at this stage in development, so there's no need to add docs to every function and class until things stabilize a bit.

And one more bonus point:

  • Support for SharpDX as an alternative to SlimDX. SharpDX was I believe the first to come out with DX11.1 bindings that passed marketplace certification for metro style applications, and seems to be the more mature metro implementation of the two. 

Clarification on SlimDX and/or SharpDX synergy:

This just means that, since we're using SlimDX or SharpDX as a dependency, there should be a good two-way dialog between the two projects. 

Jan 3, 2012 at 3:05 PM

Sounds fine... Dacore with every point ;-)

BTW: We are using SharpDX only for ANX. It is much faster than SlimDX and the Metro-Support is already very mature. I tried metro some weeks ago and made good progress on a virtual machine. But things get to slow now to do further development.

Jan 4, 2012 at 1:50 PM

Concerning DirectX integration in XAML, this is currently not supported in the Win8 Developer Preview. I don't know if It will be available for RTM but Microsoft is supposedly working on it.

Also I told you Glatezemann, I'm not really confident with your energy spent on Direct3D10 API as It is a legacy API, that is redundant with a subset of D3D11. D3D11 and D3D11.1 are almost identical, so you should be able to target desktop as well as metro style app with just a single rendering system. But D3D11 will require more work, as there is no more Effects framework (Mircosoft recommends not to use it anymore). Also developing with Win8 and .NET 4.5 Core profile gives a good hint about what can be safely used from .NET framework in order to pass Win8 certification (The .Net 4.5 Core profile is much more skimmed than the full .NET 4.5 profile). The good point is that you don't need to develop .NET 4.5 Core compatible assemblies under Win8 as It is possible to do it from Win7 with VS2011 installed (look at SharpDX solution build files, there is a workaround to use .NET 4.5 Core profile).

Jan 5, 2012 at 10:02 AM

@Alex: Yes, I share your concerns regarding DX10/DX11. I've already started to work on DX11 in parallel and will drop the DX10 version to low priority after having a stable DX11 version. It is currently a little bit less effort to work with DX10 because everything a XNA port needs is DX10. Most of the code is the same in both versions but but the changes regarding effect files makes life a little bit more complicated when using DX11.


Jan 5, 2012 at 1:05 PM

When I was working on an internal SharpDX.Framework.Graphics, I wrote a binary fx file loader in C# that can be used to load a binary fx file (compiled with D3DCompiler). The fx loader is only used to discover annotations/techniques/passes, vertex/pixel shaders bycode, blend/depth/rasterizer states. The variable binding part with constant buffer construction is better to be done with the standard D3D11 reflection.

If you would like to load fx files with D3D11 you can freely use this code in ANX, but I agree that It is a substantial work to support legacy fx files (and not sure It is worth it).

Jan 5, 2012 at 1:33 PM

I will have a look at this, thank you... I think it will be very helpfull. We've not yet decided how we want to deal with this. XNA depends on FX-Files and it shouldn't be a big deal to break this for ANX, but I want to have it stable first...


Jan 7, 2012 at 2:13 PM

PLS Multiple Render Targets Support !!!!!!!!!!!!!!!!!!!!!

Jan 7, 2012 at 2:14 PM

xna does not support this.

but the ability to use the depth buffer as Input to a shader will be VERY usefull =P

Jan 9, 2012 at 2:36 PM

I will work on MultipleRenderTargets for the next release (see feature #559: [workitem:559])


Yes, I know that Depth-Buffer input for a shader is very usefull but referring Shawn Hargreaves this is not possible on all gpu's. That's the reason why it is not supported by XNA. I think I will add this later on for the extended version of ANX.


Jan 10, 2012 at 4:24 PM

Simple Question:

How the XNA will deal with the half pixel offset problem ?
In xna we have to apply this in certain circunstances (like when processing fullscreen quads), but in DX 10 we dont.

How ANX will behave ? Like DX 10 ?? =P

In this first version, will you let us access special Directx 10 features (like Geometry Shader, Stream Out ...)  ? or you will follow the xna "specification" for now ?

Jan 10, 2012 at 8:16 PM

ANX will behave like the selected RenderSystem. For DX10, DX11 and OpenGL there's no need for the half pixel offset as far as I know. If someone knows how to emulate the XNA/DX9 behaviour on the other system without performance issues it is maybe a good idea to emulate it.


The first version of ANX will try to match the xna "specification" as far as possible. If there's something interesting or an easy to implement feature I will have a look at it and add it to the "extended profile". If someone want's to send a patch for such features, he or she is welcome ;-)


Jan 13, 2012 at 5:44 PM

For what it's worth, I don't XNA api's that correspond to DX9/10 APIs that are deprecated in DX11 should be a very big priority. These features are in danger of being deprecated in a future version of XNA as well, if there's ever going to be one.

On top of that, the last time I used custom effects in an XNA game was in the XNA 2.x timeframe. All my recent work has just been using the reach profile on windows phone 7.

And, honestly, if all ANX had was Game, GameComponent, SpriteBatch, input API, and SoundEffect and their dependencies, I could ship a game with that.