Building upon the low-level API introduced in an earlier post, we will take a look at the platform-independent high-level API today, which provides support for the things that are to be expected from a game engine file system.
Typically, a file system in a game engine comes with all the bells and whistles like multiple file devices, support for zipped files, encryption, device aliases, asynchronous I/O, and more. But buried underneath every file system lives a low-level implementation (directly using OS/SDK functions), which in turn is used in the high-level file system.
This low-level implementation should be the only platform-specific file implementation in the whole file system, and is the topic of today’s post.
In game development, C++ enums are often used to denote that certain values can be combined using bitwise-operations, resulting in so-called flags. However, enums in pre-C++0x exhibit some drawbacks which will be discussed and improved upon in this post.
This is the final installment in a series of posts about Molecule’s memory system. Today, we are going to look at the final piece of the puzzle, glueing together different things like raw memory allocation, bounds checking, memory tracking, and more.
assert() is a very useful tool for ensuring that pre- and post-conditions, as well as invariants, are met upon calling or exiting a function. If you have never used assertions before, start using them now – they will help you find bugs in your own code, and quickly highlight when code is not used in the way originally intended.
Still, there are a few bits missing in the standard assert(), which is why we will try to build an improved version of it today.
In the last few installments of the Memory system series, we were mostly concerned with how ordinary memory allocation using new and delete works internally, and how we can build our own tools to provide additional functionality. One thing we haven’t discussed yet are the memory arenas which are responsible for actually allocating memory, while providing additional things like bounds checking, memory tracking, etc.
Continuing from where we left off last time, we’re about to optimize our NewArray and DeleteArray function templates for POD-types this time. Let’s start easy by talking about the implementation itself first, and then putting pieces of the puzzle together one by one. Following is the implementation of the function templates NewArrayPOD and DeleteArrayPOD:
In the last installment of the memory system series, we covered how new, delete, and their variants work. This time, we’re going to build our own little toolset which allows us to create new instances (or arrays of instances) of any type using custom allocator classes in a standards-compliant way. Be prepared for some function templates, type-based dispatching, template magic, and nifty macros.
Before we can really delve into the inner workings of the Molecule Engine’s memory system, we need to cover some base ground first. Today, we’re taking a very thorough look at new, delete, and all their friends. There are some surprising subleties involved, and judging from the interviews I conducted, sometimes even senior level staff messes up questions regarding the inner workings of new and delete.
One problem which often arises during programming is building a base set of functionality which can be extended by the user, while still being modular enough to make it easy to replace only certain parts of an implementation. I guess everybody of us has faced this problem at least once, and came up with different solutions. There is a really powerful and elegant technique for solving this kind of problem, which is what I want to show today.
Today’s post is about configuration values in the Molecule Engine – how they are declared, how they can be used, and how they are implemented.
The following things were important to me when designing the config system:
One scenario that is quite common in all game engines is having to look-up some resource (texture, shader, material, script, etc.) based on a string, which could look like the following:
Texture* tex = TextureManager::FindTexture("my_texture");
