on moving forward

So, as always, it has been a long time since I have last posted anything here, and as such, there is a TON of new information to realy, so I'll try and take it one at a time

I just finished up (and pushed to github) the port of the code to lwjgl, and am quite happy to say the least that I finally grasp the fundamentals of 3D graphics. And hence, having achieved this little goal, I have decided to move on to my next goal, creating a complete game

In order to do this, I have always heard that the best possible way is to pick the simplest game one can think of, and hence, I decided that the simplest game I could ever create which would be satisfactory would be a 2D shooter / platformer. I will also add in some elements of physics in it to make it SUPER awesome

So, this blog is mainly to say that I am moving forward with Colour Wars (yes, that title is in fact, a work-in-progress). I have nailed down the creation of the basic outline of the engine, and have made it into an entity engine, with each new piece of functionality being added in as a new component (Render component, input component, etc)

This has worked well so far, and for the next step, I will add in some physics elements to it. In the first iteration, I will just add in collision detection. I have chosen to use the JBox2D engine, which came in highly recommended from a number of websites, and so, looks pretty cool enough

on Taking a photograph

Ok, so I do realise its been a LONG time coming, but I have some great news, I think I finally understand basic 3D concepts in addition to vertex/fragment shaders and how they work!

And to prove that, I have the code up and running for lesson 5 up on github. Now, the way I see it, rendering a 3D scene onto the display surface (screen), is very much like taking a photograph. Imagine with me, if we wanted to take a photo of a box with our camera, what would we do?

The first thing we would do, is setup the world, scene or whatever you want to call it. This means that we need to take everything we want to display on screen and place it in its correct position in the world. This is also the same in OpenGL, in terms of loading up the model vertices, textures, colours and everything else that represents the model and loading them into VertexBufferObjects [VBOs for short] which, to the graphics card, represent the world

Next up, we move the model to its correct place, and rotate it by certain degrees, till we get its correct placement in the world. Through OpenGL this is done by multiplying the translation (position) & rotation matrices by every single vertex in the model, to correctly move the model to the place we want in the world. These two steps constitute us building the Model Matrix (or how the world is modeled)


Later, after the world is set up, we start setting up our shot. Usually, this means setting up where the camera is, its orientation and where exactly it would point. On the OpenGL-end this I've done through a call to gluLookAt which simply takes as input 3D vectors specifying (in exact match to real world scenario) where the camera is, where it points and its orientation (mostly known in graphics programming as the Up-Vector). This later step constitutes the View Matrix (or where we're looking and how we're looking at it)

In OpenGL, the first two constitute the ModelView matrix.

Last, but certainly not least, having setup the scene and chosen our camera, we turn our attention to the camera lens. We adjust what type of lens it is (wide/narrow lens) & its range (what distance it focuses on). This, again, is almost directly mapped to a call from gluPerspective which takes the camera's field of view angle, the width/height ratio and the near and far cutoff distances. This final step, constitutes the Projection Matrix (or, literally, how the 3D model is projected/perceived onto a 2D surface)

When it comes to the shaders then, it is fairly simple from there on. Given each vertex, and attributes for the translation/rotation of the model, the vertex shader simply computes the screen position of the vertex by multiplying all those matrices together

On a side note, the Modern OpenGL Wikibook does the computation for the rotation/translation matrix in the c code for the drawing. I moved the construction of matrices and their multiplication to the shaders in order to have this piece of computations run on the GPU, which is generally much better at these sort of floating point calculations

So, there you have it, we are finally in 3D! Next up, we will be adding some more texture (no pun intended) to the work, by adding in model textures! Till then

on Matrices, transformations and buffer flipping

So, I sat down yesterday and decided I was going to BLAST through lesson 4, so that I am completely free from the porting effort all the way till the weekend. I still have an AI-Class lesson to go through tonight, and a LGP assignment due by tomorrow. So, really, yesterday night was all the time I had left to get through lesson 4, because I REALLY want to get to lesson 5, where we move up to... are you ready? 3D! YES! where all the awesomness begins. But, until then, I still had to go through lesson 4, so let's get to that

Reading in the lesson code, I realised it was probably not going to be a big deal. I was HUGELY mistaken, but I did not know it at the time! Anyways, the lesson introduces the concept of transformation (basically altering the models in any way, moving, rotating, etc) by applying a transformation matrix. Not really much of a shock there, since this is what I know from older days of dabbling with OpenGL. The major change though, was that the transformation matrix was not applied to the vertices in the code, but rather passed to the vertex shader;
(OMG I just ended a sentence with a semi-colon instead of a period. I guess I should take some time off of coding this weekend... *thinks about it*... NEVER!)

