The hero’s final destination: Geometry Planetary System a.k.a. Graphics Engine!

Hello my fellow readers! As a man of my word, here I am again. This time will be all about my Graphics Engine. I will talk about its architecture in general (components & description) and also have included a video so you can see it running in all its glory =D

Let’s start from the beginning. This engine was built in Visual Studio 2010 using C++ and OpenGL. I used the Pyramid Demo (Chapter 5) from the OpenGL SuperBible (5th edition) book as my starting point for the implementation. During the last month of the quarter, all the students worked in tandem with Prof. Keenan refactoring this code (Pyramid Demo), in order to make it more efficient and flexible, but at the same time more elegant and re-usable. In my opinion, that’s the whole idea behind a Graphics Engine, to be fast but flexible at the same time.

Basically we took the book’s code and reorganized it into different classes in order to achieve our objectives. The majority of these classes were created using the Singleton Pattern (one-instance class), and the idea behind this move was to build a collection of Managers to handle the different components of the Engine: Renderer, Camera Manager, Texture Manager, Objects Manager and Objects Library. For the porpoise of this post, I shall give you a small description of these components:

• Renderer (Graphics Manager): handles the majority of OpenGL calls, including all the initialization, setting up, program main loop, input handling and program shutdown. This one is basically the orchestra director and the one piece that glues the whole engine together.
• Camera Manager: takes care of camera administration, including creation and destruction of all cameras, as well as setting up a primary camera (main frustum) and alternative cameras for frustum viewing.
• Texture Manager: this manager is in charge of loading textures to GPU’s memory, storing the appropriate texture handlers, upon request give the texture handlers and freeing all texture resources when the program is shutdown.
• Objects Manager: holds pointers to all objects created during program execution (at least all objects that the engine will draw). This manager also handles on-the-fly texture changes for current selected object, and finally, destruction of all objects when the program is close.
• Objects Library: this singleton class is in charge of creating models (geometry figures) in GPU’s memory using Vertex Buffer Objects and Vertex Arrays, and also storing the respective model handler (GLuint). These handlers are later assigned to objects to specify to kind figure they represent.

Now, I shall present you the demo (video) I recorded and submitted for this assignment. Hope you enjoy it!

I will probably post one more time to cover other details about the Graphics Engine before moving onto the second Game Engine Programming class (next week). So, I guess I will see you soon again! Have a nice one!

Adios!

And right there, where nobody con see him was hiding the last mini boss... The File System!

Once again my fellow dudes, apologies for disappearing for almost three weeks, I was M.I.A. working on stuff for the three classes I am taking this quarter: A.I. for games, Graphics Development and Game Engine Programming. The quarter is over, yesterday was the last day of activities at the university, and what an effort I did to finish all the assignments on time. For this week I had: Graphics Development’s homework #4 and final exam, A.I. for Games’ take-home final exam, and Game Engine’s final essay and final project (Graphics Engine). I finished all of them on time (almost all completely, only failed to finish the A.I. final) after two days in a row without sleep (not even a small nap), so now is time to relax a little bit and tell you the story behind Game Engine’s last projects.

Since my last post I owe you guys one describing my File System implementation, so here you have it. Unfortunately, this was the last system I started from the four core systems, and since I started it two days before deadline, I did not have too much time to refine and improve my first design. But I am still quite satisfied with how the implementation ended up looking like.

The core functionality of the File System was to handle reading and writing different types of data to files on Windows. In order to do this (and due to time constrains), once again we ended up using the Win32 Library (Windows.h) as our start point for the implementation.

The system’s main functionalities were covered by creating a FileHandler class which wraps the following functions from the Win32 Library: WriteFile, ReadFile and FlushFileBuffers. All these methods use HANDLEs to manipulate files, and some of them use up to five (5) parameters as input. Therefore, the idea behind this FileHandler class was to hide some of the advance features this Win32 functions have, and create a simple interface the user can use to upload/download data to disk. The FlushFileBuffers function was used in combination with WriteFile to allow the system to write as much data as possible to memory, and then proceed to download all of it in one shot (writing to disk is a very slow operation, but one that is unavoidable sometimes, so if we must to do it, we better attempt to do it altogether in one try). Here you have a brief summary of the functions prototypes and description:

• FileHandler(filename,mode) – Class constructor (Specifies the filename and read/write mode)
• read(buffer,size) – reads size bytes from file into the specified buffer
• write(buffer,size) – writes size bytes from specified buffer to file
• flush() – flushes (writes) to file all data stored so far in the buffer

Last, but certainly not least, as part of the assignment I also developed an Archiver System. Essentially this class is an advance data structure that holds different types of objects inside (it has a linked list with pointers to each one) and has the functionality to download all this data to a file in an structured way (using an archiver header and table of contents), so that you can also read it back to memory when needed. The whole porpoise of the Archiver in the gaming world is to be able to store/load from disc (hard drive or optical media) files that contain complete models (maps, characters, etc.). For example, if we are talking about a character, the file would hold data regarding vertices, normals, texture coordinates and data, sounds, animations, etc.

Well my dear followers, hope all this information is useful for you or at least interesting in some way. I will be posting tomorrow the video of my Graphics Engine‘s demo followed by a post describing its architecture and implementation. Have fun tonight!

Adios!