Learning OpenGL. Log 4

This post is part of a series of logs of my journey in learning OpenGL (or as some say, modern OpenGL. OpenGL 3.1+).


Since the last log. I’ve done a lot of code exercises, basically involving implementing the render system in my engine. The main two focus were moving away from the homogenous/normalized device coordinate system and using VAOs(vertex array objects) properly.

Projection, projections

I spent  quite a bit of time over the last couple days learning and implementing perspective and orthogonal projects (and wrapping them into a simple camera class). It’s been quite a few years since I’ve done calculus back in high school. Where I’ve learnt the basics of matrix maths. I know how matrix multiplication works and I do have some basic ideas on what the maths are doing when I looked at the necessary steps to create a perspective project matrix, but I didn’t really understand the higher level concepts and theories in the transformations. Mostly because my brain was in denial and did not want to learn them, plus I just couldn’t care less at the time. So I did what any lazy person would and went the premixed cake flour route. I read a bunch of tutorials online and books and stitch together bits and pieces of codes that will work for now. Leaving the mess to my future self to worry later. At the end of the day. The minimal you need to know when comes to learning new stuff is knowing what things do, but not how they do it. At least that’s how I look at it.

Vertex Buffer Objects

I only just picked up what vertex buffer objects really do yesterday. Reading any tutorial or guide on modern OpenGL. One of the first things you do when you want to draw something (e.g. a triangle). You have to setup a vertex buffer object by calling glGenVertexArray(), and bind it by calling glBindVertexArray(). They then move on to do other stuff only to never return to the generated vertex array object (aka: VAO).

After spending much time on Google-ing, reading and cursing. I’ve finally came to the understanding that the VAO is conceptually just an object that records all the configure and setup calls such as glBindBuffer(), glEnableVertexAttriArray()m gkVertexAttribPointer() when it is binded. So instead of calling those functions everytime I made a draw call. I can just create and bind a VAO  and make those calls during object setup, and then bind the VAO each time I want to draw the object and unbind right after. When drawing multiple objects (e.g. multiple triangle shapes), each object should have their own vertex buffer object and just bind it when it needs to be drawn. Very cool stuff.

