Issues

From BlackCompanyCoding

Jump to: navigation, search

There are aspects of game development which restrict the manner in which we can use C++ to write our software. Synopses of these issues are given here.

NB: Under construction...

Memory usage

When developing for a PC environment, it is possible to use dynamic allocation much more agressively without noting any real drawbacks in performance. This is because the virtual memory system on the PC platform seamlessly shuffles pages of memory around and maps them to a wide ranging virtual address space without the need for program intervention. The net result of this is that memory can be allocated and freed at will, and any resulting fragmentation in memory will tend to be smoothed out. Even in pathological cases where the virtual paging system cannot cope with things, a disk based swap file will be brought in to hide the problem, again without program intervention.

On a modern games console, as with many embedded devices, no such systems exist. Memory exists in a relatively small, fixed memory architecture, with no virtual paging, and no swap-file. As a result, casual use of dynamic allocation and deallocation can quickly balloon memory usage, with very little actual use being made of the memory.

Many of the common and useful patterns in C++ architecture require dynamic allocation of objects to operate. Some allocations are strictly required, as they represent data being loaded into memory for use and are unavoidable. In some cases, the objects being allocated are few in number and the allocations occur at initialisation-time; such allocations are relatively friendly to a fixed memory architecture. Other allocations, such as creation and destruction of temporary variables many times per frame, are not desirable.

In all cases, care must be taken to limit memory allocation so that its impact on memory availability and usage are known and predictable.

STL collections

Following on from the point about memory usage, use of STL collection types must be carefully managed. These types are built by dynamic allocation at run-time, and so can easily introduce undesirable memory allocation into the system. Used carefully, the allocation can be made as 'up-front' as possible to minimise unpredictable interactions with other memory allocation.