Game Engine v0.0.8

Is hard to believe but the game engine is getting better and better as time passes. This month I focused on fixing two significant issues related to memory and rendering.

Here is a demo of v0.0.8 of the game engine:

In version v0.0.8 of the game engine I fixed some memory leakage issues and improved the rendering-ordering algorithm.

Substantial memory leaks were happening all over the engine. The leakage was something I could no longer ignore, so this month I focused on fixing this issue. I used Xcode's Instrument app to help me locate the memory leakage throughout the engine. I'm now happy to say that the engine is 99% leakage free. There is a small leakage that is happening when using the Collision Detection System. Unfortunately, I caught the leakage after I created the video demo for v0.0.8. The good thing is that is small, and I will fix it in v.0.09.

I also added Ordering functionality in the scenegraph. As you may know, entities such as text, skyboxes, and images, must be rendered last due to Blending requirements. Unfortunately, it meant that I had to add these objects into the scenegraph in a particular order. Naturally, such restriction is not acceptable. So, I added functionality into the scenegraph that orders these entities depending on their Z-Depth value.

I also found another issue related to Shadows. I noticed that the Shadows in the game engine have aliasing problems. I will fix this issue in v0.0.9.

Thanks for reading.

Game Engine Beta v0.0.7

I believe the engine is almost complete. Most of the functionalities expected in a game engine have been implemented. For example, the engine is capable of:

• Rendering 3D models with textures/normal maps
• Supports Shadows
• Supports 3D model animations
• Supports Skyboxes, Text, and Sprites rendering.
• The engine contains a Physics engine with a Collision Detection System
• It makes use of BVH algorithm in its Frustum Culling algorithm
• among many other minor implementations

However, it lacked one crucial element found in every game engine, i.e., a Particle System.

Back in beta v0.0.4 of the engine, I did implement a particle system. However, it was rudimentary and basic. I wouldn't consider it a particle system, per se.

So this month I decided to scrap the original Particle System I had written back in v0.0.4 and focused on implementing a real Particle System.

Implementing a particle system is quite simple. I will write an article how to implement a Particle System soon, but if you are dying to know how to write one, this site has an excellent post on it. After reading this article and other books, it gave me a good idea how to implement a Particle System.

Well, here is a video showing the Particle System currently employed in my game engine.

Added particle system to the engine. The engine can generate smoke, explosions and other particle types.

What I need to do soon, is to write a Particle System editor similar to 71 Square Particle System, but for 3D particles.

That way, YOU, can easily import your particle effects into the engine.

Thanks for reading.

Game Engine Beta v0.0.6

Hi there,

These past two weeks I've been working on implementing a Frustum Culling algorithm for the engine. Here is a video of beta v0.0.6 of the engine with Frustum Culling.

In the previous beta version of the game engine, I had 20 soccer players on the screen. And I noticed that the game was a bit choppy. I recall the Frames-Per-Second (fps) being below 30. The engine was rendering all 20 players, the two goals, and soccer field at every frame without analyzing if the camera was able to see these models or not. You can agree that this is a problem.

The logic behind a Frustum Culling algorithm is essentially this:

"If the camera does not see the 3D model, then the engine should not render it".

Implementing this logic, allows you to have 100 models in a game, but only 10 or so many models being rendered at any time. Thus, improving the game experience.

For example, the minimum acceptable fps in a game is 30 fps. With Frustum Culling, the engine was able to render the entities at 60 fps and the lowest it got was 49 fps.

If you are entirely new to Frustum Culling, keep reading. I'm going to give you a brief tutorial on how Frustum Culling works.

What is a Frustum

A game engine requires a camera. During initialization of a game, the engine computes a Frustum. A frustum is a chopped pyramid. And 3D models within the frustum are visible by the camera and by YOU.

Notice how the frustum is composed of six planes.

What is Frustum Culling

A Frustum Culling Algorithm tests which 3D models lie within the frustum. If the 3D model lies outside the frustum, then it is ignored by the rendering engine. If the 3D model lies within the frustum, then it is rendered.

Frustum Culling Test

Testing if a 3D model lies within a frustum is quite simple. First, the 3D model is wrapped within a box, in this case, with an AABB (Axis-Aligned Boundary Box).

Then, the eight vertices of the AABB are tested against a plane. In a Frustum Culling algorithm, the AABB's vertices are tested against all six frustum's planes.

If all vertices lie on the negative side of the plane, then the model is considered being outside the frustum. Otherwise, it lies within the frustum.

And that is it. You repeat the process for all game entities in your game.

Improving the Frustum Culling Algorithm

Frustum Culling improves the efficiency of a game engine, but it is not enough. If your game only has ten 3D models, the engine can quickly do a Frustum Culling on all these entities. However, if your game has 200 or 1000 objects, then Frustum Culling by itself may not improve the efficiency of the engine.

