For those of you who don't know, Microsoft just released the August 2007 DirectX SDK.  The release page is at:
http://www.microsoft.com/downloads/detai...laylang=en

Note, near the bottom, this nice, small section:

Microsoft has been very hesitant to say their future plans for Managed DirectX, other than a few employees on some boards mentioning not to expect anything related to this any time soon. They seem to be focused nearly entirely on XNA.

Before I go into this - I do want to say, right up front, XNA doesn't really get us anything in terms of Jade over MDX. Since we're writing a PC engine (we use a lot of non-compact framework things), it would never run on a 360. Also, since we're completely abstracting out the rendering, the end user would never use XNA directly - they'd be using Jade. XNA would just be a slower version of MDX for us.

After some research and some chatting with Vicente, we are thinking that we may want to move away from using the MDX1.1 libraries for rendering. They are now deprecated, with no 2.0 version ever to be released, and no plans for support or development at this time.

The three best options out there, right now, seem to be:

Stick with MDX. So far, MS hasn't said they're going to stop allowing distribution of the end user runtimes, so this is probably pretty safe. However, they have already done similar things to this with other parts of D3D (for example, there's no legal way to get D3DRM.dll onto a vista box, even though it works). For the long term, staying with a deprecated, unsupported tool doesn't seem like a great idea.

Another option: Use SlimDX - A free managed DirectX wrapper (C++/CLI based) being developed as a replacement for MDX. Just to test this, I've started implementing a rendering backend for Jade 2.0 using these libraries. It's in an incomplete state at the moment (so far, only text is rendering correctly - and I'm not sure why), although it does appear to be quite close to MDX, if not a little bit cleaner in terms of syntax. If anybody wants to jump in and help figure out how to fix this, that'd be great.

One nice thing about SlimDX is that the developers have also already started managed DX10 wrappers - so, when it comes time, Jade would have a fairly straightforward path towards developing a DX10 rendering backend.

Also, it does appear to be fairly active and maintained.

There is another potential option - since the rendering system is implemented as a separate assembly, and loaded via a plugin, we could actually implement it in C++/CLI instead of C#. This would entail some of us writing C++ code instead of C# code, but would let us work directly with the MS supported DirectX library code. Also, this removes another abstraction layer in the rendering pipeline, which would most likely boost performance. (Jade->RenderingSystem->D3D vs. Jade->RenderingSystem->MDX->D3D)

Since this isn't the main Jade assembly, and end users would never deal with it directly (other than saying to use it to render), there aren't any downsides from an end user's perspective - they're still just dealing with the main Jade assembly (which is all C#). The downside to this is that the developers working on the renderer need to know C++/CLI. I'd be more than happy to help port things in this directly, but I'm not sure if this is the best approach or not.

Anyways, I wanted to get some discussion going about this. Since we've just started this large rewrite, I think we're better off trying to figure this out now, and working with the tools we're going to want to use in the long term, instead of waiting and trying to resolve this later when/if it becomes a problem.

-Reed

Personally I favor the C++/CLI option. I know C++ (and especially C++/CLI) can be a real pain but it would remove the dependency to other peoples work and potentially give another speed boost.

If time is an issue I'd stick with SlimDX (if thats stable enough to use) and create the new direct renderer when the engine is stable.

Staying with MDX is not a very good option.

This post was last modified: 08-01-2007 01:56 AM by Quimbo.

The "end of MDX" day has come in the end :p Reed has done a very good analysis about our future options for Jade in the rendering arena for Windows.

I've been talking with Jader about this also, and well, I think that probably we should take the C++/CLI path. As Quimbo also said it saves us a dependency with another project (even if I think the work on SlimDX is very nice) and we don't really need a whole wrapper as we are using very small parts from DX right now. I think the speed boost in the engine will be pretty small (the wrapper should be quite thin) but this way we aren't adding more dependencies around to use only 10% of what they offer to us.

Keep the opinions coming people, this is quite an important affair right now, and maybe we are doing mistakes in our assumptions or there are things we haven't taken into account, so please post your point of view on this subject

Regards!

Vicente

I'd say going the C++/CLI path is the best way to go, too, since staying with MDX is no option and before simply exchanging one layer/wrapper with the other, doing our own ligthweight thing seems to be the best solution.
That way we have full control from ground up and we can extend it easily to bring in more DX functionality whenever we see fit. The only question that comes in my mind is: Who should do it?

My opinion is that we should wait. There is a lot of things to do ( animation!!!! ) yet, and who knows what expect to the future. Perhaps withing six months, OGL 3.0 will be a reality, DX10 will work on XP and there is some nice wrapper to use. We can work on the engine, and when most of the features are present, we can think on MDX. As i said, maybe there are a lot of new options at the future...

Of course there are always new options comming in the future, but what I'm worrying about a bit is that Microsoft could stop releasing MDX completely as redistributable soon... this would prevent new users from using the current renderer, so we should at least have an alternative renderer to go with as soon as this happens.

This post was last modified: 08-01-2007 03:31 PM by gonzo.

I like the idea of making a new rendering wrapper in C++/CLI as I have had plenty of experience with C++ that it should be easy for me to read. Though I would say this is something that can wait, as I would like to see JAD 2.0 up and running first.

Gonzo,

I highly doubt they would cut MDX entirely - they are not supporting it at this point, though, so the biggest fear would be having something like Vista sp1 (due out this year) causing an incompatibility with the current MDX, which in turn would cause MDX to stop functioning on Windows Vista.

I'm quite sensitive to issues like this - my company has actually been bitten by MS causing changes to the OS in a service pack that breaks old libraries, more than one time. If that happens, we'd have a significant period where nothing works, which is part of why I think it's important to at least bring this issue up.

Jader, I'm not too opposed to waiting, however, I do think that, if we're going to end up rewriting it to use C++/CLI, it'd be an easier transition now (since less is done) than later (when everything is in place). We do not use a large portion of D3D, so I don't think it would be that awful of a job.

OGL 3 will be a reality at some point, but it will be a while before people have hardware support for it. DX10 will probably never come to XP (MS has said this every time they've been asked, and it's in their best interest to keep it vista-only), and it looks like they have no plans to make or maintain their own managed wrappers other than XNA. That was why the C++ suggestion in the first place - C++ DX9 and DX10, and C OpenGL, are pretty much guaranteed to always exist, since that's how they are written natively.

But - even if official managed DX10 wrappers exist, we're still going to need a maintainable DX9 solution (at least for the next couple of years).

-Reed

Yeah, MS breaking apis in new releases happens more often than it should I agree also that moving now is more interesting than continue working on a renderer we don't plan to support in the end (it is like wasting work time even if it's not much time at all).

Also, I could bet MDX10 won't ever come to happen, like DX10 on XP. Microsoft wants all their users migrating to Vista and XNA so releasing something like that would go against their own goals.

Regards!

Vicente

Ok, so my prefered option is C++/CLI. It seems that we are doing all!!!!

Well - I started putting this in place, although it has quite a ways to go.

So far, I removed the SlimDX project, and started a new C++ project. (Jade.Rendering.Dx9) I have the adapters initialized, and the plumbing in place for device creation.  I'm trying to get the hang of writing code in C++/CLI, but the porting should go pretty fast.

There are actually some advantages to writing this in C++, I've found.  So far, with the little I've done, it seems that debugging is a bit more straightforward, since you're not trying to debug MDX and D3D at the same time.

Jader: Feel free to work with the MDX renderer still - if you want to add to it, please go ahead.  I've started implementing a C++ version, and will just copy over everything from the C#/MDX renderer when I get to that point.  Once I have the effect builder copied over, we can switch to developing against the new one.

-Reed

This post was last modified: 08-03-2007 01:45 AM by Reed.

Great job!!!

As usual, nice news Reed Regards!

Vicente

Sweet. I'm glad to hear its going well.

Cool, I would like to show (us) your work on the showcase area, so even more users could learn about JadeEngine.

Keep up the good work.