Category: SlimDX

Posts about SlimDX.

Follow-up on DirectX/XNA

Received today, and hopefully the “you can quote me” part means this is an exception to NDA because it’s important:

The message said “DirectX is no longer evolving as a technology.” That is definitely not true in any way, shape or form. Microsoft is actively investing in DirectX as the unified graphics foundation for our key platforms, including Xbox 360, Windows Phone and Windows. DirectX is evolving and will continue to evolve. For instance, right now we’re investing in some very cool graphics code authorizing [sic] technology in Visual Studio. We have absolutely no intention of stopping innovation with DirectX, and you can quote me on that. 🙂

My intent was not to start a firestorm of questioning on DirectX’s future viability, and I said up-front that I felt that communication was poorly worded with regards to intent. My frustrations were also apparently poorly worded. Since I accidentally launched this, let’s clear up a few things.

Number One: In the absolute (and implausible) worst case scenario that MS really scales back their Direct3D support to a minimum, that situation is still better than OpenGL. The Direct3D system is a technically superior piece of technology, and support for working with it is still better than OpenGL whether you’re a hobbyist or a pro. I cannot emphasize this point enough, so for the love of god stop bringing up OpenGL. It’s a badly designed API and has been since I started doing this in 2000.
Number Two: A new picture is coming into focus that shifts a lot of the DirectX SDK’s burden onto VS. This hasn’t been made previously clear to us on the MVP side. As I’ve begun to explore the tools already inside VS 2012, I like what I’m seeing. It’ll take some time to see how it all plays out, but in a very real way having Direct3D integrated into core VS development is a serious promotion.
Number Three: There’s more content in today’s email regarding XNA which I don’t care to share, thanks to a stern NDA reminder. (Ironically, when MS finally gives us what they should be saying to the public all along, I can’t share it.) But this is very much a case of “put up or shut up” and defending XNA’s status as a serious technology seems patently ridiculous to me right now. The community, whether it’s my work or someone else’s, has stepped in to integrate .NET and DirectX for many wonderful use cases. But there are things we can’t do (like Xbox) and it’s clear that matters to a lot of people. It’s not clear that it matters to Microsoft.

That said, I am not walking back my actual complaints about how DirectX and XNA are being handled. I like the work that’s been done in integrating VS and DirectX, which is arguably many years overdue. That doesn’t make everything else okay. The fact that we’re having this discussion, the fact that my dashed off blog post exploded on Twitter, the fact that clarification had to be written up behind the scenes — this is a problem. Which brings me at long last to the actual point I was trying to make yesterday:

As developers, we need Microsoft to communicate clearly with us, in public. As MVPs we were asked to act as community representatives, to guide everyone interested in the tech and have an open line on future development. Apparently that means we get half-hearted vague emails from time to time that dodges our serious questions and casts further doubts about the status of the technology and teams, all covered by an NDA agreement. And then, shockingly enough, people get the wrong idea. We’re sitting on the outside, trying to play this stupid guessing game of “which Microsoft technology is alive?” XNA doesn’t support DirectX 10+ or Windows 8, but it’s still a “supported product”, as if that means anything in the real world. Windows XP is still a “supported product” too.

It shouldn’t take a leaked email to force a straight answer.

DirectX/XNA Phase Out Continues

—
Please read the follow up post.
—

This email was sent out to DirectX/XNA MVPs today:

The XNA/DirectX expertise was created to recognize community leaders who focused on XNA Game Studio and/or DirectX development. Presently the XNA Game Studio is not in active development and DirectX is no longer evolving as a technology. Given the status within each technology, further value and engagement cannot be offered to the MVP community. As a result, effective April 1, 2014 XNA/DirectX will be fully retired from the MVP Award Program.

There’s actually a fair bit of information packed in there, and I think some of it is poorly worded. The most stunning part of it was this: “DirectX is no longer evolving as a technology.” That is a phrase I did not expect to hear from Microsoft. Before going to “the sky is falling” proclamations, I don’t think this is a death sentence for DirectX, per se. It conveys two things. Number one, DirectX outside of Direct3D is completely dead. I hope this is not a shock to you. Number two, it’s a reminder that Direct3D has been absorbed into Windows core, and thus is no more a “technology” than GDI or Winsock.

Like I said, poorly worded.

There are a few other things packed in there. XNA Game Studio is finished. That situation has been obvious for years now, so it also should not really come as a surprise either. And finally the critical point for me: our “MVP” role as community representatives and assistants is appreciated but no longer necessary. On this point, the writing has been on the wall for some time and so I should not be surprised. But I am. Maybe dismayed is a better word.

