After we finished the control schemas last time, it’s time to look a bit deeper into OpenGL.
Since we want to be able to build a basic UI, we will take a look at drawing 2D in OpenGL today. Also we will have a look at texturing our scene and UI elements.
Last time we started, adding control elements to the scene. We defined a controller class, that could take gamepad input and manipulate the camera position accordingly.
Today, we want to extend that, by adding keyboard and mouse control. For this simple scene, we want the user to be able, to use all three control schemes simultaneously.
On the Keyboard, the user should be able, to control the latitude and longitude via WASD or the arrow keys, and the center-distance via 1 and 2 or 9 and 0 respectively.
With the mouse, latitude and longitude should be controlled via the movement of the mouse, while using the mouse-wheel to control the center-distance.
In the last chapter we created a pretty cool scene with movement and sound.
Today we will take a look at the most important UI interface for games ever: Controls. Until now, our scene was pretty static, with the camera flying around wildly on a kind of weird, prescripted path.
Let’s implement some controls, to steer the camera on a spherical path around the main cube. Imagine a sphere around the cube and the camera as a kind of bubble on the outside of that sphere; always looking into the center. The user can choose to fling the camera-bubble along the latitude and longitude of this imaginary sphere, as well as shrink or grow the sphere itself (make the radius closer or wider).
We want to end up with a program, where the user is able to control the scene via a Gamepad, the keyboard or the mouse as he chooses.
In the last chapter we learned a bit of basic OpenGL functionality. While not enough, to be actually useful in a game, it got our appetite wet and gives a good base, from which to investigate further.
Today, we will mainly leave OpenGL behind and focus on the other second-most important user interface in games: Sound.
More to the point: Sound, using OpenAL. That choice is convenient for a few very simple reasons:
- It’s available in nearly any possible target system
- It’s open and rock solid
- It’s very simple to understand
- It has most of the basic features, you could want from a game sound interface
I am currently doing some basic research, how one could make games with basic OpenGL, OpenAL and system dependent libraries. At the end of which a simple multi-plattform game engine should be the goal.
I will post updates to the things I found out here, in form of a diary/tutorial as soon as I reached another milestone along the way.
Since I start developing on my Mac, we will also start supporting the Mac and move up from there.
Creating an OpenGL enabled application on OsX Lion
Our first project, to get a hand on OpenGL on the Mac, will be, to create a simple application, that draws a rotating cube inside a Cocoa View and behaves nicely with the system. It should work in Window-Mode and support the Lion’s way of doing fullscreen.
As I did rant about the lack of a useful build and test ecosystem in C++ earlier, I obviously needed to write my own for my development.
The first step for this is the Test Framework.
For every Unit-Test framework, one rule is more important than any other: The more difficult it is for a developer, to write and perform unit tests, the less he/she will write them. Therefore any unit-test framework that aims to be really used, needs to be as simple as possible.
For the development of my game engine, I will accomplish that, by utilising Python in the build itself, to automatically find any test class written, and perform the tests while building.
To start doing something useful with my Mac, I started putting it to work in game development.
First thing on the agenda: Find a suitable Graphics Engine, that would compile on the Mac and the PC and ideally be able to run on iOS too, so I won’t have to learn a second Graphics Engine, when developing for iOS.
Ogre and Irrlicht both seemed to be good candidates.
After initially looking through some sample code and the specs, Irrlicht got 2 Points over Ogre, because I liked the API a bit better and it could handle almost any resource format. Meaning, that I could throw Blender files, Images and Textures right at it, without converting them into an Engine-specific format.
Ogre on the other hand has a much more active community, better Sample and Tutorial features on it’s wiki (BIG Plus). What really sold it to me though, was an official support for iOS, that doesn’t exist on Irrlicht.
So Ogre it is then.