Since the matrix to be passed was a constant value (it did not alter from one vertex to the next for each drawing cycle) it was going to be passed as a uniform value. Quick trip to the lwjgl javadocs, and it was clear all I needed was a simple call of glUniformMatrix4() with a buffer loaded up with the matrix data. The Matrix4 class was even nice enough to have a store() function that would fill up the buffer passed to it, just like OpenGL liked it

On the vertex shader's side, the only thing required was to multiply the inbound coordinates passed to the shader, by the transformation matrix, and that was really all there is to it. Simple enough

I hacked in the code, double-checked everything and ran the program and BAM! a blank screen with nothing on it. Fast forward a couple of hours, and I had tried literally EVERYTHING I know, to no avail. I had even tried replacing the transformation matrix with identity matrix (in essence, negating the effect of the multiplication) and still, nothing would show up

I spent the next 3-4 hours playing around with the code, google, opengl docs, forums and then repeating the cycle all over again. When I had last given up, I posted up a question at the forums with the SUPER helpful community at JGO and hit the sheets

To my frustration, but still luckily enough, the fix was a very simple thing. I had forgotten to flip() the buffer I was writing to, and so it was not yet ready for reading and hence OpenGL was only getting 0s off of the matrix. This of course would make all the vertices end up at the exact same coordinates on screen of (0,0,0) of which no GL_TRIANGLES call would ever be able to draw anything

I put in the fix today morning, and finally called a wrap on lesson 4. As I said earlier, I will be getting into the second assignment for LGP course, which is basically a SHMUP, one of my favourite game types ever. I have discovered yesterday the very interesting Google PlayN, and will try to do the second assignment using it tonight. If I fail to get things setup and running quickly enough, though, I will just revert to the ever reliable Slick2D and play around with PlayN later on

But that, is a different matter, and for that, I'll probably have a different post. Till then

on varyings, uniforms and being in over one's head

So, it's been a long time, I KNOW, but in my defense, I have been quite busy, and not just new-father busy, but actual indie-game-dev-wannabe busy, so a little update on how things have been going

I've got bad news and good news. I have joined up with Stanford's Online AI-Class course which has just started this week. Also, I have joined up with a University of Reddit class to Learn Game Programming. What does that mean? It means I have been SUPER busy for the past 2 weeks, and things are unlikely to change any time soon. In fact, they may only get busier in the next 2-3 months, and that is the bad news. On to the good

I have FINALLY managed to port over lesson number 3, that involves passing in information to the shaders, in the form of attributes, and passing them from vertex to fragment shader. This has also made me realise, that I had been doing the whole vertex position passing to the vertex shader in a long way all from the start of lesson 1. What this meant was, I had to go back to lesson 1 and re-write the display code for our lovely triangle. Took me a bit to understand what was going on in order to be able to port it correctly, but thankfully, a few trip to Google & LWJGL docs later, I managed to get it right. Merging forward into the code for lessons 2 & 3 turned out to be a bit easier than expected (THANKS git!)

Having ported over the code to the correct way to pass vertex points to the shaders, I was good to go and continue with porting the lesson 3 code to java/lwjgl

I am very happy with the current progress I have made; I may not be moving as fast as I would have wanted, but at least I'm getting quite a good grasp of the OpenGL programmable pipeline this way. I think this port was probably a good idea

As for the Learn Game Programming (from here on LGP) course, I will try and write more about my progress there as well. As with the lwjgl port, I am also uploading all my source code over at a github repo, and of course, everyone is invited to check it out, fork it and do whatever you want with it

on BuffersObjects and hair pulling

So, tonight, I finally got the port of the second lesson to work. This was a tricky one. It has been a few days and I was getting some weirdly funny stuff going on in the last couple of days, that really brought to me the fact that I'm working with code wrapping around C native calls, and that OpenGL does NOT mess around!

Lesson 2 is about using VertexBufferObjects (or VBOs) to store the vertex information (position, colour, normal, etc etc) and then drawing the scene using those buffers. By moving the data to the VBOs, they are probably (depending on GFx driver) moved to the graphics card RAM, and hence, offer quite the speedup in terms or drawing. Also, as far as I can tell by looking at future parts of the tutorial, they would make life easier when importing in models generated from 3D modeling software, like Blender, which I think is inevitable if you ever need your game to include something other than triangles, cubes, teapots and chimps!