As I’ve said previously, I don’t feel that the way DirectX has been handled in recent years has been a positive thing. A number of technical decisions were made that were unfortunate, and then a number of business and marketing type decisions were made that compounded the problem. Many of the technologies (DirectInput, DirectSound, DirectShow) have splayed into a mess of intersecting fragments intended to replace them. The amount of developer support for Direct3D from Microsoft has been unsatisfactory, and anecdotal reports of internal team status have not been promising. Somebody told me a year or two back that the HLSL compiler team was one person. That’s not something you want to hear, true or not. Worst of all, though, was the communication. That’s the part that bugs me.

When you are in charge of a platform, whatever that platform may be, developers invest in your platform tech. That’s time and money spent, and opportunity costs lost elsewhere. This is an expected aspect of software development. As developers and managers, we want as much information as possible in order to make the best short and long term decisions on what to invest in. We don’t want to rewrite our systems from scratch every few years. We don’t want to fall behind competitors due to platform limitations. Navigating these pitfalls is crucial to survival for us. Microsoft has a vested interest in some level of non-disclosure and secrecy about what they’re doing. All companies do. I understand that. But some back and forth is necessary in order for the relationship to be productive.

Look at XNA — there have been a variety of questions surrounding it for years, about the extent to which the technology and its associated marketplace were going to be taken seriously and forward into the future. It is clear at this juncture that there was no future and the tech was being phased out. Direct3D 10 was launched in late 2006, a bit over six years ago, yet XNA was apparently never going to be brought along with the major improvements in DWM and Direct3D. How long was it known internally at Microsoft that XNA was a dead-end? How many people would’ve passed over XNA if MS had admitted circa 2008 (or even 2010, when 4.0 was released) that there was no future for the tech? The official response, of course, was always something vague and generic: “XNA is a supported technology.” That means nothing in Microsoft world, because “it will continue to work in its current state for a while” is not a viable way for developers to stay current with their competition.

Just to be clear, I don’t attribute any of this fumbling to malice or bad faith. There’s a lot of evidence that this type of behavior is merely a delayed reflection of internal forces at Microsoft which are wreaking havoc on the company’s ability to compete in any space. But the simple ground truth is that we’re entering an era where Windows’ domination is openly in question, and a lot of us have the flexibility and inclination to choose between a range of platforms, whether those platforms are personal computers, game consoles, or mobile devices. Microsoft’s offer in that world is lock-in to Windows, in exchange for powerful integrated platforms like .NET which are far more capable than their competitors (eg Java, which is just pathetic). That was an excellent trade-off for many years. Looking back now, though? The Windows tech hegemony is a graveyard. XNA. Silverlight. WPF. DirectX. Managed C++. C++/CLI. Managed DirectX. Visual Basic. So when you guys come knocking and ask us to commit to Metro — sorry, the Windows 8 User Experience — and its associated tech?

You’ll understand if I am not in a hurry to start coding for your newest framework.

Before things get out of hand: No, you should not switch to OpenGL. I get to use it professionally every day and it sucks. Direct3D 11 with the Win8 SDK is a perfectly viable choice, much more so than OpenGL for high end development. None of the contents of my frequent complaints should imply in any way that OpenGL is a good thing.

SlimDX Status Report

Alright, we’ve talked DirectX and XNA already so let’s move on to the subject of SlimDX.

First off, there’s a release coming any day now. A number of things were screwed up with the September 2011 release, mostly my fault, and I’ve been busy patching them up. So there’s a new December 2011 release around the corner, and 4.0 runtimes will be available right at the start. I do want to point out, though, that the runtimes are strictly for end-users (non-developers) who are consuming SlimDX apps. You don’t need them to develop, and for that matter you probably don’t need them at all if you’re at a game development company. They install the DX runtimes, VC runtimes, and SlimDX itself. Given that both runtimes are now well over a year old, odds are you already have this stuff. While that doesn’t excuse my personal failures in getting this stuff out in a timely fashion, there is almost certainly no need to worry over it for 90% of you.

We’ve been promising a SlimDX 2.0 release for some time now, with substantially revised architecture. The redesign is based around many of the same concepts driving another wrapper library called SharpDX by Alexandre Mutel. Alex was working with us for a while but we split up over some mutual differences and went our separate ways. I’ve decided to withhold any comments on his work one way or the other. As far as our work… we need help. The three of us (Josh Petrie, Mike Popoloski, and myself) have been working on the library for something like five years, and things are pretty stable at this point. Sure there are bug fixes that we’re shipping out, but especially now that the DirectX SDK updates have stopped, the current codebase is largely good to go. The new codebase for 2.0 is really a prototype, and the simple fact is that it needs a lot of work and none of us has the time anymore.

I repeat: We need new people to help develop SlimDX. If that doesn’t happen then we’re likely stuck in place, which might not be that big of a problem except for one thing: Windows 8. SlimDX 2.0 is based on a code generation system that should allow us to target C++/CLI as well as the new C++/CX language. With CX support we get not only .NET but also JavaScript and native code support to interop with Metro apps. Not only that, but it also means ARM support and SlimDX on tablets in the coming years. I think that’s a big deal, if we can pull it off.