What you need is an algorithm that can analyze the spatial area seen by the camera. For example, if the camera does not see the upper-left quadrant, then the engine should not perform Frustum Culling on the entities that lie on this quadrant. There are many algorithms that you can use. In the engine, I implemented a Boundary Volume Hierarchy (BVH) tree.

The image below shows the idea. I recursively wrapped the game entities in an AABB, until there is only one model per AABB. Then, starting from the root node, the engine test if the camera sees the AABB node or not. If the camera does not see the AABB node, then all the children node, containing the 3D models, are not rendered.

If the camera does see the AABB node, then it keeps performing Frustum Culling on the next AABB child node, until it reaches the leaf node.

In the example shown above, the algorithm rejects the red AABB box and does not need to test if the red and gray car is seen by the camera.

The camera does see the blue AABB box. Thus it tests the children nodes of the blue AABB box. It does this on and on until it reaches the leaf nodes. In this case, it sees the blue and orange car, but not the yellow car.

And that is Frustum Culling. I hope you learned something.

Thanks for reading.

Game Engine Beta v0.0.5

In version v0.0.5, I ported the game engine from OpenGL to Apple's Metal API.

Initially, I planned to keep working on the 3D soccer game using v0.0.4 of the engine. However, I decided to port the engine once I saw an Augmented Reality demo. I realized that Augmented Reality (AR) is the future of gaming and it may be a good idea to have this feature available in the engine. However, the AR framework only works with the Metal API; it does not support OpenGL.

To be honest, my goal was to port the engine to Metal in a year or two. I was not planning to port it so soon. Part of it was that I feel I'm still learning Game Engine development and didn't want to overwhelm myself. The other reason was that porting a Game Engine from one API to another is not an easy task. When I saw the AR demo, it was the push that I needed.

To my surprise, porting the engine to Metal was quite simple. In less than two weeks I had ported the major components of the rendering engine. I also became aware of some misconceptions I had with computer graphics and OpenGL; essentially with Normal Maps and Shadows. Metal is so simple to use that it highlighted some errors I was making with OpenGL.

Overall, I would say that the porting took about a month to complete. It does not include the time it took to learn Metal, which it should take you about a week; assuming you know computer graphics.

Here is a video showcasing the 3D soccer game with Metal. In my opinion, it looks better than when I was using OpenGL, but then again I am using better 3D models.

This video shows the game engine using the Metal API for its rendering operations. The game engine no longer uses OpenGL.

So, the engine now runs entirely on Metal.

Goodbye OpenGL

Hola, Metal

Thanks for reading.

The state of the Game Engine (Sept 2017)

I want to give you a brief update on the current state of the engine. With my day job and other responsibilities, I had to scale down the amount of time I spent writing on this blog. However, not for a second, have I stopped working on the engine. If you haven't seen any updates, is because I decided to do something unorthodox.

Back in July 2017, I decided to take a detour. As you may recall, I was working on developing a 3D soccer game using my game engine. At that time, the engine was being powered by the OpenGL API. I have nothing but great things to say about OpenGL. I think it is an amazing API and if you are interested in learning computer graphics, I strongly suggest to start by using it. However, the time had come for me to port the engine to Metal.

Metal is the new Graphics API from Apple. In my opinion, Metal is a lot easier to work than OpenGL. It is less convoluted, and it leads to clean code. And more importantly, it is a lot easier to grasp. If you already know OpenGL, learning Metal is going to be a walk in the park.

So, why did I decided to port the engine to Metal? Part of the answer came down to future OpenGL support. I learned that Apple is very committed to Metal and there are no plans to keep updating OpenGL on mobile devices. I also found out about Apple Augmented Reality framework. Looking at some demos, it is apparent that Augmented Reality will play a huge part in the future of mobile gaming. And it so happens, that the Augmented Reality framework from apple only works with Metal. Of course, I plan to implement AR features in the engine.

I have to admit, porting the game engine from one graphics API to another is not something to look forward. However, it was easier than I thought. And I believe that Metal's clean paradigm had a lot to do with the ease of this task.

As of today, Sept 16, 2017, the engine has been completely ported to Metal.

So why haven't I given an update on the engine?

It has to do with the fact, that through the porting, I learned of many mistakes I had made using OpenGL. And I'm finding of these errors through the mobile soccer game. So, that is what I'm doing now. I'm going back and forth, tweaking issues in the engine and the game. Making sure everything is correct and working properly. Unfortunately, this is taking longer than I planned, but I think is important for the engine to be reliable before I release it to the public.

I plan to release version 1.0 of the soccer game by the end of 2017. Once released, I plan to complete the API documentation for the engine, User's Guide and tutorial by May 2018. The release of the engine will soon follow after this. I haven't decided to release the engine as open source or closed source yet. I'm still evaluating this decision.

Well, that is what is going on in my world. Thanks for reading.