SlimDX -- A Prototype MDX Replacement Library
I just wanted to say this looks really interesting and I hope it doesn't just flop (But I doubt that will happen with people like Promit behind it).
So, wanna give us any info on how this is progressing [smile]?
So, wanna give us any info on how this is progressing [smile]?
You can watch the progress over on the Google Code page. SlimDX is currently functional enough so that my rendering engine can compile against it (some minor modifications were required because one of our goals with SlimDX is to actually keep it slim, and thus we're not supporting a lot of redundant methods to accomplish the same thing). And obviously since Promit originally wrote it for his own use, his code will compile against it.
We've got some sample code that currently will not compile against SlimDX, so we're working to get that happening. It would be a lot of help if other people would download and build the library (the build process is very straightforward, it's just a solution file) and try to use it themselves and give us feedback about what functionality is missing that you need.
The best way to do that is probably via the project's bug tracking interface, but I suppose you could also post issues here and/or find one of us in #gamedev or #graphicsdev on IRC.
We've got some sample code that currently will not compile against SlimDX, so we're working to get that happening. It would be a lot of help if other people would download and build the library (the build process is very straightforward, it's just a solution file) and try to use it themselves and give us feedback about what functionality is missing that you need.
The best way to do that is probably via the project's bug tracking interface, but I suppose you could also post issues here and/or find one of us in #gamedev or #graphicsdev on IRC.
I use MD3D9 and I want to move to DX10 when things will be more clearer.
in my opinion there is no point moving to XNA when waiting for MD3D10.
I have some concerns for example i use Physx .Net wrapper over there:
http://www.zelsnack.com/jason/JttZ/Novodex_NET_Wrapper/
I made some progress with it and i dont want to waste all my progresses for Physx .Net wrapper when porting my codes from one wrappers to another.
And also i think there is much more wrappers made for MD3D9.
Demirugs idea of “Universal Direct3D” is great or at least DirectX 9 and DirectX 10 should be combined.
We must not trash all wrappers we made so far.
If this “Universal Direct3D” ideas come true, it will be a great success.
[Edited by - CoRe_eYe on June 28, 2007 1:48:15 PM]
in my opinion there is no point moving to XNA when waiting for MD3D10.
I have some concerns for example i use Physx .Net wrapper over there:
http://www.zelsnack.com/jason/JttZ/Novodex_NET_Wrapper/
I made some progress with it and i dont want to waste all my progresses for Physx .Net wrapper when porting my codes from one wrappers to another.
And also i think there is much more wrappers made for MD3D9.
Demirugs idea of “Universal Direct3D” is great or at least DirectX 9 and DirectX 10 should be combined.
We must not trash all wrappers we made so far.
If this “Universal Direct3D” ideas come true, it will be a great success.
[Edited by - CoRe_eYe on June 28, 2007 1:48:15 PM]
Quote:
If this “Universal Direct3D” ideas come true, it will be a great success.
While an interesting idea, I would imagine that in practice it might not be the most efficient way of doing things, since there may be some assumptions raised during the homogenization of both APIs since there are some concepts that are notably different. In other words, it would be cool, but production code might want to prefer to use the D3D9 or D3D10 specific APIs or simply homogenize it themselves (so they can control the assumptions, not the wrapper author).
In any case, this kind of API homogenization is not, to my knowledge, a goal for SlimDX. We'll end up with a D3D10 wrapper at some point (I'm not sure any of the developers on the project actually have a suitable D3D10 development environment at the moment), though, I'm sure.
This is great Promit, it's just what I've been looking for. I'll give it a shot tomorrow [smile]
So, thanks to much help from jpetrie and Washu, SlimDX's functionality has grown substantially. I would like to do our first versioned release soon. First, I'll briefly update you all on the status of various components:
Complete or nearly complete:
Query
SwapChain
Texture
VolumeTexture
CubeTexture
Effect
Font
Sprite
IndexBuffer
VertexBuffer
Surface
VertexDeclaration
FVF
XInput
In progress:
Device
Caps
Render states
Math Library*
Mesh
VertexShader
PixelShader
Resource
ConstantTable
DirectInput stuff
* Some parts of the math library have been deliberately omitted, usually where orthogonality was seriously broken. Poke around and check that a "missing" function hasn't simply been dropped in favor of a different variation.
Anything not mentioned is probably missing.
So in preparing for an actual release, I would very much like to hear what you guys consider make-or-break functionality, and what would really compel you to switch. Remember, this isn't hypothetical -- what you say will have direct impact on what is added in the near future. When this release hits, I want most people to be able to switch over with relative ease.
A couple quick notes on what's changed from MDX. As mentioned before, an emphasis on orthogonality and simplicity has led to the removal of certain functions and classes. (CustomVertex is gone, by the way.) The math library is a visible place where things may be removed. All creation of objects is now routed through the class being created -- operator new for a blank object, or .From* or .Create* for other things. The ability to load many objects directly, as well as from a stream or a file, has been added.
The error handling architecture has been improved considerably. Of note is the ability to disable certain subsets of exceptions. For example, device lost and device not reset can be disabled while leaving everything else active, which can lead to simplified and more efficient handling of these conditions. Similarly, the "was still drawing" exception can be disabled, enabling more efficient and robust handling of presenting with the D3DPRESENT_DONOTWAIT flag.
Seriously people, speak up. That last paragraph of changes was directly inspired by conversations with Tape_Worm and sirob. I'm actively implementing suggestions to make the library better.
Complete or nearly complete:
Query
SwapChain
Texture
VolumeTexture
CubeTexture
Effect
Font
Sprite
IndexBuffer
VertexBuffer
Surface
VertexDeclaration
FVF
XInput
In progress:
Device
Caps
Render states
Math Library*
Mesh
VertexShader
PixelShader
Resource
ConstantTable
DirectInput stuff
* Some parts of the math library have been deliberately omitted, usually where orthogonality was seriously broken. Poke around and check that a "missing" function hasn't simply been dropped in favor of a different variation.
Anything not mentioned is probably missing.
So in preparing for an actual release, I would very much like to hear what you guys consider make-or-break functionality, and what would really compel you to switch. Remember, this isn't hypothetical -- what you say will have direct impact on what is added in the near future. When this release hits, I want most people to be able to switch over with relative ease.
A couple quick notes on what's changed from MDX. As mentioned before, an emphasis on orthogonality and simplicity has led to the removal of certain functions and classes. (CustomVertex is gone, by the way.) The math library is a visible place where things may be removed. All creation of objects is now routed through the class being created -- operator new for a blank object, or .From* or .Create* for other things. The ability to load many objects directly, as well as from a stream or a file, has been added.
The error handling architecture has been improved considerably. Of note is the ability to disable certain subsets of exceptions. For example, device lost and device not reset can be disabled while leaving everything else active, which can lead to simplified and more efficient handling of these conditions. Similarly, the "was still drawing" exception can be disabled, enabling more efficient and robust handling of presenting with the D3DPRESENT_DONOTWAIT flag.
Seriously people, speak up. That last paragraph of changes was directly inspired by conversations with Tape_Worm and sirob. I'm actively implementing suggestions to make the library better.
Quote:Original post by Promit
So in preparing for an actual release, I would very much like to hear what you guys consider make-or-break functionality, and what would really compel you to switch.
I'd need to see SlimDX used by either a 3D engine or a major 3D tool. Could be a non-game tool. Who actually needs and will use SlimDX, driving its improvement and maintenance? You need to work on political relationships; try to get major 3D C# projects to use your library. Otherwise, you're up against a very basic problem: the game industry does not care about using C# in games. I do hear they use it for tools, though.
You should talk to the Jade engine guys. One of their bloggers was proclaiming that MDX would eventually go away and they have to prepare for it. I don't know anything about their project; other potential users are left as an exercise to the reader.
Quote:
Otherwise, you're up against a very basic problem: the game industry does not care about using C# in games.
This isn't really the goal of SlimDX, however. The games industry wasn't interested in C# for actual game code even before MDX was put into sustaining engineering mode, and it will take more than just an MDX replacement to catalyze adoption on that scale.
That said, however, in making the library available, we're attempting to solicit the kind of response you're talking about; to get others to grab it and try to build their projects against it, find out what functionality they need that is missing, and let us know about it so we can implement it. This generally has to start with smaller projects, who will be more amiable to dealing with the breaking API changes (since we have broken the interface in a number of places to streamline the library and reduce duplication); larger projects would like be less open to attempting to build against such a young library since it is virtually guaranteed they'd need to deal with a large amount of completely unimplemented functionality.
It's sort of like a grassroots thing.
I think that a good set of basic examples are pretty crucial to early adoption. Something like a NeHe for SlimDX, but perhaps rolling 2-3 of the simpler NeHe lessons into one. There needs to be some basic "Getting started with SlimDX" samples/tutorials to get started, with more advanced samples later.
Beyond that, some larger examples. Maybe port, or get someone to port, the freely available XNA projects (providing the liscense doesn't disallow it) like SpaceWar. I know from earlier in the thread that JPetrie has ported an MDX application of his to SlimDX, would it be possible to get an IOTD of that? It might garner some interest.
I'd also like to see a feature comparison chart between MDX, XNA, and SlimDX, since they are essentially aimed at the same task and user base(XNA to a slightly lesser extent). You could use this chart to also address the different approaches you've taken, ie: foo() is not supported by SlimDX, but its functionality has been replaced by bar(), which supports X in addition to foo()'s Y.
Step 1: Create a friendly, flexible API.
Step 2: Convince everyone that its a friendly, flexible API.
I might also suggest that some wrappers be created over the top of XNA. One of XNA's major advantages will be support for the 360 platform using essentially the same code. If its possible for SlimDX to match that bullet-point in the future, it might be worth considering.
Beyond that, some larger examples. Maybe port, or get someone to port, the freely available XNA projects (providing the liscense doesn't disallow it) like SpaceWar. I know from earlier in the thread that JPetrie has ported an MDX application of his to SlimDX, would it be possible to get an IOTD of that? It might garner some interest.
I'd also like to see a feature comparison chart between MDX, XNA, and SlimDX, since they are essentially aimed at the same task and user base(XNA to a slightly lesser extent). You could use this chart to also address the different approaches you've taken, ie: foo() is not supported by SlimDX, but its functionality has been replaced by bar(), which supports X in addition to foo()'s Y.
Step 1: Create a friendly, flexible API.
Step 2: Convince everyone that its a friendly, flexible API.
I might also suggest that some wrappers be created over the top of XNA. One of XNA's major advantages will be support for the 360 platform using essentially the same code. If its possible for SlimDX to match that bullet-point in the future, it might be worth considering.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
