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.
Tags: design, refactoring, slimdx
Well, unlike some other Managed DirectX libraries at least you didn’t release a version 1.1 that replaced all getX/setX methods with properties because you forgot to use those in the first place. You beat Microsoft’s compatibility promise bigtime
Well, there will definitely be a slew of breaking changes in SlimDX 2, that’s part of why we want to start talking about things as early as possible — so developers have some idea of the scope of the changes they’d need to make to upgrade to 2.0. We plan on continuing development of the 1.0 codeline such that there is significant concurrent development overlap between the two versions. We want to enable developers to migrate to 2.0 on their schedule and not ours. Probably the only thing we wouldn’t add to 1.0 after 2.0 ships are entirely new APIs, like Direct3D 12 or something.
Assuming you don’t go timebombing your releases you’ll still have MDX beat on the compatibility front