Click here to Skip to main content
Click here to Skip to main content

A multithreaded, OpenGL-enabled application.

, 6 May 2014 Apache
Rate this:
Please Sign up or sign in to vote.
Provides a base to use when programming OpenGL-enabled applications for the real world, rather than a simple hello world.
  • Download source code - 28.3 Kb
  • Download example project - 28.8 Kb

    Sample Image

    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, include the functionality that would be present in just about every application you made that uses it. 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:

      APP_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.
      APP_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).
      APP_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.
      APP_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.
      APP_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.
      APP_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.
      APP_DEF_HEIGHT
      APP_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.
      APP_MAX_REFRESH
      APP_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.
      APP_MIN_WINVER_MAJOR
      APP_MIN_WINVER_MINOR
      Allows you to specify the minimum version of Windows the application will run on.
      APP_MIN_HEIGHT
      APP_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.
      APP_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.
      APP_WINVER_NTONLY Set to true if you want the application to run only on NT-based versions of Windows; 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.

      I'm fully aware of all the key areas in a C vs. C++ debate, and I assure you I don't care to repeat them. If you have to use C++, then please simply create a wrapper or use this application as guidance while you create a C++ version.

    • Source Code Key Areas
      While the majority of the code is relatively self-explanatory, it is worth noting that in DrawMain.c the function RenderFrame() is 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

    Also provided is an example application that 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, not written for speed but for clarity. However, it does take advantage of the time-based animation provided by the skeleton.

    Notes

    Is it my intention to write OpenGL-related articles for CodeProject in the future. If applicable, this skeleton application will serve as the basis in which I'll use to run code samples in the downloadable demo applications.

    Credits & History

    Article's Author - Jeremy Falcon
    High Resolution Timer Suggestion - Jeffry J. Brickley
    InitScene() Update Suggestion - JWood
    • 2006-08-27 - Ver. 1.1 released.
    • 2006-08-26 - Ver. 1.0 released.
  • License

    This article, along with any associated source code and files, is licensed under The Apache License, Version 2.0

    Share

    About the Author

    Jeremy Falcon
    Software Developer (Senior)
    United States United States
    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

     
    QuestionGreat article, however fullscreen does not work [modified] PinmemberElrinth8-Dec-11 9:47 
    AnswerRe: Great article, however fullscreen does not work PinmemberJeremy Falcon17-Apr-14 8:10 
    Generalmouse event Pinmembersmart_dummies27-Dec-08 3:38 
    GeneralRe: mouse event PinmemberJeremy Falcon27-Dec-08 11:48 
    GeneralRe: mouse event Pinmembersmart_dummies28-Dec-08 7:34 
    GeneralSynchronization with monitor refresh Pinmemberrinchendawa13-Aug-08 11:02 
    GeneralRe: Synchronization with monitor refresh PinmemberJeremy Falcon27-Dec-08 11:52 
    GeneralCPU utilization when minimized. Pinmemberkavitesh23-Dec-07 22:26 
    GeneralRe: CPU utilization when minimized. PinmemberJeremy Falcon7-Feb-08 7:41 
    GeneralRe: CPU utilization when minimized. Pinmemberrinchendawa13-Aug-08 10:44 
    GeneralRe: CPU utilization when minimized. PinmemberJeremy Falcon27-Dec-08 11:59 
    QuestionSystem menu Pinmembergiuliana_a9-Dec-07 2:13 
    GeneralRe: System menu PinmemberJeremy Falcon7-Feb-08 7:38 
    QuestionFlicker on resize? PinmemberHimar Carmona18-Jul-07 12:11 
    AnswerRe: Flicker on resize? PinmemberJeremy Falcon27-Sep-07 9:28 
    Questionworker thread slowed by MFC UI interactions Pinmembersolehome22-Jan-07 0:49 
    AnswerRe: worker thread slowed by MFC UI interactions PinmemberJeremy Falcon26-Jan-07 20:13 
    GeneralRe: worker thread slowed by MFC UI interactions Pinmembersolehome28-Jan-07 16:22 
    GeneralRe: worker thread slowed by MFC UI interactions PinmemberJeremy Falcon28-Jan-07 17:50 
    GeneralRe: worker thread slowed by MFC UI interactions PinmemberJeremy Falcon28-Jan-07 20:13 
    GeneralRe: worker thread slowed by MFC UI interactions PinmemberPiet Bibber24-Jan-09 1:29 
    GeneralRe: worker thread slowed by MFC UI interactions PinmemberJeremy Falcon24-Jan-09 8:20 
    GeneralRe: worker thread slowed by MFC UI interactions PinmemberPiet Bibber25-Jan-09 20:36 
    GeneralRe: worker thread slowed by MFC UI interactions PinmemberJeremy Falcon26-Jan-09 9:02 
    GeneralVery nice article Pinmemberalankelly2-Jan-07 4:39 
    GeneralRe: Very nice article PinmemberJeremy Falcon4-Jan-07 8:56 
    GeneralRe: Very nice article Pinmemberlazygenius24-Jan-07 23:35 
    GeneralRe: Very nice article PinmemberJeremy Falcon28-Jan-07 20:19 
    GeneralRe: Very nice article Pinmemberlazygenius31-Jan-07 6:19 
    GeneralRe: Very nice article PinmemberJeremy Falcon31-Jan-07 6:58 
    GeneralRe: Very nice article Pinmemberrinchendawa13-Aug-08 10:53 
    GeneralSlick... PinmemberPaulC197226-Nov-06 11:19 
    GeneralRe: Slick... PinmemberJeremy Falcon26-Nov-06 18:46 
    GeneralRe: Slick... PinmemberPaulC197226-Nov-06 19:19 
    GeneralRe: Slick... PinmemberJeremy Falcon26-Nov-06 21:27 
    GeneralRe: Slick... PinmemberPaulC197227-Nov-06 3:20 
    GeneralRe: Slick... PinmemberDanoo18-Dec-06 20:51 
    GeneralRe: Slick... PinmemberJeremy Falcon19-Dec-06 4:26 
    Generalpick and pan Pinmemberjekata21-Nov-06 19:26 
    GeneralRe: pick and pan PinmemberJeremy Falcon22-Nov-06 17:59 
    QuestionIs Windows messaging faster?? PinmemberKenneth Krueger21-Nov-06 8:39 
    AnswerRe: Is Windows messaging faster?? PinmemberJeremy Falcon22-Nov-06 18:03 
    GeneralRe: Is Windows messaging faster?? PinmemberTodd Smith22-Nov-06 23:54 
    GeneralRe: Is Windows messaging faster?? PinmemberJeremy Falcon23-Nov-06 11:59 
    GeneralError checking PinmemberJWood27-Sep-06 5:44 
    GeneralRe: Error checking PinmemberJeremy Falcon27-Sep-06 14:39 
    GeneralA stupid question.. PinmemberSuper Lloyd28-Aug-06 18:47 
    GeneralRe: A stupid question.. PinmemberJeremy Falcon28-Aug-06 18:55 
    GeneralRe: A stupid question.. PinmemberSuper Lloyd28-Aug-06 19:01 
    GeneralRe: A stupid question.. PinmemberJeremy Falcon28-Aug-06 19:12 

    General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

    Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

    | Advertise | Privacy | Mobile
    Web03 | 2.8.141022.2 | Last Updated 6 May 2014
    Article Copyright 2006 by Jeremy Falcon
    Everything else Copyright © CodeProject, 1999-2014
    Terms of Service
    Layout: fixed | fluid