When I first wrote SlimDX in 2006, I believed that automated codegen like SWIG was not well suited to creating a simple, usable wrapper. SlimDX was hand written from the ground up to make using DirectX as painless as possible, and also to reshape the DirectX API into something that made sense as a .NET API. That was directly in the footsteps of Managed DirectX which Tom Miller had created, though we took the model a lot farther in that direct path. Alex came to us with an approach for code-gen which we felt really has potential, but there’s still a lot of rough edges and a lot of work in getting it to the standard which we really want it to be at.

So, who can help? You’ll need to have a working familiarity with C++ and C#, and DirectX of course. It is not, contrary to popular belief, necessary to really deeply understand any of these things. Working on SlimDX is an adventure in quirks and details of interop that I can almost guarantee you have not seen. Don’t worry about experience if you’re looking to help out. There will be a lot to learn of course, and you’re going to need a lot of free time to commit to this, but we’ve spent a long time building SlimDX and have a pretty solid handle on what’s going on. The only other requirement is the understanding that what you get out of this is experience, an excellent resume item, and skills that are fairly rare. Money is very unlikely to appear directly unless donations take a serious uptick.

If you’re interested in helping out, please post here, or ping us via Twitter or IRC or e-mail or GameDev or whatever. I really do need one or two people to join as regular developers, otherwise DirectX and Windows may well move forward without a SlimDX to help glue the bits together.

Moving Away From Godaddy

Just a quick update here: My domains, primarily SlimDX.org and SlimTune.com but a few others as well, are currently hosted by GoGaddy. Now GoDaddy is a company with a long, messy history of being a third tier sleaze-bag registrar, but I stuck with them because of pricing. However their recent support of SOPA, and their pathetic recant, pushed me over the edge.

Effective immediately, I am shifting all domains away from GoDaddy. Because I’m rather new to this process, I don’t know what will happen to DNS and email during the transition. SlimDX or @slimdx.org addresses may become inaccessible for a short period while I sort things out. Please bear with me.

If you are interested in moving your own domains, I found out that NameCheap is running a promotion with code “SOPAsucks”. Their pricing is not quite as aggressive as GoDaddy but it appears that they do offer very competitive pricing ($2 specials) nonetheless. Transfers with the code cost $6.99 per domain, which includes a year renewal of the domain. I am sure there are other anti-SOPA registrars but this one is mine.

Software and Projects Using SlimDX

Man it’s been a long time since I posted here. Company is going great. It’ll probably be a few more months until I can really say anything, though.

I’ve decided to keep up a list of the various software packages and other projects where SlimDX is used. This used to live on our wiki, but that was killed off a long time ago. I’ve also been somewhat cagey about what games are built on SlimDX, but I may as well make the listing public. Can’t think of a good reason not to. If I’m missing anything, please feel free to post a comment or drop me an email.

These are in no particular order. All of them are for Windows platforms.

ClickOnce Support in SlimDX

Man, it’s been a long time since I wrote about SlimDX. We’ve released the February 2010 version today, so go ahead and grab that if you’re so inclined. This version is mostly bug fixes, for both us and Microsoft. DirectX 11 should be much more usable, although we’re still working towards stronger D2D and DWrite implementations. In the meantime, I wanted to discuss a feature that was included too late for documentation to catch up: ClickOnce support.

ClickOnce has actually been on the to-do list for a very long time, but it ended up quite far down the priority list thanks to a lack of user demand. For the February 2010 release we’ve gone ahead and included it. The installer will set it up for VS 2008 and VS 2010; we’ve dropped 2005 support across the board so no ClickOnce there. There are a few quirks to setting it up properly though, so I just want to explain what you need to do in order to make sure it works properly.

First of all, make sure you’ve got a reference to the GAC version of SlimDX in your project (via the .NET tab in Add References). Also check the properties of the SlimDX reference; the default is Copy Local = True and that should be set to False.

Once you’ve done that, go into your project’s properties and select the Publish tab. This is where you set up all of the ClickOnce options and actually produce a distribution. If you press Application Files, you should see SlimDX.dll listed as Prerequisite (Auto). If it’s something else, you’ve got the previous step wrong.

Next, hit the Prerequisites… button. Somewhere in the listbox, you’ll see “SlimDX Runtime (February 2010)”. Check the box and press OK.

That’s it. Pretty easy, huh? Now when you publish, the SlimDX runtime will be included with your application and run automatically as part of the ClickOnce installation.

Advisory: You Should Probably Use FpuPreserve

One of the create flags for D3D 9 devices is FpuPreserve. It tells the Direct3D runtime that you don’t want it to mess with the FPU flags, which it does to improve performance. And you should probably be using it.

