Prologue

As most people learning about OpenGL tend to find out, it provides a wonderful means of allowing developers direct access to the underlying graphics hardware and/or the GPU for a computer. What it does not provide is any mechanisms, whatsoever, to work with its host operating system environment.

This includes things like system IO, Windowing, timing, etc. just to name a few. The traditional approach to fill this gap has been to use yet another library to handle the specifics. This approach can be nice in the fact that the abstraction can allow platform-independent GUI, etc. operation. But, as with most abstractions the underlying OS functionality - ready for the picking and tweaking - is hidden from you.

The second method is to interface with the platform's specifics directly to achieve the extra functionality necessary. This approach does not allow for platform independent code, but it does allow you fine-grained control on how your application works and without the extra overhead involved. Being a longtime Windows developer myself, this is the route I chose because to me, speed is important and getting exactly what I want out of Windows is important.

So, I propose a skeleton Windows-based application that hosts an OpenGL rendering environment. Unlike most other skeletons or wizards out there for OpenGL-based applications, this is more complete with the functionality required to create a real-world application rather than a hello world scenario, and actually uses multithreading to achieve a performance boost on newer systems.

Goals

The goal of this application is to provide the mundane work required to get an OpenGL rendering environment up and running using no external libraries other than what is already provided by Windows by default. This also allows us to use a common set that is well-tested and debugged.

The design followed the KISS principle. Rather than including everything in the world that doesn't apply directly to an OpenGL command, it includes the functionality that would be present in just about every application you make. It does, however, contain enough of a structure to allow you plug in extra functionality as needed.

Features

Timed-Based Animation

One of the age-old issues in animation for games has been when running on a faster CPU/GPU than the game was designed for the game becomes unplayable as it runs too fast. The opposite of this is true as well. If a game was designed on a fast system, but run on a slower one, the animation can be too slow.

Due to this, the skeleton application employs a technique called timed-based animation, which uses the amount of CPU cycles per second the computer takes to render a frame as a multiplicative factor when animating. Using this method allows for smooth animation regardless of the frame rate.

Multithreading

The skeleton application takes advantage of a multithreaded paradigm. It uses one thread to handle the Windows specific processing and a separate thread to handle the OpenGL specifics. This has two distinct advantages. One, this will allow for a performance boost on modern CPUs that use Hyper Threading and/or dual core technologies. Two, this also ensures a smoother operation of the rendering pipeline for OpenGL, as it will not be bottlenecked by Windows message processing (which is required so the user can interact with the application).

Inter-Thread Communication

In the application, the two threads are able to communicate via a messaging system. The main thread can use the PostThreadMessage() API to talk to the render thread, and the render thread can use the SendMessage() API to talk to the main thread. This allows for a customizable, extensible means for the two threads to share information.

Serialization

Realistically, any Windows-based application will tend to use some means to save and restore settings. One very popular way is to take advantage of the Windows registry. As such, the application supports reading and writing to the registry under the Users hive, but can be easily adapted to also write to the System one, etc.

By default, the skeleton will check for BPP data, main Window positioning data, and the vertical refresh rate to use for fullscreen mode.

Command Line Parsing

And what would an application be, if it didn't use the command line? The skeleton application allows you easy add support for as many command line options as you wish. By default, it checks for a /fullscreen option that allows the user to specify if they wish to run in fullscreen or windowed mode.

Debug Macros & Information

For debug mode only, the skeleton application will do two extra things:

First, it will provide you with status information on the title bar of the main window providing the version of OpenGL installed on the system and the frame rate (FPS). This information is useful in determining what you can do with your installed implementation and performance tweaking.

Second, it enables two debug macros called ENTER_GL and LEAVE_GL, which is intended to be used to surround code blocks of OpenGL calls. OpenGL's error handling mechanism isn't straightforward, and these macros will help alleviate this. The application itself demonstrates the usage of them.

Extensive Configuration Options

To accommodate many different scenarios, the skeleton application makes use of preprocessor directives in WinMain.h to enable or disable or configure the features to use. Below is a description of the ones that may provide a bit of confusion:

CONFIG_ALLOW_FULLSCREEN

Set this to true if you wish to allow the application to enter fullscreen mode; otherwise set it to false. Note: if false, this will override all other settings (registry, command line, etc.) regarding fullscreen.

CONFIG_ALLOW_RESIZE

Set this to true if you wish to allow the main application window to be resized; otherwise set it to false. Note: if false, the application will not take into account any information regarding the window's size (only position).

CONFIG_ALLOW_MENU

