• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Promit

SlimDX -- A Prototype MDX Replacement Library

96 posts in this topic

This thread is obsolete. Please visit the SlimDX homepage instead. Why: Around fall of last year, there were a couple events involving the future of Managed DirectX. MDX 2.0 was discontinued, along with assistance from a surprise time bomb. MDX 1.1 is frozen and is essentially our only option for interfacing DX and .NET. XNA rose to "replace" MDX 2.0, but my work with XNA convinced me of two things. First, XNA is an Xbox API that happens to run on PC as a convenience. Second, XNA is a toy right now and will not be useful as a serious development tool for some time. This left MDX developers in an akward place. Yes, MDX 1.1 is supported for several years, but the current state of affairs is not exactly encouraging. Additionally, researching the loader lock problem yielded considerable explanation of why the problem exists, but I was unable to find evidence that the problem is a false positive. That is, every application built on MDX 1.1 may have a non-deterministic deadlock risk due to mistakes in the Managed C++ stuff in .NET 1.1. I'm not really sure if the problem exists or not, but I was not happy with the situation and I have yet to see a convincing technical description of why the loader lock warning isn't a danger. Lastly, there were some design things in MDX that I didn't like. Some were minor issues, some were bigger issues. It was the combination of these three factors that led me to build a replacement library in C++/CLI that would allow me to pull free of this whole mess. The library is somewhat tailored to my specific needs, so I can't reasonably claim that it is suitable for everyone else, or in fact anyone else. However, I felt that it was worth gauging initial interest in the codebase. Status: ALL non-D3D technologies are currently missing from this prototype. I would like to add them eventually, but they're not in right now. As far as the D3D stuff, this library was built by tearing MDX out from under my latest project and replacing it with SlimDX. As a result, I've essentially implemented the subset that I use. There are a few conspicuous omissions. First, the entire fixed function pipeline is missing. Very nearly all of the render states are missing. None of the Get* functions are implemented on the device, and honestly, most of the Set* functions are missing too. There are holes in the math library, particularly when dealing with quaternions and Vector2. There are two specific bits which were omitted by design. First, all of the event stuff is completely gone. Second, resources are not automatically released. If you do not dispose something, it will leak. I don't intend to introduce the event structure. However, I'm still examining the automatic release thing, so that's not nailed down yet. My thinking on this point is that automatic release disables D3D's leak detection and makes it harder to track code mistakes where things were not disposed. However, I do know that some people use automatic release as a crutch and are not disposing at all. One possibility is adding a flag to switch automatic release on and off, similar to how MDX allows you to enable or disable exceptions and events. This thing is a prototype, not a production library. If you need a stable, complete DX wrapper under you, switching to this thing now would be ill advised. Future: There are two possibilities here. One is that people simply don't care. I'm fine with that, and I'll simply continue using the library and filling in stuff as I see fit. The other is that there is substantial interest. In that case, I would like to license out the library under a non-restrictive open source license (possibly LGPL) and make it available at Sourceforge. The hope is that people will be willing to fill things in that they use, and the library will expand to fit people's needs as a result. This only works if people are actually willing to submit patches; otherwise, the library just stagnates. [Link Removed] Again, I originally wrote this for myself. If you don't think it's worth the bother of making it public, feel free to say so. Still, I have seen a lot of complaints about the current state of DirectX and managed code, so I'm curious how many people are actually dissatisfied with Microsoft's choices on the matter and would prefer to work with an open source library. [Edited by - Promit on June 19, 2009 10:04:23 AM]
1

Share this post


Link to post
Share on other sites
Hmm..Ralf Kormann (Deimrug or Demirug on GDNet) is already working on an MDX replacement as well, integrating it into his MD3D10 project (MIT license). I was planning on joining him in development earlier, but I've been kept back by some delays in the Overlay library. Perhaps you two can join forces?
2

Share this post


Link to post
Share on other sites
It doesn't really make much sense to me to have D3D9 and D3D10 as part of the same project. I'm also not sure where he plans on going with his, as there seems to be no particular talk on the codeplex page about it.

Also, is there any reason to choose codeplex over sourceforge?
1

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
It doesn't really make much sense to me to have D3D9 and D3D10 as part of the same project.

They could be separated. That's his call, though.

Quote:
I'm also not sure where he plans on going with his, as there seems to be no particular talk on the codeplex page about it.

Yes, because it originated after a discussion in the private MVP newsgroup. Again, we should just wait for him to chime in.

Quote:
Also, is there any reason to choose codeplex over sourceforge?

They use Team System for source control, which I prefer. Also, its integration with VStudio is much better than SVN. Their user interface is friendlier in my experience. Their "source code" page gives a much better review of changes to the code over time.

That's about it.
2

Share this post


Link to post
Share on other sites
The Direct3D 9 and 10 elements life in two namespaces and share only some general things like rectangles, boxes, …

As all referenced DLLs (DXGI, D3D10, D3D9, …) are marked as delay load it would work without problems on Windows XP.

If someone doesn’t need the D3D10 part it could simply be ignored.
2

Share this post


Link to post
Share on other sites
The core (D3D9) is nearly complete but D3D9X is still mostly missed.
2

Share this post


Link to post
Share on other sites
Whilst it wouldn't be easy, I think there would be an enormous amount of value in getting any MD3D9 and MD3D10 interfaces similar.

Obviously they can't be identical - but to use the same design guidelines, rules and so on could smooth out transitions as well as help those cross-targetting 9 and 10 (or would that explode on dependencies?).

Jack
2

Share this post


