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 [...]
Tags: design, refactoring, slimdx
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 [...]
Tags: design, refactoring, slimdx
The SlimDX sample situation is currently pretty disorganized: some of our samples are checked in to the Subversion repository, but others are just referenced from issues in our issue tracker. Not all the samples use our internal sample framework, either, and the framework itself has a few issues. But as SlimDX becomes more and more [...]
To begin with, the term “engine” (specifically as it related to the game development world) has no strict definition. Therefore, in the interests of keeping everybody on the same page, I’ll define the term as I intend to use it in this article. An “engine” is a collection of robust, reusable software subsystems (possibly including [...]
Tags: design, good practice