Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.

The Render engine

Hello everyone!

This post is intended as sort of a a walk-through/overview of the render engine used by the Solkraft Game Engine(it will not contain a section on rendering the GUI, that will be a separate post):

The render engine is based on OpenGL and several support libraries that we would like to first mention. For creating and managing the window we use “GLFW” (we also use this for input in other parts of the engine), for handling image loading and conversion to OpenGL textures we use the “SOIL” library and for easy access to OpenGL functions we use “GLEW”.

The core structure of the render engine i composed of two classes:

The RenderManager class: Is a singleton that the rest of the engine can interact with regarding graphics and rendering. For example: when an entity wants to sign up to be rendered it contacts this singleton, when the user wishes to re-size the render window or when something wants to receive camera focus.

The GlWindow class: Is the other class in the render engine representing the actual render window. This class is responsible for interacting with OpenGL and the Shader program when it is time to render. It also communicates with the “RenderManager” class to get the list of entities that are supposed to be rendered “the render queue”.

To try and better explain how the render engines “pipeline” functions we will go through all the steps from when an entity registers with the render manager to it being rendered in the window:

The requirements for an entity to be able to sign up for rendering are that it possess three attributes, the “Sprite” attribute which is a text string representing the name of an image in the “images” folder of the users project, the “DepthLayer” attribute which is an integer that represents the depth layer that the entity’s graphics will be rendered on with zero being “closest to the screen” and the “GLTextureHandle” attribute an integer representing an OpenGl texture handle, the value of this attribute will be assigned by the “RenderManager” later in the process. When these requirements are met the user can call the “RenderManager” and register the entity for rendering. The first thing that happens when an entity is registered for rendering is that it is added to the render queue and sorted based on the value of its “DepthLayer” attribute, after that the value of the “Sprite” attribute is compared to the names of images that have already been loaded in to memory, if a match is found the “GLTextureHandle” attribute is set to the corresponding texture handle of the image name. If it is not found, a function in “SOIL” is called and a new texture handle is returned and then assigned to the “GLTextureHandle” attribute, it is also added in to a “map” of already loaded images along with the value of the “Sprite” attribute.

The entity is now signed up to be rendered and in the next “onFrame” function call to the “RenderManager” the “GlWindow” class will be tasked with rendering it and all the other registered entities. When this happens the “GlWindow” starts by gathering necessary information for the entity that is about to be rendered, first it sends a message to the entity requesting its transform matrix which it will use as the model matrix in a “model * view * projection” calculation later in the shader program. After that, it looks up if something has camera focus, if something does then that entity’s camera matrix(another matrix stored in the entity) will represent the camera’s matrix and will be assigned to the view matrix in the aforementioned calculation, if nothing has the camera focus then the view matrix will be represented by an identity matrix. Now that it has completed gathering the necessary information from the entity and the “RenderManager” it is time to set the active texture and attribute arrays, this is done by calling several functions in “GLEW”. When setting the active texture the “GLTextureHandle” attribute of the entity is used as the texture handle argument. Then there are the two attribute arrays, one with vertices and one with UV coordinates. In the vertex array there are four vertices going from (-0.5, -0.5) in the bottom left to (0.5, 0.5) in the top right corner. We have designed it this way so that we can reuse these same four vertices for drawing all entities, using the scaling part of the entities model matrices to represent the actual size of the entity. When this is all done the information is sent of from the application and the entities are rendered in the window.

We hope that this has been helpful in better understanding how the Solkraft Game Engine functions under the hood.

Expect more of these posts over the next few days covering other parts of the engine as we approach the final presentation of our project on 13/3-2015.

There will also most likely be some posts regarding the demo game that we will be developing for the engine this week.

Be Sociable, Share!

Leave a comment  




Submit comment