Getting the code to work however, was not really an easy thing. I am so far into the code right now, that when something goes wrong, I start to freak out and blame myself first. So I kept thinking it was probably the shaders from Lesson 1, or I had done something wrongly, but I guess it was just a case of too little sleep

Fast forward to tonight, when I've had a little bit better sleep than yesterday and a lot more time to pull my hair, and I've finally gotten the code to work. I also made sure I refactored it, and played around with it a little while, to make sure I got more confidence around it. I can now finally say, I know how to use VBOs coupled with shaders to get what I want onto the screen, at least, as far as what I want is a 2D polygon

Stay tuned till the next time when we tackle passing information to shaders whether varied or constant, which should demo how we can add custom colours and fog. Till then

on Finishing up & exercises

So, I finally got down to completing just the last bits of the first tutorial (I am going at a very slow pace at the moment, but things should pick up a little once I have a little more idea what's going on). I covered all the tutorial work and even changed the code a couple times to match the tutorial exactly in terms of colours & vertex positions

As for the code itself, as I mentioned in my earlier post, I had lost it all to a stupid mistake because I was basically up coding till around 6AM, which is never a good time to use any FORCE flags, specially when coupling it with a git remove!

Anyhow, I think this git mishap might have actually been a good thing, because second time around, I completely wrote down the code from my understanding of it, and I managed to do it this time in a much cleaner and refactored way; which really paid off while doing the exercises, since other code parts could easily be plugged in. Also, what I'm really getting out of this is proficiency with git, whose workflow I'm really begining to like

In other news, I have signed up with a Reddit class about Game Programming which seems to be quite promising, and I think will be a great addition to keep me going forward. It should last 20 weeks, but seriously covers all the areas I've always wanted to read about

I am also trying to get more into the smaller details about Cubic Wars, so that when I know what I need to know, I will know what I want to do with it

Stay tuned... next couple of weeks will probably be interesting for anyone who wants to watch as one employed programmer strives to go indie and live his dream :)

on Basics, Setup & building a wireframe

Finally some time to get some work done, starting with the port of Lesson 1, and I am super happy to have finally some good quality code that I have pushed to the git repo

I had already downloaded & setup LWJGL to be used with eclipse (forever my IDE of choice) through the guides at their wiki (which is quite excellent, I have to say). The process was flawless and quite seemless really, which took about 20 minutes, all in all

Next up, I headed to the OpenGL Modern Programming wikibook, and fired up the first lesson. At first glance, I could quite easily figure out that it was all about the "programmable graphics pipeline (PGP)" which I always kept hearing about, but had absolutely no idea what it was, so this seemed quite a good start. However, reading into 2-3 paragraphs I realised that the PGP was all about shaders, written through the GLSL. More stuff that I've always heard about, but never quite understood, GREAT!

After reading through, I realised that most of the code was just foundation and wireframes to setup the window & initialise OpenGL inside it, then it was all about loading the shaders and using them to draw & colour the scene; this meant I needed to figure out where shaders fit into the picture with LWJGL. Wiki to the rescue, I found out a great tutorial about getting GLSL shaders to work with LWJGL

I have read through said article and have completed building the wireframe, where the code currently does nothing in the render method but sit temptingly waiting to replace the // TODO line. Since I've had a quite long weekend, and since this is the last day of work today, I think I'll be done today thus far, and will continue off on Saturday (weekend in Egypt) and fire up the shaders

Till then

on Humble Beginnings

Alright, so I'm finally going to dive head into indie game development. I finally have a very simple idea that I want to work on, and that I think would be fun to play. I will mainly try to target Java game development, so that the transition to developing the games for the Android OS might be a bit easier in the future

To start, I will dive head first into learning OpenGL. I have very (almost no) experience on the topic of graphics programming, and will tackle this first, since this will be the most fun (I hope) to work on. I have found quite the excellent tutorial on the topic of Modern OpenGL (since most are either over complicated, or out-dated) in the form of a Wikibook.

Since I believe the best way to learn something is to try and do it yourself, I will try to port these to the LightWeight Java Gaming Library, and have created a github repo for the ported code and will keep it opensource of course, so that others may alter (read: fix) it or benefit from it

So, if you're interested in OpenGL / graphics programming, java, game development or following along as I try and build my first ever game from scratch (The world's most highly anticipated: Cubic Wars) then keep an eye on this blog as I will be updated it (hopefully) often

Till the next time