Dark GDK
As I was working on my Computer Science final project, I really started hating Dark GDK. It was slow. It was rarely updated. It relied on the directx SDK from 2007. It required a bunch of external modifications to work to any appreciable degree. Eventually, I swore to myself that if I ever continued the shooter, I’d switch to a different graphics API, probably SDL, or maybe Allegro.
Then I actually took a look at the libraries’ documentation.
I was absolutely horrified by the depth of complexity that the two libraries needed. I immediately went back to the comfort of Dark GDK. It turns out that my professor had a reason (as most humans do for the things they do) that he recommended it to me. Sure, it’s slow, and relies on old SDKs and all that. But it is extremely easy for aspiring game programmers to get into. For example, in order to play a sound in SDL or Allegro, from what I could tell (it could be different, I haven’t actually tried the two libraries out), you needed to load some audio drivers, then specify the actual length of the audio stream. It takes about two or three commands to actually load the sound, and then I couldn’t even tell how to play the dang sound without looking up some tutorials. In Dark GDK, though, it takes two lines. One to load the sound from a file, and one to play it. The commands are simple - dbLoadSound(char* soundName, int ID) and dbPlaySound(int ID) - and they use a easy-to-learn number-indexed system to identify sounds.
As I looked around the SDL/Allegro documentations, I grew more and more certain that I could not use them. I may return and look at those libraries in a year or two, when I really need a robust library and deal with that kind of complexity, but for now, I’m sticking with DarkGDK. It has it’s shortcomings, but hey, it’s easy, and I’m a teenager.