QubeKwest Blog

I’ve never really coded “to the metal” with a graphics library so this is going to be a bit of me talking out random non-mouth orifices.  Actually, never isn’t fully accurate I suppose.  For the sake of full disclosure I did what seemed like about 20 minutes worth of OpenGL 1.2 when I was in college the first time (16 years ago) and a full course with Direct3D during my second attempt at college (but didn’t make anything like a game).  Direct3D isn’t going to help me much since I’ve chosen Java and LWJGL and a tiny bit of 16 year old experience with OpenGL is as good as having never used it at all.

This inspired another round of buying books.  I actually bought 5 of them, but the important ones for this conversation are “The Red Book” and “The Orange Book.”  More specifically, OpenGL Programming Guide: Eighth Edition and OpenGL Shading Language: Third Edition.  This is particularly amusing for me because when I was learning a little about OpenGL the first time, I actually bought the Second Edition of the Red Book and there was no such thing as a shader.

So here I am, with literally thousands of pages to look over.  I’m not going to pretend that I will read all of these books cover to cover, but I have at least started to pick them over for useful bits and educational potential.  This is a mountain of a learning curve, but it’s a fun one to climb.

Things I’ve pieced together so far…  The graphics pipeline used to be “fixed”.  This means that it always did roughly the same thing all the time.  Over time they made that pipeline more and more configurable in lots of fun ways.  Turning features on and off was the most control you had over how things worked.

Over time, the processors on video cards got more powerful and more parallel and they introduced the ability to program them with small programs called shaders.  Sort of like the ability to configure the pipeline, only way more powerful.  The original shaders were extremely limited in the number of instructions they could do and what those instructions were allowed to be, but were still considered a step up from mere configuration options.

Eventually shaders evolved into general purpose programs and the number of instructions you were allowed to use got large enough for them to be truly useful.  Video card makers saw this as an opportunity.  Why keep around the old fixed pipeline that was buried in configuration items when you could replace it with shaders by themselves?  Why create chips that have specific features that game designers may not even want when you can provide a way to run any features they want and leave the other ones out to avoid wasting overhead on them?  That’s how the “shader pipeline” was born.

And now I have to learn how to use them…  :)

I was hoping to not have to write this post.  I did a fair shake of research on which 3D library I wanted to use, I purchased books, I subsequently read some of those books and parts of other ones, I cleaned my office and found an old book I had sitting around…  And that’s where everything kind of went to crap.

My initial research brought me to the doorstep of JavaFX 8.  There were lots of reasons for this, but the one that I found the most compelling was actually that it was simply “built in” to Java 8.  No extra .jar files, no extra licenses to worry about, just 3D as brought to you by the makers of Java.  It honestly seemed perfect.  This is where I bought books on it and started reading them.

The book that I found buried in my office and that I’m now reading my way through is a book all about the math behind 3D.  A wonderful book on everything from vectors and matrix math to triangle meshes and occlusion.  The side effect of all this delicious learning is that I started to ask questions about how things worked in JavaFX and that’s unfortunately when the cracks started to show.  Each time I read about some other 3D math thing, I learned that it was only partially present in JavaFX.  What I mean by this is that I’m sure it was there and being used under the covers, but it was totally hidden from me.  What I was discovering rather quickly was that JavaFX is likely simply too high level for what I needed.

After a bit more reading, lots of coding that was well below the level of getting pretty 3D things on the screen, and conversations with friends, I started to worry a little that I was heading down the wrong path.  Fortunately, at this point in the project that path was very fixable.  All I’d manage to get on the screen with JavaFX was a single textured block.  Sure, it was a rather pretty block, but it was only one block of the roughly 236,118,324,143,482,260,684,800,000 I was expecting each world to possibly contain.  (If you were running on a server with unlimited storage anyway.)

This in turn led me to ask Google “Java 3D Libraries” and to find repeatedly that if you want to code with full access to the 3D power available in a machine, you pretty much use LWJGL (“Lightweight Java Game Library”).  This change comes with a couple of interesting problems for me.  First and foremost it means I have to learn a LOT more about working with 3D libraries.  JavaFX is a very high level scene graph style 3D engine.  Everything is well hidden from you, so you just tell it where things go in the scene and cross your fingers.  In LWJGL, if you want it to happen, you have to tell it how to do it.  There aren’t magical high level concepts available to help you out.  Part of me sees this as a challenge, and the other part is genuinely afraid that this could be what stops this project in its tracks.

At this point, the next step is to download LWJGL and start trying to figure out how to use it.  To that end, my goal is to get essentially the same picture you see above to happen using LWJGL instead of JavaFX as shown there.  Wish me luck.

 

I’m designing QubeKwest to be a PC game first and foremost.  My chosen language is Java, a language I’ve been using and loving (except for a couple small issues dealing with unsigned numbers) since 1.0.3.  Thanks to Java, it should run equally well under Windows, Linux or Mac, but that doesn’t mean it won’t someday make its way onto Android or iPhone.  I’m not yet sure how much horsepower will be needed to run the game or the server, but I’m hoping to keep it as reasonable as possible.

My development machine is an overly powerful high-end gaming computer, and frankly that makes it a terrible target platform.  Very few people have computers that have tons of RAM, dual video cards, or eight available CPU cores.  In other words, if I wrote it to run well on my development machine I’d price myself out of the market.  To that end, I’ve chosen the new Raspberry Pi 2 as the target platform for both the server and the game itself.  If I do it correctly, it should be able to run both the server and the game on a single Raspberry Pi 2, but we’ll see.

I’m one of those people that was following Raspberry Pi well before it was a real computer that you could actually buy.  I pre-ordered my first Raspberry Pi when they thought they might eventually be able to sell 10,000 of them and when me and everyone else that wanted one took down servers all over the place trying to get our pre-orders in before they ran out.  As it turns out, they ran out in seconds and we all had to wait months before we could have one, but that’s just part of the amazing story that is Raspberry Pi.  Now they’ve sold over 5 million of them and are showing no signs of slowing down.

I personally own six Raspberry Pi computers.  As mentioned before I own an original Raspberry Pi Model B (from when it had 256MB of RAM), I also have the improved Model B (where they bumped it to 512MB of RAM), I’ve recently acquired a Model B+ (where they added 2 more USB ports, switched to microSD cards, and removed some of the output connectors almost no one used) and three Raspberry Pi 2’s (which are similar to the B+ but with 1024MB of RAM and a vastly more powerful CPU).  This cluster of little computers is my test bed for making sure my game doesn’t require more power than it should.