Set this to true if you wish to allow a standard Windows menu on the main application window; otherwise set it to false. Note: if true, the application assumes the menu's resource id is IDR_MAINFRAME. Also, by default, the ESC key will show and hide the menu. Doing this will enable the user to free up more real estate on the screen.

CONFIG_ALLOW_VSYNC

Set this to true if you wish to allow the application to adjust the vertical refresh rate synchronization for the frame rate (VSync) on the video card. Note: if true, it attempts to turn VSync on or off depending on if it's possible for the system and configurations. If it is not possible or set to false it will do nothing no matter what the settings. If allowed VSync can be turned on or off by using the VSync key in the registry.

CONFIG_DEF_BPP

Default bits-per-pixel (BPP) to use if the application is in fullscreen mode. Note: This can be overridden by setting a BPP key in the registry.

CONFIG_DEF_FULLSCREEN

If fullscreen mode is allowed, then set this to true if you want to the application to default to fullscreen mode or false if you want to default to windowed mode. Note: as it is currently, the /fullscreen switch can override this as it's just a default value.

CONFIG_DEF_HEIGHT
CONFIG_DEF_WIDTH

Default width and height of the main application window. Note: if the window is not allowed to resize this will effectively be the main window's size always.

CONFIG_MAX_REFRESH
CONFIG_MIN_REFRESH

By default the application will look into the registry for a vertical refresh rate to use for fullscreen mode under the key Refresh. These two settings will determine the maximum and minimum refresh rates allowed as a safety precaution.

CONFIG_MIN_HEIGHT
CONFIG_MIN_WIDTH

Allows you to specify the minimum width and height of the main application window. If set, the window cannot be resized below these points. Note: setting these to 0 effectively means there are no minimums.

CONFIG_SINGLE_INSTANCE

Set to true if you want the application to limit itself to only one instance (using a mutex); otherwise, set it to false.

Points of Interest

The Use of C Over C++

The skeleton application is written in C rather than C++. Many of you may prefer using C++ and more power to you. It should be easy enough to wrap the functionality of the application into a few classes. I have nothing against C++, but my choice in C is more a practical one rather than a philosophical one.

As a result of using C, the skeleton app defines and uses bool and tribool data types akin to the C99 boolean definition and the C++ Boost library's triple-state boolean type.

Source Code Key Areas

​Main\Application.h

This is the main application include file and houses the configuration options outlined in this article.

Render Delegate

While the majority of the code is relatively self-explanatory, it is worth noting that the delegate function passed to pRenderFrame in the RENDERARGS struct that is passed to the render thread will be the starting point for anything that is to be rendered in OpenGL. It will be called once every frame and all rendering operations that don't include preloading, etc. should stem from it.

Example Application

The download of the application project also demonstrates a simple usage of the skeleton to animate the Triforce from the well-known Zelda series by Nintendo. It is a bare bones example, written for for clarity. Also, it takes advantage of the time-based animation mentioned in this article.

Share

About the Author

I've been in software development since 1994. Over the years I've learned quite a lot in what it takes to complete the process of pushing out a quality product to customers in a timely fashion. As most of my colleagues could attest, there have been many challenges in our new and growing field in the past couple of decades as the industry matures rapidly. Much more so than most others historically speaking.

As such, I've learned one of the best aspects of software engineering is embracing the change that inherently comes along with it as new technologies constantly emerge to help us improve our world one application at a time as we make sense of the overwhelming amount of data now prevalent in the Information Age.

We truly live in a time unlike that ever known to mankind in recorded history, and it is my hope to do my part to help it along to face the challenges and demands of tomorrow.

Comments and Discussions

Beside it doesnt have C++ so it makes lot easy for me to understand all

That's actually one of the reasons this was done in C. I wanted the focus to be on OGL and WGL more than design patterns, etc.

kavitesh wrote:

Let me know if u noticed anything like this?

It's because the game loop is running faster as there's less to update when no display is visible. You can either just pause the process and/or game loop or throttle it down when it's minimized and/or lost focus. In fact I may add that in an update since its common enough.

This will slow down CPU usage, but may not be the best solution.
I still figure out how to use something like SuspendThread(bool yes_no) upon resizing the window.

2:
The WM_SIZE message should also be checked for SIZE_MAXIMIZED if one allows window maximizing.
Just do the same as in SIZE_RESTORED. This will re-center the graphics. Same probably goes for fullscreen mode.

This is by design, as the transparent drop shadow provided by Windows doesn't get updated. So, constant animation would leave some artifacts. This can be altered however, should you use an owner drawn menu and/or disable the drop shadows. Look into WM_ENTERMENULOOP in WinMain.c for more info as how to stop this.

