miniDooM: On System-Agnosticism

Another week(+) gone by, and still no sexy screenshots to show. That is the hardest part of the process I call "software condensation" (when the project is transitioning from vaporware to an actual piece of software), a lot of work is going on, but there is little to show for it.

Anyway, therapeutic as it might be, ranting won't get stuff done.

The Display Manager is coming along nicely, in fact, being able now to display and handle windows, change to full screen, manage screen resolutions, etc...

The part I'm having some fun with ("fun" pronounced as "hysteria-inducing difficulty") is the attempts at making the software System Agnostic.

What does this mean? Essentially that all calls to the underlying system (Java's libraries in this case) have to be neatly packed away in a corner of the code, so when the whole thing is ported to, say, C++, I don't need to go around figuring out how to re-implement methods, classes and attributes.

So far, the encapsulation is working nicely, the System namespace where I'm dumping all system-dependent elements is shaping up to be a decent template for multi-platform development, and I'm really glad I decided to focus first on this part, or else having to "rewire" everything else to meet the new specifications would've been a nightmare.

So, to recap, this is what I have currently completed:

  1. Display Manager: Handles display devices, managing display mode changes and support, active device switching, fullscreen changes and other minor details. Yes, it is multi-device compliant, so it is possible to have applications running on this use extended (multi-monitor) desktops, or have different windows on different devices.
  2. Log Manager: Logging is essential, and a robust log manger is key. I really shouldn't need to explain what this does or why it is important, let's just say that a problem cannot be fixed if you're not aware of what is breaking.
  3. Screen Manager: Ok, this one is in development, but the basics are working. Right now it can create new windows and assign them to a display device, and also make them change into fullscreen. The next step is to have this manager get control of the draw surface into which the actual game contents will be... well, drawn.

Doesn't seem like much, but I assure you the Display Manager took a lot of research to get up and running correctly, which is great for me because I'm learning lots about how the Java Virtual Machine does things under the hood.

I personally loathe doing things "blind", which is the usual easy approach. Most Java tutorials out there will have you create a generic window, recover the default display device, with the default settings and expect default operations to work correctly. There's too much default there for my tastes.

Don't take me wrong, it's a fine way to develop quickly, but it requires trusting in the default settings being optimal, which isn't always the case, specially if you port the program to a different platform.

In my situation, since the framework needs to be robust in order to be usable for future non-DooM4k miniDooM projects, it pays off to have control over these features.

So, back to the trenches!

No comments:

Post a Comment