FPU computations are a really hideously messy area, one that makes my head spin when you get into the details. One of the cool things .NET does is to take away most of the complexity and make very simple, straightforward guarantees about how floating point code must behave. Operations are done at specifically defined precision, in a certain way, and the runtime must enforce these requirements during code generation. (Which creates some weird x86 code.)

When DirectX goes in and messes with FPU state, it apparently throws off what .NET expects, leading to weird bugs of various sorts. So unless you’ve got some problem with FPU performance that can be solved by switching to the faster FPU states (hint: you don’t), it’s probably a good idea to simply set FpuPreserve all the time.

[EDIT] I forgot to mention as an addendum that as part of the SlimDX 2.0 transition, it’s very likely this flag will become the default.

SlimDX August Release Plan

I probably don’t need to tell you that it has been an incredibly long time since the last SlimDX release. That’s because it has been an incredibly long time since the last DirectX release. The reason seems to be somewhat quirky schedule planning on Microsoft’s part; basically they’ve decided to hold out on the next SDK until they have a completely stable Windows 7 compatible release. (IMO they should’ve done a release in June but okay fine.)

I do know two things. One, the SDK is branded as August, so unless they screw this up really badly it should arrive soon. Today is Wednesday; my guess is it’ll show up Friday mid-day. I have confirmed that there’s a bunch of new functionality coming, which of course we’ll have to wrap. That will take some time. Not sure exactly how much, but it will be at least a few days to write and check that code. IOW, our August release will actually come out in early September sometime, hopefully before Labor Day. It will have fully merged support for 10.1, 11, and Direct2D. DirectWrite remains as a maybe.

SlimDX Performance Tips and Tricks

Previously, I discussed some of the inherent performance costs that SlimDX suffers. Although that’s somewhat educational if you’re evaluating SlimDX, it’s pretty useless if you’re already using it and would like to get the most out of your code. This time, I’ll go over what you can actually do to make sure you’re running optimally.

There are two big problems with managed vector/matrix math, and this applies just as well to XNA. First, all of the types are value types, and passed by value to operators. That means when you multiply two matrices via operator*, two matrices (32 floats, 128 bytes) are copied onto the stack, and then another one is copied back into your result. This can get quite expensive, and the solution is to pass by reference, not by value. Unfortunately that means operators are a problem for performance sensitive code; you’ll have to use functions like Add and Multiply instead.

There’s also the problem that generally speaking, vector operations are not candidates for inlining. They’re too big for the JIT’s metrics to pick them up as inlining candidates (the 3.5 SP1 revision may have changed this). For small vector operations, this can again become a substantial cost. Unfortunately this is a messy one to deal with, as you can’t ask the compiler or JIT to inline things for you. The most effective approach I’ve seen is to replace vector operations in stable code with hand-inlined code. Farseer Physics uses this method, and wraps the inlined blocks in #region to clarify what’s going on. Yes it’s incredibly tedious, but if that’s what you have to do, then there it is.

Don’t use strings as effect handles if you can help it. We have to convert from Unicode to ANSI internally, and create a temporary handle. This gets slow and can cause other bugs as well. In future releases, this problem will actually be alleviated somewhat, but it’s best to avoid it completely.

Also make sure that SlimDX itself is configured correctly. These settings in the Configuration class. For example, object tracking is an incredibly useful debugging feature that tells you what objects you’re leaking and where they came from. But because it records call stacks, it’s also quite expensive. The default setting is for it to be active; turn it off for production builds. Also consider disabling exceptions for return codes you don’t care about (device lost and device not reset are common ones), instead of catching and ignoring.

Be careful with get properties and functions. An object’s Description property will always call GetDesc() on the underlying object, and then return a whole struct. This can get expensive quickly, especially if you casually access the property multiple times. We’ve chosen not to cache much of anything in SlimDX for the time being due to some nasty bugs early on. Querying data is expensive as a result.

Anything involving callbacks and callback interfaces is bad news, and it’d be best to avoid them for performance critical code. Every time you cross the boundary from managed to unmanaged or back again involves overhead, and for callbacks we end up bouncing multiple times — all while doing various kinds of fix up and data marshaling. Texture.Fill in particular is incredibly slow.

If you’re working with large amounts of raw data that will be sent to SlimDX, consider using DataStream, especially as a replacement for (Unmanaged)MemoryStream. When you give SlimDX a generic Stream to work with, it has to allocate a buffer large enough to hold the data, read all the data into the buffer, and then copy that into the target native DirectX buffer. This is quite inefficient for certain types of data that are already in memory. If you hand us a DataStream, we can skip the allocation and read, doing a fast memory copy only.

Hopefully that’s helpful. I’ll update this post as I remember more tips.