I modify the example project to allow resize (#define APP_ALLOW_RESIZE true). During resize it flickers. Does anyone know why?

Check out my response to the thread below titled "worker thread slowed by MFC UI interactions" for more information as to why. The reasons are mostly the same, with the DC preempting the RC. However, with the resize, you do have an option to reduce the flicker, you can override WM_ERASEBKGND. Check MSDN and/or Google for more info.

I create a SDI MFC program in which there is a worker thread to render a 3D scene. I found the rendering speed will be interupted and slowed by some UI interactions, e.g., moving the window by drag the window title, mouse move on some toolbar's buttons. I don't why. Could you give some suggestion?

When dragging a window around you will always notice a decrease in FPS because Windows has to redraw the window a lot, which redraws the client area and updates the DC, which forces the RC to be preempted by the DC it belongs to. Being in a separate thread doesn't matter because the RC will always be subservient to the DC it belongs to, and the DC still belongs to the GDI - which is slow.

To see this in action, try downloading, compiling, and then run the example application for this article in windowed mode, and then run Notepad and drag it back and forth over the GL sample app. You should notice a drop in FPS. And this is due to a totally different app!

Also, a lot of games will use in-game menus and toolbars as well rather than the standard Windows version. This way, you won't have to worry about the DC slowing things down when navigating them either, if they happen to force a redraw that is.

I'm trying to wrap it in classes, so i can create multiple windows doing continuous rendering.
As i'm rendering to video, uninterrupted rendering is a must (hence me putting the rendering in separate threads)....
yet as you explained above, performance suffers from other windows being dragged, minimized .

can you elaborate on the "RC to be preempted by the DC it belongs to", i do not understand what this means (i tried to google it, but that didn't make sense)
What can possibly be done to avoid this performance degradation?

Keep in mind, that was said before Vista came to be popular. If you turn on Aero/desktop compositing in Vista things are a bit different now. There's a slight loss in performance for moving stuff around, but it's not nearly as bad. If you turn off compositing, however, it still works the same way as previous versions of Windows and suffer the DC preemption. So, since not everyone uses Vista or Aero it's still a concern.

Anywho, the order of relationship of preemption with a Windows (the OS) app in regards to this is Window > DC > RC. The Window can kill the DC's drawing, and the DC can kill the RC's drawing. When Windows or menus move about the screen Windows (the OS) sends a signal to whichever DC (client or non) needs to be invalidated (usually means it needs to be redrawn to show it after being exposed) and voila. But the DC is not hardware accelerated. It's slow as dirt compared to the RC - which Windows (the OS) doesn't really care about. It just knows that until the DC is happy (redrawn) then everything can wait its turn like good little children.

Outside of using Vista's desktop compositing, there is zero way to stop this. It's just the way Windows (the OS) works.

Piet Bibber wrote:

What can possibly be done to avoid this performance degradation?

You have two options really. You can either make your application fullscreen and don't use anything drawn by a DC (like menus provided by Windows, etc.) or you can look into off-screen rendering for your application. If it's not shown on the screen, the DC will never be invalidated by other Windows moving around.

This is not hardware accelerated. It's just like movie animation. It's just as slow as the DC, but it'll appear fluid due to the way it works. It's a trick on your eyes.

Piet Bibber wrote:

click on the screen to get some balls moving - they *don't* stop moving - even when the window overlaps

In Vista, turn off desktop composting. Play around with the menus a lot. You'll notice some bottlenecks. Also, the effects of this animation is less noticeable again because it's the GDI doing the drawing in the first place. It only appears smooth sometimes since the animation is much much slower then what the RC can handle. So it gives it some time for the DC to do its thing. This can work to create an illusion, but the slow down is still happening.

I too am developing an engine using OpenGL, also for the learning more than anything else. My plan is to create an engine that is scriptable so have spent the last few months creating an interpreter for a C-style scripting language which manipulates objects, lights, cameras etc.

I am now looking into the more advanced OpenGL stuff to include in my engine, along with support for shaders - now that I have a new computer which has a seriously powerful graphics card. It has been a while since I looked at this project but I shall try this approach and see if it offers me any speed increases. Thanks!

PS. Your name is familiar, I think we spoke a few years ago - you were creating a VB encryption program. If it is you, it is funny how we are moving along the same lines.

It's a great plan. In the end we can learn a lot and possibly help others in the community as well maybe improve upon from public feedback. Sounds like win-win to me.

alankelly wrote:

My plan is to create an engine that is scriptable so have spent the last few months creating an interpreter for a C-style scripting language which manipulates objects, lights, cameras etc.

Sounds cool. I never used LUA but I know that a lot of engines also use that as a script if you want to at least pull some ideas from it.

alankelly wrote:

It has been a while since I looked at this project but I shall try this approach and see if it offers me any speed increases. Thanks!

The multi-threading will really shine on the newer systems that have dual cores, or even hyper threading will benefit somewhat. It really will be the way of the future, so it's worth integrating into your engine for sure.

alankelly wrote:

PS. Your name is familiar, I think we spoke a few years ago - you were creating a VB encryption program. If it is you, it is funny how we are moving along the same lines.

I dunno. I have made one in the past in VB so maybe. And ya know what they say, great minds think alike.

The multi-threading will really shine on the newer systems that have dual cores, or even hyper threading will benefit somewhat. It really will be the way of the future, so it's worth integrating into your engine for sure.

I couldn't agree more.

I was thinking about how this model could be extended but OpenGL isn't really thread-safe in terms of having multiple threads doing work on different parts of the system.

One thing i've been looking into is OpenMP, as it is now supported in VS.2005. I think there is probably some great benefit to be had to sharing vertex processing etc. between multiple threads. Maybe i'll get around to writing an article on it one day - it's been a while since i wrote anything legible. It would be interesting to get some real speed comparisons in using OpenMP. I did some time tests on a fluid dynamics simulator I wrote last year and it didn't seem to make _that much_ difference. Maybe I was using it wrong though!

I haven't used it, although it would be a bit interesting to look into. So far, I've been allowing the OS's SMP scheduler handle the grunt work, of course I do set affinity. But, if I can push better performance out of OpenMP that would be nice, although I don't really have a supercomputer to test things out on.

For more complex models I wonder about introducing a third thread (or utilising the main thread more) for manipulating the model. As I understand it there is a latency issue with SwapBuffers whereby the SwapBuffers call, or the next GL call will block the thread.

Even in your secondary thread you are going to experience that latency, no? If SwapBuffers does block it would be nice to kick off another thread for doing CPU based work such as collision detection or general housekeeping. If SwapBuffers doesn't block then I guess this work could be done directly after SwapBuffers being sure not to call any GL functions.

For more complex models I wonder about introducing a third thread (or utilising the main thread more) for manipulating the model.

Definitely, I don't want to suggest you only need two threads in all scenarios. Typically though, most apps tend to have only one render thread however.

This skeleton isn't a end-all-be-all by any means. I wanted I wanted to achieve with this is give people something to use as a skeleton when making their multithreaded OGL apps on Windows. It's just a start that contains most of what you'll use over and over again.

lazygenius wrote:

Even in your secondary thread you are going to experience that latency, no?

Yup, but the latency can't be avoided with just about any 3D pipeline. As far as blocking, I haven't ran across that myself. If you have a link or more info on it; I'd be grateful.

The idea behind the threading is more about concurrency in that while you do swap buffers going on you could also be doing something like processing the AI for the next frame on another core. The slow down is mitigated and not really gotten rid of, but the end result could be faster overall.

Thanks for the interest. It recently passed the initial design phase. I already have Windowing abstractions set in place for cross platform, but no inter-game GUI elements yet like listboxes, etc.

I was in the middle of implementing the thread pool when I got pulled aside to do some work (not by choice ). But, once that's done and I get a rough renderer set in place I may go ahead and write a pre-alpha article on it just to get some feedback/ideas about it.

I still have a long way to go. It'll be in alpha for a while. I want to get something functional first (3D audio, scene graph, timing, etc.) going before adding more advanced stuff like shaders. It's all a work in progress and could easily be a year before it's done. But, I'll most likely post something on CP before that time.

i am looking for a minimal opengl framework that supports picking elements in the model and interactive navigation such as pan, zoom, rotate, orbit ... does anybody know of a good clean implementation of such a beast? preferable platform independent, e.g. wxWindows based?

I agree with everyone else and your article is well written and will definitely aid coders in writing OpenGL apps. Earlier in my Windows programming career, I did some testing to determine the speed difference between Windows messaging and using Events and memory mapped files to pass messages. Like you, my first code was written in C, not C++. I cannot find my data after 8 years, but I seem to remember that the Windows based mesaging came out slower. I alo did some playing around with priorities at the time and that certainly could have been a factor in the differences. Have you ever done any tests in looking at the differences in response times of the 2 methods?

Have you ever done any tests in looking at the differences in response times of the 2 methods?

No I haven't. My threading experience has been in Windows only, so I naturally got used to using the messaging route. You have, however, piqued my interest and I'd love to hear more about using memory mapped files for messaging. I'm not sure if it's faster or not, but I have no problem testing it out to see.

As far as threading priority, that very may well be something I add to the example at a later date. I kinda got side-tracked working on my engine and it's taking a lot of time.

Windows uses the message loop as one of the triggers for context switching applications. Another trigger is the Sleep() function. So perhaps by avoiding the message loop and using memory mapped files you could give your application a higher priority when it really needed it. Or did you get more consistent framerates by avoiding the message loop?

So perhaps by avoiding the message loop and using memory mapped files you could give your application a higher priority when it really needed it.

Well, I've never used memory mapped files for threading, so it's still a subject I'd like to dig into some more. Perhaps over the holiday weekend and compare to the two.

Todd Smith wrote:

Or did you get more consistent framerates by avoiding the message loop?

I never did avoid using a message loop. The reason being I wanted to allow Windows to handle the threading priorities naturally so I don't hog down the system. With that being said, I don't notice a major performance penalty over using messaging say compared to global variables (yeah, there is one of course). But, the idea behind messaging is A: it's a lot more flexible and B: it helps with encapsulating details.

However, if using a memory mapped file can help me achieve the same thing but faster then I'm all ears.

Seriously though, I don't know D, and I'm trying to stay away from learning a new language right now while I'm racking my brain with all sorts of learning materials (I'm making a game engine), and if I push it any further I'm afraid my head will explode.

It's a home brew engine, using libs (like libpng) internally where I can cut a few corners.

I'm mainly doing it for the learning experience. It already supports texture mapped fonts w/ kerning, PNG HDR TGA and JPG image formats, and filters like sharpen, etc. Of course, I still have a looooooong way to go, but one step at a time.

I see.
As you mentionned "fonts w/ kerning" I can't resist to taunt you a bit more...

I guess it's OS independant font handling (because of the "texture mapped font" hint) but does it support international rich text?!
Ok, bad question...

Just for fun and to show that I do some homework too (although with the evil .NET technologies):http://csgl.sourceforge.net/[^] by Lloyd Dupont! (me!)

http://www.nova-mind.com/[^] by ... me again! (well I was the only windows developer 'till last month) and although I have a small hebrew bug, it does support international characters (and it's using home made text view)!

At first I tried using freetype, but the load time was too slow for my liking, and then came its issue with being dog-slow with kerning, so I dumped it.

Anywho, rich text is supported in the fact that if you want a bold and/or italic font, the font creator program included with my engine will convert that. So, you can create two different fonts (say a normal version and an italic version) and mix and match them however you want when displaying the text.

Is does support different colors by passing a command and color value in the input string for the drawing routine, so you could draw any char in any color you wanted.

It theoretically supports Unicode in the image file format as it stores the char codes mapped at 16-bit ints, but the little helper tool I made to create the font file loads the ANSI charset to pull the glyph data from (forward thinking at least for now).

Super Lloyd wrote:

Just for fun and to show that I do some homework too

It looks cool. How much do you plan on doing with it?

Super Lloyd wrote:

http://www.nova-mind.com/[^]

Ok, that looks real interesting. How much does that sell out of curiosity? You making a killing yet?

Super Lloyd wrote:
Just for fun and to show that I do some homework too

It looks cool. How much do you plan on doing with it?

Stopped to work on it a while ago...
In fact my activities level has dropped a lot due to some form of chronic illness which pumps my energy way..
But I have a plan! (Althought a slow one)

Jeremy Falcon wrote:

Super Lloyd wrote:
http://www.nova-mind.com/[^]

Ok, that looks real interesting. How much does that sell out of curiosity? You making a killing yet?

it's working well (financially) on the mac (my boss has 3 developers working for him now)
it's hasn't been marketed a lot on windows yet (and the sale figure are not great, just a few hundreds windows user last time I asked)
we plan a new upgrade in about 1~2 month with a completely new GUI which would be
1. much nicer
2. and, more importantly, easier to use yet more powerfull! (whereas now I regularly lose myself in the 17 inspectors...)

This is something I found interesting as well. Plenty of sites I've been to mentioned using a separate render thread, but very few of them had a downloadable sample/base that I could find that didn't use a combo of SDL, etc. Granted, I wasn't searching the web for months, but you'd think would've stumbled across a few.

Btw, I did notice one major caveat also when making the base app. Make sure you shutdown the render thread before you close the main application window on the process thread. OpenGL's RC is bound to the window's DC you set it to. If that goes, OGL starts spitting out errors because the RC being used is no longer valid.

Oh... by the way... once you employ the high resolution timer and link all movement to time rather than timed-frames, it is a true time-based application since you are no longer timing the frames you are moving according to time itself.