One of the biggest changes we’re going to make in SlimDX 2 concerns our use of interface types (specifically, our lack thereof). In the current version of SlimDX, the API consists almost entirely of concrete classes. However, there are advantages to exposing interfaces instead — improved testability of the public API and code depending on it, for example, as well as the potential for some back-end improvements to code health.

There are two major main concerns involved in redesigning SlimDX to use interfaces:

Acquisition

The first is the question of how one initially obtains an interface. SlimDX 1 uses the constructors of its concrete objects to enable users to obtain new instances. Thus, in SlimDX 1 you would obtain a texture instance by doing new Texture2D( device, ... ). This constructor will invoke the native ID3D10Device::CreateTexture(). In SlimDX 2, we’ll present a model that mirrors the native interface more closely, with an IDevice interface that demands a CreateTexture method.

To handle bootstrapping — obtaining that first interface — we’ll expose so-called “API objects” that will represent each of the primary subsystems SlimDX exposes to native code (for example, there will be a Direct3D10Api object that will let you obtain the initial D3D10 device interface. These API objects will also be a convenient location to present many of the native free functions. SlimDX doesn’t expose all of these now, and the ones it does provide are often tucked away, seldom-seen static members of one class or another.

Handoff

The other half of the problem is translating those interfaces back into concrete, usable objects when they are passed back to SlimDX for one reason or another.

We could simply downcast the interface to the concrete type, but that relies on the assumption that such a cast would always succeed — and that isn’t true in general. SlimDX has always supported interoperation with other DirectX-wrapping managed libraries, and to make the assumption that our interfaces were only ever implemented by our own library would work against that.

Fortunately, as a result of that interoperability feature, we’ve had to have all of our objects expose their IUnknown or similar native pointer (wrapped up in a System.IntPtr). Thus, we can rely on an accessor for that pointer being available from the interfaces, and we can use that to obtain the actual interface we’re interested in working with in the SlimDX code.

SlimDX is has become a pretty comprehensive API, but the fact still remains that it is a version-one iteration of the product, and like all version-one iterations, it has issues. In particular, some of the more insidious bugs and poorly-considered design decisions are starting to become increasingly more uncomfortable to deal with. Since no good solutions exist for some of these problems that will preserve the existing public interface, we’ve been thinking about what a version-two iteration of SlimDX will look like. There are quite a few aspects of the API we’d like to improve for the next version, and over the next few days I’m going to talk about some of them.

Microsoft released the February 2010 DirectX SDK last week, and so we on the SlimDX team now present you with the February 2010 SlimDX SDK.

There aren’t many major changes in the DirectX SDK this time around– PIX has gained some improvements, including better support for dealing with D3D11, and XNAMath got a few bug fixes, but most other changes are relatively minor. However, the SlimDX SDK includes some interesting changes (a full summary can be found in our release notes).

Ownership and Disposal

We made some modifications to certain interfaces to help clarify the ownership/disposal semantics of those interfaces under typical usage scenarios. In particular, we changed the ownership rules for GetBackBuffer so that users must call Dispose on the returned object themselves, and we changed how surfaces are constructed from swap chains (using the static FromSwapChain method on the Surface interface). These changes were made to alleviate some issues caused by unclear ownership semantics, leading users to not know when it was appropriate to Dispose of an interface, and in some cases making it impossible to correctly clean up a resource.

New Subsystems

August’s SDK release included DirectWrite wrappers, but they were severely lacking. We’ve implemented significantly more of the DirectWrite interface for this month’s release, although by our estimate we’re still missing about half of the subsystem.

We’ve also added wrappers for the XAPO API.

Decreased Subsystem Interdependence

D3D11 shares a few interfaces (and constants) with D3D10, so in the previous SlimDX release one would need to reference both namespaces to effectively utilize D3D11 functionality in some cases (involving, for example, the ShaderBytecode class). For February, we’ve split those shared interfaces into 10 and 11 versions, so this should no longer be necessary.

Revamped Sample Framework

Finally, as I have discussed previously, we had plans to rewrite the sample framework and the associated sample set. There were many problems with the previous sample framework, mostly centering on its similarity to XNA (which caused many users to interpret it as a reusable “game” framework and try to use it for real applications). It isn’t our intention to be providing that kind of a framework in SlimDX, so the new sample framework is significantly more bare-bones. We have removed most of the old samples from the distribution, replacing them with more narrowly-focused samples illustrating some specific basic concepts that we receive a lot of questions about — specifically, dealing with losing the device and resizing the window in D3D9 (illustrated by the framework itself) and in setting up depth and alpha blend states in D3D10 (illustrated by the SimpleMesh10 sample).

Unfortunately we didn’t have the time to complete everything we would have liked to have done with the new sample framework for this release, but we’ll be continuing to add samples of increased complexity in future releases.

Dave Prout wrote an article on the subject of crunch. He approaches the issue from a different angle, examining the causes and effects of compulsory overtime rather than dwelling overmuch on the quality of life issues. Early on, he makes an excellent point about the perception of importance:

While espousers of crunch often equate it with creative passion — a necessary duty, a sacrifice shouldered in the realization of a nascent gaming opus — I grow increasingly skeptical. Any project, enshrined in the pregnancy of its own importance, is able to distort the realities of its true value to the world, skew the definition of success for team members, and inflate the supposed creative caliber of team leadership. Not all games are game-changers.

I think this is such a critical point because I have seen so many cases where a project develops this aura of misleading significance, this notion that slipping the release date will result in disaster and grievous consequence. Yeah. Right.

The release date is generally only of such dramatic importance to investors and major stakeholders, and as Prout says, reliance on crunch is actually a disservice to them as well:

Common practice or not, one cannot make good faith assurances to an investor regarding budget and date targets, if said assurances are dependent upon significant, but unknown, quantities of free labor.

The full article, “A Closer Look At Crunch”, was published today on GamaSutra. It’s an excellent read, especially since it explores various ways to avoid the need to crunch by avoiding what Prout believes to be the fundamental root cause of the issue: premature production. While I’m not sure that I would agree that this is the cause, it can certainly be a contributing factor and the preventative techniques Prout outlines do have some merit regardless of their ability to eliminate crunch from the development cycle.

I’ve been on a bit of a pork kick, recently, so when I found out about a new butcher that had recently opened up nearby, I knew exactly what I wanted to do. When I ate at Morimoto last year, one of the amazing dishes I ordered was a slow-braised pork belly served with a rice porridge… Marc of No Recipes had recently posted a great video about about black braised belly as well. Obviously, I needed to do something featuring the same, wonderful cut of pig.

The butcher sold me a cut of belly, and since it was so large I decided to prepare it two different ways — since belly is generally cooked slowly, I’d have plenty of time to intersperse the two dishes and their related accompaniments. It would be an all-day project.

Pork belly is a really fatty, flavorful cut — it’s the same place on the pig that bacon comes from, in fact. The difference is that most bacon you find in the stores has been cured and then smoked or seasoned, et cetera. You can find “fresh bacon” in some stores, but even that has still undergone an initial curing process. I decided I would roast half of the meat, and braise the other half. By doing the roasting first, and then chilling it, I could make what is called “pressed pork,” and the chilling time would allow me to braise the other half of the belly and do a lot of the prep work for the other dishes — a cranberry chutney, turnip puree, and a really simple apple salad. You can see the complete set of cooking photos over on Flickr.

After months of speculation and anticipation, Apple unveiled their tablet computer — called the iPad — today. I had been curious about the device primarily from the standpoint of an owner of both an iPhone and a MacBook Pro. What, I wondered, would be the unique appeal of the fabled tablet to people like me?

But after today’s presentation by Steve Jobs, I’m forced to conclude that the iPad really isn’t aimed at me at all. There wasn’t really anything in the its demonstrated range of capabilities that I can’t get from any of my other devices. It seems that Apple is going after the set of people who are iPhone owners but who don’t own a MacBook.

My first impression of the iPad was that it’s just a bigger iPhone, and nothing I saw ever really changed that. That’s not really a negative thing, though: the core apps — Mail, Contacts, Safari — have been rewritten to take advantage of the better screen, beefier hardware, and improved OS features and UI elements. The tablet appears to remain a single-app device — early investigations of the SDK revealed no multitasking support. But the larger screen does allow each individual application to structure itself to support more modeless operations.

I did find the extremely large bezel somewhat off-putting at first, although I realize it’s probably utilitarian: it provides surface area on which you can grip the device. I’d expect you’ll be gripping the edges of an iPad more often than you would an iPhone, due to the increased size. You wouldn’t want your fingers to set off the touch screen in that case. John Gruber, who spent some hands-on time with the device, has the same opinion. Although… it would have been cool to see those “touch-sensitive back casing” rumors (concerning the next-gen iPhone) materialize here in a form that would let the iPad detect how you’re holding it, and react appropriately (shrinking the touch-reactive area, perhaps).

As far as filling needs… eliminating what the MacBook Pro and iPhone provide, the only unique service offered by the iPad is the e-book platform. I’m sure iBooks and all of Apple’s infrastructure for electronic reading will look great, but I’m not sure they’re going to be stealing the Kindle’s thunder — not for me at least (they may have a shot at the people who read newspapers on the Kindle, since the iPad can do better, more dynamic layout). It comes down to the screen: reading on the Kindle’s e-ink screen is a fundamentally different experience than reading off a backlit, glossy LED screen. The Kindle’s screen certainly has shortcomings, but I still prefer it to reading on my MacBook or iPhone. Perhaps if the iPad had been available before I got my Kindle…

The price was also a surprise — cheaper than I thought. I’m wary of the 3G data plans, though. I didn’t catch any mentions of how the iPad’s plan interacts with existing iPhone data plans, and I’m not sure the 3G functionality is worth another $15-$30 on top of what I’m already paying AT&T for their mediocre service.

Still, it’s a solid, good-looking device on the whole. I have absolutely no need for it, but that doesn’t mean I wouldn’t ever buy one. I’ll definitely swing by an Apple store a few weeks after it becomes available to see what it’s like in person.

Oh, but the name is really dumb.

A few days ago, I was asked, “oh, you’re still doing tools programming? They haven’t promoted you yet?” It made me chuckle.

This kind of inquiry is something I am familiar with fielding; even within the industry itself, tools programming is often regarded as less than glamourous. Some — such as the fellow who asked me that question — seem to regard it as a lesser programming discipline. This is unfortunate, because there really isn’t any aspect of game programming that is less important than others, in general. Sure, certain studios may have no need for a server programming team, and some studios may not need much in the way of a tools programming team, either. But when you need one of those teams, you really do need them. The whole development machine has to work together, and if any one cog or widget goes missing, the whole thing breaks down.

But it is true that tools programming is rarely a position of high visibility. As Jeff Ward recently wrote in an excellent post over at the IGDA Toolsmiths SIG:

…in my experience, when you talk to people both inside and outside the industry and say you’re a game programmer, the first thing they’ll ask is “So what did you do on the game?” expecting that you’ll be able to point to something specific. Gameplay programmers can say “I made that system work.” AI programmers can say “I made that person move.” Graphics programmers can say “I made that thing render and look good. Tools programmers can really only point at the team and say “I made that work better.””

But, Ward continues, “that’s the way we like it.” And he’s right. I chuckle when people ask me if I’m “still doing tools,” because if I get my way, I will always be doing tools. Building tools is really all about helping people, and it turns out, I like doing that. I enjoy working with the other developers, trying to figure out why some program isn’t addressing their needs exactly, why some bug is manifesting its nasty little head, or what I can do to further optimize their workflow. I love the sense of satisfaction and accomplishment I get from succeeding at such an attempt.

There are other benefits, too: I get exposed to nearly every other developmental discipline in the studio, which gives me a pretty clear picture of where the project actually stands (and produces a feedback loop allowing me to better customize the tools I build). Additionally, I get to work with a wide range of technology, and have a lot more freedom to explore new ideas and conduct research. In short, I think that being a tools programmer is the best job I could ever land in this industry.

If you’re reading this post, the DNS changes have propagated such that you’re now looking at this blog’s new home. I’ve switched to hosting with WebFaction — not because I had any serious problems with my previous provider, OCS Solutions, but because I hate both Webmin and cPanel. WebFaction uses a home-grown control panel interface that offers an excellent combination of “powerful enough to do what I need” and “simple enough not to tempt me with options I don’t know how to use properly.”

I’d been toying with using Tumblr as a replacement content delivery platform. It was new and sleek, but using it put me very much in the mind of a longer-form version of Twitter. The back-end management provided by the platform was just a bit too simple for my needs. So I’m still with WordPress, albeit on a different machine.

The recent “Rockstar Spouse” incident has, not surprisingly, caused some discussion about the IGDA and their role within the game development industry. Drew Sikora posted via Twitter

“Wake up people. Game devs who blame the IGDA for doing nothing blame themselves for doing nothing. Get it? Now do something.”

which instigated a series of replies, including my own. But since Twitter is a really poor medium for discussion (especially as the number of participants, and thus @replies, grows), Drew elected to expand his argument via a blog post, which he published earlier today.

As it turns out, Drew and I seem to agree on the critical issue, which is that the onus is on the individual developers to take responsibility for the quality of their own work life. Where we differ is our opinion of the IGDA and its role in that process.

The IGDA is not — and never has been — an agent of change within the industry. The organization is about communication: enabling networking between peers, or advocating on the industry’s behalf. But they’re not a regulatory organization: they have no authority to alter how a studio or publisher runs itself. While some would call this a failing of the organization, I feel instead that it is simply their ideal state. In this sense they are impotent, and impotent they should remain. I don’t really feel like the industry has reached a point where it needs a governing body.

That the Rockstar developers are beset with the trials of long, thankless hours is unfortunate, but they allowed themselves to put in that position. It’s naive to think that, as an individual game developer in a studio, you can hunker down and focus on your isolated area of responsibility, letting all the other goings-on in the company pass you by. When you do that, you become complicit in your own misfortunes: you become the faceless cog in the machine. We, all of us, need to take charge and be proactive. When schedules get changed, or features get piled on, when it starts to become apparent that something might be wrong, ask the hard questions. If you don’t think you can ship when the new release date is pinned down, say so, and say why.

Yes, it might be hard. It might be scary. You might feel that speaking up puts your job on the line, and maybe it does. If so, talk to your peers beforehand — a unified front is more effective than a single man or woman. It’s likely to be especially risky in today’s economy, but it is what needs to be done in order for this industry to outgrow these exploitations. You need to convince your bosses, who need to convince their bosses, who need to convince the VPs, who need to convince the publishers, and so on. It’s not the IGDA’s job, it’s yours. If we want to grow up, we can’t expect to run crying home to mother every time a bully says something hurtful about our pocket protectors.

Which brings me back to the original topic, and where Drew and I disagree. He says:

“So unless you’re ready to start from scratch and form your own organization to simply create a more complex problem out there, or you really think we’re all better off acting as individuals (look how that’s turning out) I suggest you get involved with the IGDA by becoming a member. Do it simply to support all the other members actively working and using the monetary resources you provide to continue to improve standards and reach out to more areas of the industry with their advocacy. Or, if you support the idea of the IGDA but feel there are parts of it that need to change, roll up your sleeves and join a SIG or request the formation of your own to address a certain issue.”

Unlike Drew, I do believe that an individual acting alone (or in concert with peers, but not necessarily via a third-party organization) can catalyze change in game development. But I choose not to renew my long-lapsed membership because I do not believe in the IGDA as an aid to that end.

I don’t believe that the SIGs and chapter meetings bring about any more good than the individuals participating in them could do on their own. Having seen no evidence that the IGDA has ever successfully been engaged to mediate a debate, I’ve no faith they could do that effectively, either. Nor do I see anything going on in any given local chapter that couldn’t occur were that chapter their own, independent interest group. Indeed, each chapter is so unique they may as well be. True, we must recognize the IGDA for their work on standards for QoL, crediting, and such… but a standard is only as reliable when it is accepted widely enough — and from what I can tell, much of the IGDA’s standards are accepted by virtue of being common sense.

In the end, I simply see a dearth of evidence sustaining the notion that the IGDA can act as a force-multiplier for the individual actions and opinions of its constituents. That’s not something I want my time, my money or (most importantly) my name associated with.

Before I returned to Pennsylvania for the holidays, I rather quietly made the initial commit to the SlimBuffer Subversion repository.

SlimBuffer is a very straightforward API for creating and manipulating native-memory buffers from managed code. While there exist ways to do this directly — via unsafe blocks (in some languages) or various methods of the System.Marshal class — those methods are usually inelegant, inefficient, or both. SlimBuffer is written in C++/CLI for maximum efficiency and does what it does in a very clean, expressive manner.

If you’ve used SlimDX’s DataStream class, you already have a basic idea of what SlimBuffer’s MemoryBuffer class is like. Indeed, DataStream is the conceptual basis for much of MemoryBuffer, and the problems with DataStream provided the impetus to spin off the SlimBuffer project.

The big difference is that MemoryBuffer is not a subclass of System.IO.Stream. Our original decision to make DataStream a stream was a poor one. It forced certain conventions on us that, as development and usage of our API progressed, became restrictive. For example, the lack of distinct read and write positions causes users to have to remember to “rewind” many streams before handing them back to SlimDX. MemoryBuffer is beholden to no such interface restrictions — save for those of IDisposable, but that’s a given since unmanaged resources are involved.

MemoryBuffer also allows for allocator customization, similar to that offered by the standard C++ containers. As of now, there is a default allocator that uses new and delete, as well as a simple delegating allocator.

SlimDX 2.0 will be replacing DataStream with MemoryBuffer, but the class (and some of the interesting tidbits I have planned for it) can be extremely useful on its own, so we’ve created a dedicated project for it. This way users who aren’t using other aspects of SlimDX can still take advantage of what SlimBuffer provides.