Link to post
Share on other sites
As I am prefer not to move to far away from the original concepts of both APIs writing a multi API application would as complex as with C++.
Normally I want keep this secret until I can show you something but I want to add a third Direct3D namespace. “Universal Direct3D” (work name) would be an API that maps to Direct3D 9 and 10 at the same time. If anything works out right it should be possible to write applications that use the same source code for 9 and 10. But before I can add this to the managed Layer I need a native C++ implementation first. It will mostly based on the new Direct3D 10 concept but adding some element from D3D9 like the caps, device resets, …
2

Share this post


Link to post
Share on other sites
Quote:
Original post by Demirug
As I am prefer not to move to far away from the original concepts of both APIs writing a multi API application would as complex as with C++.
I agree - just because .NET is a higher level language doesn't magically make this sort of thing easier.

It was difficult to make my idea clear, but basically I meant having the same design philosophy for MD3D9 and MD3D10 rather than making them source-code compatible or making some trivial "auto-porting" API.

Say a D3D9 developer picks up Promit's MD3D9 API and later wants to check out D3D10 so moves over to Ralf's MD3D10 implementation. If they were somehow 'aligned' then it'd make this transition a whole lot easier, rather than having to go back to square-1 and re-learn a whole different way of interacting with what is, under the covers, a fundamentally similar API.

Anyway... I'm going to stick this thread for a bit to encourage some further discussion. I get the distinct impression there are various members of the community who want to do something about Managed DirectX yet there seem to be a number of blocking factors involved in actually getting it moving forward. Maybe putting this topic in the spotlight will generate the right sort of interest to get things rolling...?

Cheers,
Jack

2

Share this post


Link to post
Share on other sites
This is almost the exact thing that I was considering doing, and I still have come to no definite conclusion. I haven't liked the look of XNA, particularly the lack of freedom when doing things in Windows, as you have said, XNA is an XBox library with Windows tacked on.

I think that providing a library for this is a great idea, and I just need something that I can focus my attention on. Basically, I am looking for some sort of stability in the world of managed games, and so far I am not getting it from Microsoft. Perhaps a community developed library on top of the more stable DirectX 9 and the forthcoming DirectX 10 would be the sort of stability needed for more developers to get on board with managed languages for games.

I would definitely also love to help out in any way possible. I think, however, that someone should sit down and think things through, before you start doing anything more substantial. There is, of course, no good reason to have both of you developing independent libraries, when everyone working on one would yield much better results, and a lot less wasted code and time. The two APIs for DirectX 9 and DirectX 10 should definitely by combined, but the core components should be separate from each other, with only the supporting classes merged together for code reuse as well as to facilitate the usability of the library.

Frankly, I think it is a great idea, and for some reason I trust members of this community to get it right more than I trust Microsoft. Their actions lately have shaken my faith in anything they put out as far as managed game libraries go. Hopefully this can grow into something that will become the DirectX of the managed world: stable, easily used, widely documented, and fully featured.
1

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
It was difficult to make my idea clear, but basically I meant having the same design philosophy for MD3D9 and MD3D10 rather than making them source-code compatible or making some trivial "auto-porting" API.

Cheers,
Jack


Whenever is it possible I try to use the same approaches for both APIs. Like the rules for the object ownership.
2

Share this post


Link to post
Share on other sites
For anybody watching, SlimDX is being hosted over at Google Code here. You can follow the development and grab the latest (still very much "in progress") code there.
2

Share this post


Link to post
Share on other sites
Any particular classes which people find important? All the really popular stuff like textures, surfaces, buffers, graphics stream, font, and sprite are in. Also the math library is progressing nicely, though Vector2 and Vector4 are missing bits, as is Quaternion.

We also wrapped up XInput completely. There's little bits of DirectInput, but not a lot yet.

By the way, the "slim" in "SlimDX" is serious. We're stripping out a lot of unnecessary cruft. No CustomVertex stuff. No ToString() overloads. That sort of thing. There's also a big emphasis on improving orthogonality, which was a huge problem in MDX. The math library is heavily simplified (and will probably be performance tweaked later, thanks to research Washu has been doing -- check his blog). Consider loading textures in MDX -- do you want new Texture, Texture.FromSomething, or TextureLoader.FromSomething? SlimDX makes it simpler. No more texture loader. If you want to load from a source, you use Texture.FromSomething, and you use new texture to create a blank texture. Also, you can load directly from memory now. You couldn't do this in MDX; the best you could do was to use a MemoryStream, which caused an extra copy internally.

Anyway, just wanted to give an update.
1

Share this post


Link to post
Share on other sites
I like this project and I love that you deviate slightly from the original API to make it all a little more obvious.

Classes/structs that I'd like to see are the obvious ones, I am not working with anything out of the ordinary (yet). Oh, please don't lack device/displaymode/capabilities enumeration.
2

Share this post


Link to post
Share on other sites
Some of it is there, it isn't quite fleshed out. I'll go ahead and put that in soon, probably another day or two.
1

Share this post


Link to post
Share on other sites
Effect is very close to complete, metadata/reflection and all. The stuff that's missing is include/macro/pool/state manager. The lower level shader stuff hasn't been written in, since I have yet to encounter code that is actually using it. (Same story for the missing effect helper junk.)
1

Share this post


Link to post
Share on other sites
As of now I am soley a c# programmer. If I'm reading right then SlimDX is a wrapper for Unmanaged DirectX. Is this correct?

Anyways, I think it's a super idea. I can see that it could actually become better than the original?

-Devin
1

Share this post


Link to post
Share on other sites
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]?
2

Share this post


Link to post
Share on other sites
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.
2

Share this post


Link to post
Share on other sites
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]
1

Share this post


Link to post
Share on other sites
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.
2

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 0