Tag Archives for graphics

Optimising animation based collision volumes

Last time we talked about how we can approximate objects with complex shapes using simpler ones for our game’s physics simulation.

Further, we saw how we can use an often already existing feature: a skeleton for animating sprites – or vertices of a 3d-mesh – to make our collision shapes change position, and even size, as our object deforms.

Today I want to look at how knowing about the behaviour of CPUs – and especially their caches and memory – we can use simple optimisations to implement collisions with such objects very efficiently.

Continue reading →

Animation based collision volumes

There is hardly a single game that does not need some form of collision between game objects. In many cases it is enough to approximate the shape of an object by a simpler one to simplify and speed up collision detection. It is for example very common – especially in 2D games – to use circles or boxes as colliding shapes.

Today I want to talk about how we can make use of collision code written for simple shapes like circles, and still end up with much more complex collision behaviour.

Continue reading →

Design patterns in game development: parsing OBJ files

Today we will take a look at a common task in game development: parsing asset files – from a code design standpoint.

Using the example of Wavefront OBJ files, we will explore the usefulness of thinking about our code using design patterns.

Our goal will not be to use design patterns to create code. Instead, I would like to highlight how much of our code is full of such patterns – whether we think about them or not – and how realising this can help us communicate more efficiently with other programmers.

Continue reading →

Roche Fusion Technical Recollection 3

In this third instalment of Twitter-powered reminiscence we will continue discussing more and more of the different systems I developed for Roche Fusion in the last few months of the game’s development.

We will focus mostly on their technical and graphical aspects, since that is my area of expertise, and the purpose of this series of posts.

Continue reading →

Roche Fusion Technical Recollection 2

Today we will continue our exploration of Roche Fusion’s development process that we started last week.

We will do so from a technical point of view, exploring some of the various systems I developed for the game. With my role as team-lead and graphics programmer, this mostly means that we will mostly be looking at graphical effects.

Continue reading →

Roche Fusion Technical Recollection

A few days ago I was idly scrolling through my twitter history reminiscing about the last few years of my activities as game developer. For about two years a major part of that – and my life in general – has been Roche Fusion, the game project I started together with Tom Rijnbeek in September 2013, and which we finally finished – with a team of 7 – in January 2015.

For today’s post I thought I step through the major points of Roche Fusion’s early development from a technical standpoint, and give some insight in our development process.

Continue reading →

Localised Crepuscular Rays

Crepuscular rays, volumetric rays, or god rays have become a common effect in games. They are used especially in first and third person games – where the player can easily look at the sky – to give the sun, moon, or other bright light sources additional impact and create atmosphere.

Depending on how the effect is used it can emphasize the hot humidity of a rain forest, the creepiness of a foggy swamp, or the desolation of a post-apocalyptic scene.

While there are multiple ways to achieve this and similar effects, the method we will look at in particular is the approximation of volumetric light scattering as a post-process using screen-space ray marching.

In this article we will quickly step through the idea behind this algorithm, and how it is commonly used. We will then show how we can easily expand from there to create a solution that works well with multiple light sources, including some source code and images.

Continue reading →

Designing a shader loading and management data structure

Last week we looked at how we can use the builder pattern to build shader programs out of individual shaders. We abstracted away all actual functionality in favour of a clean and easy to read interface.

In that post we assumed the existence of a shader manager – an object that held track of all our shaders and that we could ask for any of them given their type and a string name.

Today we will design a system fulfilling those requirements. Our goal is having this system take over as much work as possible, so that we do not have to bother with any of the details when using it.

Additionally we will look at how we can easily and automatically load shaders from code files – though this part of the system could be easily replaced by one loading them from a different source.

We will take an incremental approach to these topics, building our system step by step, according to our requirements.

Continue reading →

Linking shader programs using the builder pattern

This post is the first in a series on design patterns in game programming.

Design patterns play an important role in computer programming. Not every problem can be solved with a pattern, and not every pattern is useful in all circumstances. However, they can be powerful thinking tools when applied to the right kinds of problem and help us understand and design solutions quickly and without reinventing the wheel every time. Similarly, they can aid us in communicating our ideas efficiently to others.

Today, I would like to take a look at the builder pattern.

I will not go into the formal definition of the pattern itself – there are enough other sources for that. Instead we will look at just one example where I use the builder pattern in my C# OpenGL graphics library.

I will first show how I solved the problem in question previously, point out what I did not like about that solution, and then show how we can apply the builder pattern to a much nicer way of doing ultimately the same thing.

Continue reading →

Using multi-threading to animate and speed up loading screens

One feature that almost all games have in common is loading screens.

Many small games can get away with a single loading screen at the start of the game to load all or most assets.

Most larger games have one before every level or environment, or at least for major transitions. The only way to get around loading screens entirely is to have only a small core engine that is loaded at the beginning of the game, and to then load everything else (other engine parts and frameworks, assets, script files..) on the fly.

To make the latter feasible without causing the game to freeze at times, concurrency is a necessity – content has to be loaded in the background while different threads update the gamestate, render it, and keep the interface responsive.

This is a complex topic however, and too big to tackle in this post.

Instead we will look at a smaller problem and how to solve it.

Continue reading →