3.5 memory and io systems

22
Chapter 3.5 Memory and I/O Systems

Upload: sayed-ahmed

Post on 15-Apr-2017

11 views

Category:

Technology


0 download

TRANSCRIPT

Page 1: 3.5 memory and io systems

Chapter 3.5Memory and I/O Systems

Page 2: 3.5 memory and io systems

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

Page 3: 3.5 memory and io systems

3

Memory Management We have three goals when working

with memory Safety Knowledge Control

Page 4: 3.5 memory and io systems

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

Page 5: 3.5 memory and io systems

5

Memory Management Virtual addressing

Vir tu a lAd d res s T ab le

Blo c k 2

Blo c k 4

Blo c k 3

Blo c k 5

Blo c k 1

P h y s ic a l M em o ry

Blo c k 1

Blo c k 4

Vir tu alM em o ry View

Page 6: 3.5 memory and io systems

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

Page 7: 3.5 memory and io systems

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

Page 8: 3.5 memory and io systems

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

Page 9: 3.5 memory and io systems

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

Page 10: 3.5 memory and io systems

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

Page 11: 3.5 memory and io systems

11

Memory Management Memory pools

E m p ty b lo c kE m p ty b lo c k h ead erBlo c k w ith d ata

a b c

Page 12: 3.5 memory and io systems

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

Page 13: 3.5 memory and io systems

13

File I/O Unified file system

Platform independent Provide same interface to different

types of media Based around FileSystem class

Page 14: 3.5 memory and io systems

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

Page 15: 3.5 memory and io systems

15

File I/O File system

B uffe r ingL aye rF ile So urc e

D ataS tre am

Page 16: 3.5 memory and io systems

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

Page 17: 3.5 memory and io systems

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

Page 18: 3.5 memory and io systems

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

Page 19: 3.5 memory and io systems

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

Page 20: 3.5 memory and io systems

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

Page 21: 3.5 memory and io systems

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

Page 22: 3.5 memory and io systems

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