#freeglut

openGL, glut を使って描写するなら

Eu estava usando este tutorial aqui para aprender um pouco mais sobre shaders, que, por enquanto, estou fazendo a mesma coisa que nas implementações jurássicas, só que de uma forma bem mais complicada.

Ele, assim como qualquer livro sobre OpenGL, trabalha com GLUT, que é legal pra começar até você descobrir que não precisa de todo aquele sofrimento pra inicializar coisas. Por conta disso, todo tutorial que pego desses caras eu "traduzo" pra GLFW. Coisas novas sempre são legais.

E uma coisa que descobri que inicializar contexto com GLUT é diferente de inicializar contexto com GLFW.

Pro contexto funcionar direitinho, você precisa abrir a janela. Por razões.

freeglutを導入したのでまとめ

環境

OS：Windows7

VisualStudio2010

以下手順

freeglutのデータを公式ページよりDL

解凍

解凍したフォルダに移動してVisualStudio-2010へ移動

freeglut.slnダブルクリックしvs2010を立ち上げ、バッチビルドを行う

完成

This is a continuing post for my OpenGL journey days.

With the fact that I've started with a bare-bone OpenGL then I have to hook other stuff manually. The first important stuff I need to pull it in is Windowing System.

Talk about Windowing System, there're plenty rather several out there readying libraries to be linked with in no time. I started the whole things with GLUT, a plain simple yet old and non-active development since several years ago but already found itself in Mac OS X platform since several updates and it's there and no more effort to download and brew thing again. So at least it guarantees to be a component which exists for wide (legacy and plain old) users and developers.

I came across using GLUT with no pain, and easily integrate it with my OpenGL testing platform in no time. It's clean and fast readable and understandable. Not long that I progressed through the true understanding of the history of OpenGL and its way of working. The deprecation model, its compatibility and profiles pop up the need to properly create a correct OpenGL rendering context!

It's totally different if you use OpenGL 2.1 or 3.0. You just jump into another boundary world with (maybe) no turning back. Apparently upon the pile of research over Internet about OpenGL and its deep technical jargon history. OpenGL on Mac OS X seems to be very lag in progress, and staying late after other major platforms like Windows, or even Linux. OpenGL 3.x, if I can remember it correctly, seems to be supported in Mac back in its platform updates version 10.7 in July 2011. Yes, not only we should wait for it but also driver and extension updates from ATI as it's the main part of graphics card installed in Mac system. I understand the feeling of author of OpenGL Super Bible 5th Edition in which it came out in the time of Mac didn't support OpenGL 3.x just yet.

For OpenGL context creation, developers need to specify which version and whether they need the code to be compatible with older version or plain-through forward compatible context. This is done with its context creation, and it's the problem in using with GLUT.

GLUT offers no context creation setting. It forces developers to use what's there automatically and compatibility in mind across all the platforms. I found this out when I wanted to know which OpenGL version it created for my testing application via glGetString(GL_VERSION) which returns 2.1 ATI-7.18.11. Darn, no way! With this set up, I can't even test the code with 3.x. So I turn it around finding a more customizable windowing library.

It comes FreeGlut, a free version and open source alternative of GLUT. GLUT, in fact, is not an open source. Its license goes to Mark Kilgard. Any modified source code of the library must be shipped with the the product itself. It restricts some of limitation most developers won't apply. Then I have my hands on FreeGlut. It turns out that FreeGlut is not friendly with Mac OS X at all. Its user-based not land in Mac platform but spread throughout Windows, and Linux/Unix. Only a very small percentage of Mac users use it. I decided to use this because it's same same code to GLUT and its cleanness and approach in hooking function calls which I like the most but with additional ability to customized in OpenGL context creation!

At the time, its main website listed out 4 major stable packages to download. No pre-build available to download for Mac or any other platforms. So I have to manually compile and build it. Several failed attempts to compile and build come to desperate to find another solution. So I turn around again to another one, GLFW.

I successfully compiled and built GLFW and not much in effort to hook it up with my application. Everything is done but with one exception that my own timing system (implemented as part of testing OpenGL platform) doesn't fully work out cleanly with GLFW.

To be more elaborate on timing system, I implemented it since my day one in testing OpenGL application. In game, we need not the ability to fully render all content of the game in full speed of 60 fps but it would be better to restrict it or even no limitation on fps at all. That comes with the topic of Fixed Timestep and Non-Fixed Timestep. I am inspired by the notion of fixed timestep back in a day I have worked with XNA. Its definition and simple explanation raises the need to provide both options of rendering approach and timing in game. In fixed mode (with ability for you to set a target fixed time as well), your game will try (for my implementation, it will restrict!) to render the game in X fps in which X is what you can set. Not all games on different platforms need to be capped at 60 fps. Consider a simple game with slow paced rendered on low-powered mobile device, just 25 or 30 fps can do a trick. Even web-based game which goes for 25 fps for flash styled. It has its own purpose so timing system is (at least to say) a major part in game application.

My experiment with GLFW only found an issue with my timing system. I found out that GLFW already capped the frame rate at its will automatically, so when I combine it with my timing system lied internally in game loop, the game will be double slow delayed in time! So things won't get smooth out as it seems to be. I fixed it by disabling a fixed mode, and let GLFW does its work on that restriction alone. It works fine but somewhat raises a question. How can I set a target fps of the game to run with GLFW? I filed out a question here on a main soureforge.net site of the project. I expect someone would come and answer it.

In addition, I experimented with non-fixed mode as well. By setting glfwSwapInterval(0) which means to disable v-sync mode, the application is told to be relied on the capability of software or hardware as it goes, no more restriction here. Also with non-fixed mode is enabled in my timing system, the things run out as expected. The fps goes beyond 8000 which is similar to what I have tested with GLUT. This goes well with fixed-mode enabled on my timing system, now I can cap it to run says 30 fps or 60 fps at will. But that result only shows in window mode, whenever I go to full screen mode the polygon drew is tearing / unsynced / and jittering. I truthfully think that it's because of v-sync is disabled by the result of calling to a mentioned function of GLFW. Another question raises again on how to prevent those effects with the software / hardware (graphics card) were already told to render the content as fast as possible with no restriction ? So I replied to my own earlier question and ask about this as well.

A bit to mention that during a laboring test with GLFW, I even went back and tried to find a way to compile FreeGlut. Indeed, I found one. Initially I don't care even if it does only compile with not latest version but rather 2.6.0, just give it a go. After successfully compiled and built the libraries, then hooked up with my code in action, I feel disappoint immediately. Why? FreeGlut uses old X11 system to show up its window. I don't like this as it needs to open up X11 agent program first before it can even run your program. That's case bringing me back and forth and at best try to make GLFW works out!

For now, I will use GLFW at least for testing purpose with my OpenGL stuff for a long while. It has potential to be my integrated windowing system for yet to come a game product (hmm? hopefully). It offers flexible integration with callback and specific context creation. Also with non-to-mention, it breaks out the loop design (remember glutMainLoop()) and allows developers to hook up the function calls inside instead. At last, if I could find a solution to prevent those tearing / unsynced / jittering effect from uncapped rendering approach, I will definitely update here at my blog.

Updated