3.5 memory and io systems

1. Chapter 3.5
Memory and I/O Systems

2. 2
Memory Management
 Only applies to languages with explicit
memory management (C or C++)
 Memory problems are one of the leading
causes of bugs in programs

3. 3
Memory Management
 We have three goals when working with
memory
 Safety
 Knowledge
 Control

4. 4
Memory Management
 Memory fragmentation
 Free physical memory is only available in
small sections
 Can prevent an allocation from completing
successfully even if there's plenty of free
memory
 Virtual addressing will greatly help with
fragmentation problems

5. 5
Memory Management
 Virtual addressing
V ir t u a l
A d d r e s s T a b le
B lo c k 2
B lo c k 4
B lo c k 3
B lo c k 5
B lo c k 1
P h y s ic a l M e m o r y
B lo c k 1
B lo c k 4
V ir t u a l
M e m o r y V ie w

6. 6
Memory Management
 Static memory allocation
 If all memory is statically allocated there will
be very few problems

Leaks

Fragmentation

Running out of memory
 Very restrictive
 Lots of wasted memory
 Old games used to be done this way

7. 7
Memory Management
 Dynamic allocation
 Much more flexible than static allocations
 Lots of potential problems
 Need to override global new and delete to
take control over allocations

8. 8
Memory Management
 Memory manager
 Heaps are collections of memory allocations
 Override class-specific operator new and
delete to assign classes to heaps
 We can add some simple error-checking
schemes to prevent memory overrun
problems

9. 9
Memory Management
 Memory leaks
 A memory leak is a memory allocation that
is no longer necessary and was not
released by the program
 Memory leaks can cause the game to use
up resources and run out of memory
 To find all memory leaks, we look for all the
allocations that occurred between two
particular points in time

10. 10
Memory Management
 Memory pools
 Memory pools are contiguous blocks of
memory used to allocate objects
 Allocations are extremely fast
 There is no fragmentation
 They will usually have some unused space
 We can allocate objects from specific
classes with a simple macro

11. 11
Memory Management
 Memory pools
E m p t y b lo c k
E m p t y b lo c k h e a d e r
B lo c k w it h d a t a
a b c

12. 12
File I/O
 Sometimes full file I/O not available on
all platforms
 Different ways of accessing different
devices
 Memory cards, network, etc
 Usually have no control over physical
disk allocation
 Which can lead to long load times

13. 13
File I/O
 Unified file system
 Platform independent
 Provide same interface to different types of
media
 Based around FileSystem class

14. 14
File I/O
 File system
 Uses concept of streams
 Stream can be the source of data
 Possible sources

File, memory, network
 Or it can be a layer that adds some
properties
 Possible layers

Buffering, compression, range, etc

15. 15
File I/O
 File system
B u f f e r i n g L a y e rF i l e S o u r c e
D a t a S t r e a m

16. 16
Game Resources
 A game resource (or asset) is anything that
gets loaded that could be shared by several
parts of the game
 A texture, an animation, a sound, etc
 We want to load and share resources easily
 There will be many different types of resources
in a game

17. 17
Game Resources
 Resource manager
 Uses registering object factory pattern
 Can register different types of resources
 All resource creation goes through the
resource manager
 Any requests for existing resources don't
load it again

18. 18
Game Resources
 Resource lifetime
 If resources are shared, how do we know
when we can destroy them?

All at once

At the end of the level
 Explicit lifetime management
 Reference counting

19. 19
Game Resources
 Resources and instances
 Resource is the part of the asset that can
be shared among all parts of the game
 Instance is the unique data that each part
of the game needs to keep

20. 20
Serialization
 Every game needs to save and restore
some game state
 Even for check point saves
 Level editing and creation could be
implemented as a saved game

21. 21
Serialization
 Saving
 ISerializable interface for Read and Write
operations
 Each class implements the Write() function
 Saving pointers is a problem

They won't be the same when we load
 Save raw pointers to other objects

Translate them later

22. 22
Serialization
 Loading
 Create object types through an object
factory
 Read() function takes care of loading the
data from the stream
 Pointers are loaded into a translation table
 Second pass fixes up all the pointers