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.

SFGUI

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.

A quick guide to using Precompiled Headers (Visual Studio)

Precompiled headers can be a very useful thing. Increase productivity by saving time otherwise would have spent on compiling.

This is a quick guide on how to setup precompiled headers in Visual Studio (specifically VS2012). I’m not going to explain what it is, or why you might want it. So let’s go.

I will assume that you currently have a project that does not have precompiled headers setup but you want it now, or later down the road.

Win32_Application_Wizard

When you create a new project in Visual Studio, and you select a template such as the “Win32 Console Application” template. The Win32 Application Wizard will open and attempt to guide you through the basic configurations of the project. A tickbox is provided for if you want Precompiled header. This is not the case when you create an empty project. The Wizard simply does not appear.

To setup Precompiled Header. First create two source files: “stdafx.h” and “stdafx.cpp” (For the tinkers. It actually doesn’t matter what you name them.) , and add them to your projects.

solution_explorer

Now select all source files (your .cpp files) in the Solution Explorer, right click and hit Properties. The Property Page should pop up.

property_page

In the Property Pages, head to “Configuration Properties” – > “C/C++” -> “Precompiled Headers”. Change “Precompiled Header” to “Use (/Yu)”. Click “Apply” at the bottom right and click “OK” to close the page. Next, go back to Solution Explorer. Select and right click on the file “stdafx.cpp” (or whatever you named it), and click on “Properties” again. Navigate to “Configuration Properties” – > “C/C++” -> “Precompiled Headers” (again).

select_create

This time, change “Precompiled Header” to “Create (/Yc)”. Again, click “Apply” at the bottom right and click “OK” to close the page.

Lastly. Do your usual “#ifndef #define #endif” or “#pragma once” include guard inside the “stdafx.h” file, and include this file in EVERY single file inside your project. That’s right. Every single one of them. Now, rebuild your solution and it should be all good.

[code language=”cpp”]
#pragma once
#include "stdafx.h"
#include <iostream>
// etc …
[/code]

Remember that “#include “stdafx.h” ” must appear before every #include in every file. Otherwise the preprocessor/compiler will happily ignore anything before it and throw you errors.

That’s all. Hope this little guide will help those that were lost and confused like me.  Here’s a couple links that will explain what Precompiled Header is to some extent. It’s best to do your own Google foo on this topic.

http://en.wikipedia.org/wiki/Precompiled_header

http://www.ogre3d.org/tikiwiki/tiki-index.php?page=precompiled+headers

http://msdn.microsoft.com/en-us/library/szfdksca(v=vs.71).aspx

Bye for now.