One thing to take note here: The usual order to setup things up is the following:

  • create and bind a VAO
  • create and bind a vertex buffer object (VBO)
  • buffer data.
  • call your gl*Pointer functions to enable and set attributes. (This automatically associates the attributes with the VBO. Don’t call glDisableAttribPointer() here.
  • you can unbind your VBO now. (as far as I can tell it doesn’t effect anything).
  • unbind VAO
  • call glDisableVertexAttribPointer(). (seems to be optional. I am not sure if I am suppose to).


The next thing I will learn and work on is textures and simple lights.

Learning OpenGL. Log 3

This post is part of a series of logs of my journey in learning OpenGL (or as some say, modern OpenGL).


I’ve started an other log, dedicated for the engine project, so I won’t talk about it any more here unless it’s very cool or related.

Today I worked with the glm library a bit more and wrote a TransformationMatrix class.

A very simple class. The name is a bit deceiving. The entire class is actually compose of 4 glm::mat4 objects. 3 for the basic transformations, and the final one being the product of the other 3. The comments are a bit incomplete but you can probably tell what the member functions do already. There are 3 setter methods, for scaling, translation and rotation. There are also two getter methods for getting the final transformation matrix.

What interesting here is that, at the moment the final transformation matrix is only evaluated when it needs to be re-evaluated. Calling any of the setter methods will not trigger the evaluation, but they will m_Evaluated to false. When the getter methods are called. They will re-evaluate the final transformation matrix only if it’s been previous modified.

There are no methods such as TranslateFromCurrentPos or RotateFromCurrentAngle at the moment because I believed those should be implemented in a entity class which will compose one or multiple TransformationMatrix in the render component. This will allow me to implement higher level movement stuff on top while keeping the matrix class lightweight and encapsulated.

Here’s the cpp part of the class:

Of course. The class is incomplete. I will overload some operators for matrix multiplication and what not. At the moment I have to call “GetGLMMatrix()” to pass the matrix to my ShaderProgram class. I will need to add support for this new class into my shader code.

I will begin work on a camera class next, once I’m up to date with this week’s lab work.

Project Alpha. Log 0

This is the first, in what will be a series of log on my journey of developing a game engine (or something akin to that) in my spare time.


I’ve mentioned here and there that I’ve been working on a game engine, and I’ve finally decided to have a log specific for it because I’ve been mentioning it a lot in my Learning OpenGL Log  lately. Which is kind of off topic.  Having a log will allow me to eventually look back and wow myself. Seeing how far I’ve come.

The term “engine”, might be a bit overkill. Right  now, the word itself  in the game industry is pretty much an acronym to massive frameworks and game development tool kits like Unity, Unreal, CryEngine etc etc. They are software developed by teams consists of tens, if not, hundreds of developers each with a specific role.  Since I’m pretty much a one man team right now. I’m just trying to have fun while learning to develop great software and eventually, have something in my folio for when I graduate. Not to mention, it’s a real motivation and sounds epic when you’re coding a “game engine”.

The developer from ShiningRockSoftware, of whom who is also a one man team, is a huge inspiration for me. Another two group that’s also been very inspiring are the developers for Stone Hearth and Risk of Rain.

Personally, I don’t have much development experience or background. I’ve only started learning and gotten serious at about a year or two ago. It will be interesting as time move forward.

Besides building the engine. I will of course use it to develop a few games that I’ve had in mind for quite a while now. One is a 2D side scroller shooter game, and another which is something sort of like CubeWorld. My initial goal was to build an 2D game engine for developing the 2D side scroller shooter, but since I’ve started doing an 3D Interactive Graphics unit this semester. I’ve gotten a bit more ambitious.

Development started back in June July this year when I had my mid year break. It was quite slow at the start because I didn’t know what I was doing. I still am. It’s been chugging along quite nicely albeit a bit slow, but progress is steady. I’ve got the basic game loop operational.There’s a basic Entity model and management system. Of which will probably require a rewrite soon. There’s an event system for handling and passing system events. There’s also a prototype message system for engine sub-system wide communication.  Which will probably be expanded and exposed to be game specific. And since I’m doing a 3D graphics unit. There will be lots of OpenGL render system codes getting baked in over the semester.

The current plan is to begin development work on the 2D side scroller game when the semester is overall, and have a playable prototype or alpha build before next semester begins. All in all, I’m quite excited!

Hopefully the coming logs will be more technical, and less chitchats about nothing.

Until next time..

Learning OpenGL. Log 2

This post is part of a series of logs of my journey in learning OpenGL (or as some say, modern OpenGL).


So far

Quite a bit of work has been done on the engine (briefly mentioned in my last log) over the last week. I did get permission from my coordinator so I will be using the engine for the unit projects. It was mostly bug fixes and getting things to play nice with raw OpenGL. I can’t seem to remember the specifics. My short term memory is seems to be much worse than I remembered… Jokes aside. I will discuss a few things today that might not be directly related to OpenGL.

Windows on Windows

All of the OpenGL development so far, including my engine, has been done using Visual Studio 2012 on a Windows 8 machine. This might be too much information, but on Windows. Interesting things happen when you drag/move and/or re-size a window widget around.

While an user is moving or re-sizing an application’s window, the application’s Win32 message pump enters an other loop that blocks until the user let go of the mouse button. If you’re developing a game or anything alike, it means your game loop would be blocked as well. This blocks your render update, your physics update, and your logic update etc etc. Depending on how things are implemented, and the duration of the window action. Bad things could happen (game is paused when it shouldn’t be, logic break down, network de-sync etc). Of course. Being a perfectionist means that a resolution to this problem is needed if I want a good night sleep.

If you’re creating your window using WinMain, you can hack around it by intercepting and handling the events from the window yourself, instead of passing it to DefWindowProc. If you’re on XNA. You can also hack around it via custom classes instead of using the default XNA provided classes for the related stuff. It’s a bit trickier if you’re using a library such as GLFW and SFML, which provides abstraction on top of the platform specific windowing stuff. I think you could use the refresh callback to resolve the issue in GLFW (I could well be wrong). On SFML is a bit more complicated.

On SFML. sf::Window.pollEvent() also blocks until the window manipulation action is returned. If I guessed correctly, it is probably just a simple wrapper over the windows message pump. I could put some hack into the windows specific code and recompile SFML, but I did not want to do that. Anyway. After some more Googling. I stumbled upon a SFML forum post where someone proposed a solution to do the rendering on a separate thread, leaving all  the event handling and everything else on the main thread. I thought to myself. You might as well do everything on the second thread, and just leave the event handling to the main thread. This was implemented into my engine and now I have the option of running the game in a ‘mainthread’ mode and a ‘dualthread’ mode.

The only thing relevant to OpenGL in this is that the context has to be active on the thread that you’re doing the rendering.

For more information on the Windows message pump issue. Youcan go to this gamedev post where a guy has done some digging and reported his findings. (link: http://www.gamedev.net/topic/488074-win32-message-pump-and-opengl—rendering-pauses-while-draggingresizing/)

God Functions and OpenGL Tutorials

I’ve been encountering an issue that might not actually be an issue. It’s god functions in tutorials and/or minimal examples. It’s the sole reason I hate about reading code. Besides poor code format and bracketing. The tutorials that I’ve been following are full of them. Majority of the typical draw a triangle (equivalent of printing “hello world”)  example tries to stuff everything into as few function as possible, if not into the entire main function. It teaches nothing about the lifetime of any of the OpenGL ‘objects’.

How am I suppose to know that vertex array can be deleted after the data is buffered. How am I suppose to know that the shader source and the shader can be detached and deleted after the shader program is compiled. Wrapping all of these in nice simple classes such a ShaderProgram class, or a Triangle class would have been much more clearer and cleaner.


On the GUI side of things, I’ve discovered and gave SFGUI a try over the last few days and was able to get it semi integrated into my engine.

I did not mention SFGUI in my last log. It’s a GUI library just like the ones mentioned before (AntTweakBar, CEGUI etc). It is built on top of SFML, but it’s on a slow transition to become SFML independent. The widget looks very nice, and is very similar to Valve’s older in game GUI’s. It written in C++ so you don’t get retarded C interfaces that has a gezzalion variants for a single function. The support is awesome and the developers are very active on the forums. It is a new library though.

One issue that I do have with SFGUI is it’s sfg::SFGUI object. At the moment I have the aspect ratio fixed by calling glViewport with the appropriate parameters when a re-size happens. When the GUI is displayed by calling sfg::SFGUI::Display(). It calls glViewport internally which breaks my aspect ratio. I reported the issue on the forum and got a response from one of the developers very quickly. We are currently in the process on finding a workaround before the issue is fixed for the next version.

Qubicle Constructor

I bought a license for Qubicle Constructor last night. It’s a voxel model creator. I plan to use it to create some models for the unit projects.  I have to say. It is quite pricey.. (link)

For those who don’t know what a voxel is. Here’s a wiki link (http://en.wikipedia.org/wiki/Voxel).

In conclusion

I haven’t done much studies on OpenGL lately, so I need to get on with that. Gotta go to sleep a lot more earlier as well..

Note to myself

It might be better to start a different log specifically for my engine development. Instead of contaminating this log with things that are unrelated to OpenGL. Since having a general log seem like a worst idea, but that’s a lot of writing for 2 logs….

According to Murphy’s law: your professor will find your blog, and haunt you in your sleep if you say bad things about them.

Learning OpenGL. Log 1

This is the first, in what will be a series of posts on my journey in learning OpenGL (or as some say, modern OpenGL).


It’s been 2 weeks since Uni started. As I am doing an Interactive Computer Graphics this semester, which uses OpenGL. I have therefore, started it.

Besides learning to draw the basic primitives and the usual rainbow colored triangles. Plus a little bit of shader programming. I’ve spent a lot of the time in the past 2 weeks just playing and experimenting with a couple of utility tool kits and  graphics libraries for window creation and input handling. Namely Freeglut, GLFW, and SFML. Today, I will talk about my experience with them so far, and what not.

From a beginner point of view, getting started with learning how to setup a basic window and OpenGL context up was such a pain. Going from a C++ programmer to using libraries/API’s that are written in C also made me quite uncomfortable. To those who are a novice like me. Fear not, you will get used to it after a while. The hardest part is actually just getting the few concepts down.  Specifically window and context initialization and the way OpenGL’s API is defined. This is not a tutorial, so I won’t go into the details, but I will provide a list of the online tutorials I’ve been using that are very good.

Freeglut (Wiki link)

Freeglut is an API compatible clone of the now obsolete Glut. It is under active development, where as work on Glut halted back in 2005. All it does is providing means to create a window which an OpenGL context will be attached to. The reason I took a dip into Freeglut is because the Interactive Computer Graphics unit uses it (because the text book uses it…). It has been the de facto choice for tutorials and teaching materials, even though it should just die after the original project halted. now Just a quick rank: the lecturer seems like a nice guy, but he is just NOT lecturer materials. The textbook that he chose is also horrible. From what I’ve gathered, the same textbook has been used for the last couple years for this unit, which is sad. The text attempts to teach theories and concepts in computer graphics and tries to mix OpenGL into it.

The way Freeglut/Glut works is by providing a couple callbacks for different things while keeping completely control over it’s own main loop. This is good for making applications like interactive graphics render and model viewers, application which it was designed for developing.  If you intend to develop applications such as games, that are much more interactive and resource intensive, then Freeglut is not for you. At first I wasn’t too sure why, but control over the main loop is very important.

To use Freeglut, you initialize the library and set your call backs, and then you begin Freeglut’s mainloop. At this point, Freeglut takes over control until it exits.

GLFW (link)

The next tool kit I tried is GLFW. It is a very minimal tool kit and does not do as much as what Freeglut give you, but it does give you control over your mainloop. Instead of entering Freeglut’s mainloop, you have something along the line of “pollevents()”, which it internally calls callbacks that can you set, just like Freeglut. GLFW and Freeglut are quite similar with their functions, in terms of initialization and configurating the window. I spent about a week on Freeglut. By the time I moved to GLFW, it wasn’t too hard picking it up.

What I did was I ended up wrapping the GLFW stuff into a RenderWindow class, and wrote a simple event queue and wrote custom callbacks to translate most of the call backs into my own events, which I then handled by polling my own event queue. I modeled it after SFML because I’ve been using it for a while now and the OOP aspect of it made it very elegant.

One thing that I do miss that Freeglut has and GLFW doesn’t is menu creation. Pop-up menus will be used extensively for this unit so I spent a lot of time investigating what alternative there is for GLFW besides writting my own. The problem is, there isn’t really any. I did managed to discover CEGUI, nui3, glui2 and AntTweakBar.  The AntTweakBar library seems like the easiest to implement with the others looking quite complicated. I did not give any of them a try so I could be wrong. What bothered me is that they were GUI/widget tool kits and do not provide the ‘traditional’ menu.

SFML (link)

Finally. I remember that  SFML uses OpenGL internally. SFML (short for simple, fast, multi-media library). It’s popular for creating 2D games and applications. Bit of a rival to SDL. Best of all, it’s written in C++, and under active development. The library provides a lot to developers with 5 different modules. Providing classes for not just handling 2D graphics, but there are also classes for handling audio, network and other things. SFML allows you to use the OpenGL API directly, and it’s very simple to do some. What’s nice is that you can use it’s 2D graphics module along side of it. There are quite a few GUI libraries built for SFML but I havn’t look too deep into yet. The best thing yet is that I’ve been using SFML for the last couple dozen weeks on my 2D game engine project.

I spent the afternoon today and extended the engine enough to get some basic OpenGL primitive drawn. The engine is no where near completion. If I could use SFML for the interactive computer graphics unit then I will have the opportunity to develop and grow the engine along side the course project, instead of pausing work on my game project.


This blog has turned out to be a lot more formal and a bit more longer than I expected, but that’s cool. In closing, the libraries I mentioned today are not all there is out there. They are simply the ones that I’ve discovered and explored so far. There are many more out there that can be used for creating window and OpenGL context. The ones that I could think of on top of my head are Qt and SDL. I’ve used Qt before and it’s awesome for lots of things.

The next thing I will do is work a bit more on OpenGL with SFML for a bit more, and do so by extending my engine. I will also have to contatct my unit coordinator to accquire permission on developing on VS2012 with SFML on Windows (the project is meant to be done on a POSIX system with Freeglut). Lastly, I will continue learning OpenGL.

Stay tuned for the next log. Peace out!

List of tutorials

(in order of most favored):

List of libraries mentioned

(no particular order):

  • Freeglut
  • GLFW
  • SFML
  • SDL
  • Qt
  • nui3
  • glui2
  • AntTweakBar

Infinity Box and interactive graphics

A week or two back I’ve finally setup a blog for Infinity Box Studios using wordpress on the same host. Originally I thought it would had been too much work, so I actually considered embedding something like blogger or tumblr into the home page since I did the webpage using Adobe Muse. That would have meant that I won’t get 100% of the page hits (which, there is literally none at the moment…).

Anyway, I ended up finding out that it actually isn’t hard at all getting WordPress setup on my host. I spent more time choosing the right theme and customizing it than installing the blog. It was pretty much a one-click process.

Another thing that also held me back was that I didn’t really have anything to post about on that blog yet(still don’t have any) , so I thought it’s kinda pointless to set one up.

While we’re at it. I’ve also done some things to the structure of the website for Infinity Box Studio. Before I had basically the entire website inside a sub-directory called “InfinityBoxStudio/” and had htaccess redirect the main domain to the index.html file inside the sub-directory (I wanted to avoid cluttering the main directory).  This ended up giving very ugly web addresses like this one:

[code language=”html”]

I’ve fixed this by setting up a “home” sub-domain and have htaccess redirect all main domain access to the “home” sub-domain. Now everything looks prettier like this:

[code language=”html”]

To be honest, I really hate this htaccess stuff. Confusing enough. Guess I just don’t have time to look into it yet. Eventually I might look into replacing the entire website with another WordPress blog.

Speaking of Infinity Box. My game project, Project-K has been going slow since Uni started. You can blame the interactive graphics unit that I’m taking this semester. It’s all about computer graphics, graphics pipelines and OpenGL. Because of that, I’ve started an experimental project with OpenGL. Right now it’s mostly just writing some classes to encapsulate window creation and handling. The project uses GLFW internally for that and input handling, so I’m also trying  to implement an Event system to further encapsulate stuff and make things look nicer when using GLFW. Originally I started with Freeglut, which is also what’s being used by the unit materials. The few posts on the internet seem to suggest that GLFW is a much better choice for game development as it gives more control over the main loop. I’m having kind of a hard time seeing the difference between the two yet, but I’m sure I will discover more as I dig more into it. With that, I’ve fallen into the dilemma of whether I should use my GLFW stuff to run the unit lab projects and examples or stick with Freeglut.

Rest assure, work is still being done on Project-K, it will just happen a lot slower with Uni happening. It’s good in a way. I can spend more time to think before I code, instead of just code and hope things work and play nicely together. We will see how that turns out. Hopefully by the end of the year the engine will be more complete, then I can start prototyping the actual game. Before that can happen, a small game will be developed along side and as part of the engine to make sure that it works.

I had more to tell but I think this is enough for today. Bye for now!