Fixed Memory Architecture

From BlackCompanyCoding

Jump to: navigation, search

Game and engine code should be written with a fixed memory architecture in mind. By fixed, we mean the memory exactly matches the address space used, and that the maximum size of the address space is known in advance.

There are two main reasons for this:

1) Portability to console platforms

Some consoles do not have any form of virtual memory system available at all. In addition, the amount of memory available is fixed, and small (compared to PC development). While it is simple to emulate a fixed memory system on a virtual memory platform, it is very difficult to do the reverse.

2) Performance/predictability

If the memory limits are known in advance, and the code is forced to stick to a fixed memory budget, then the end-user can be assured that the memory they have is either sufficient or insufficient, without having to test every single game situation to find one which uses the maximum amount of memory. In addition, the fixed budgets make it much simpler to spot and fix memory-leaks. By fixing the memory budgets, machines with more memory do not hide bugs which would appear on lower-memory machines.

Using a fixed memory architecture means that the code is much less amenable to using dynamic allocation and deallocation; this restricts the amount of dynamic allocation and deallocation which can be done. This is a limitation on the design of code which forces developers to be aware of the memory usage characteristics of the code that they write, which should make its design clearer and more explicit.

Exceptions

NB: Tool code is exempted from this limitation, as it is expected that tool code 1) will need to process much larger amounts of data, 2) will always run on a PC, and 3) is less interested in performance than in clear and easy to maintain code.

Personal tools