Videogames decoupled discrete event simulation

ARTICLE IN PRESS

0097-8493$ - se

doi101016jca

CorrespondE-mail addr

rmolladsicup

Computers amp Graphics 29 (2005) 195ndash202

wwwelseviercomlocatecag

Videogames decoupled discrete event simulation

Inmaculada Garcıa Ramon Molla

Computer Graphics Section Department of Computation and Computer Systems Technical University of Valencia

Valencia E-46022 Spain

Abstract

Real-time graphic applications and specifically videogames follow a paradigm of continuous simulation that couples

the simulation phase and the rendering phase This paradigm can be inefficient (inadequate computer power

distribution) or it can produce incorrect simulations (disordered events execution or events lost) The use of a decoupled

discrete paradigm avoids incorrect simulations besides it improves the simulation quality and efficiency GDESK is a

discrete decoupled simulation kernel that can be integrated in any videogame or real-time graphic application to change

its simulation paradigm to a discrete decoupled one Once GDESK is integrated inside the videogame it becomes into a

set of objects being communicated by messages Messages are modeled using discrete events GDESK manages the

messages exchange process (events synchronization messages sending and reception process etc)

Keywords Simulation Discrete events Videogames

1 Introduction

Traditional videogames as Doom v11 [1] Quake

v23 [2] or Fly3D [34] follow a continuous coupled

simulation paradigm Videogames kernels (3D GameS-

tudio [5] Crystal Space [6] or Genesis 3D [7]) use the

same simulation scheme Many videogame kernels are

merely rendering kernels or scene graphs with no

simulation support

The continuous coupled applications main loop has

three main stages [8]

Test the user events

Simulate The world objects are evolved a time step

This time step is not predefined and it is equal for all

the videogame objects A simulation step supposes

to travel throughout the scene graph asking to each

g200412004

ing author

esses ingarciadsicupves (I Garcıa)

ves (R Molla)

object if it has some simulation pending Some

videogames use the scene graph pass to select the

objects that must be rendered including them in

some data structure In this way the rendering

requires only to travel that secondary data structure

diminishing the rendering process cost This sam-

pling produces in the system a continuous simula-

tion scheme [9] The simulation cycle or sampling is

the time interval among two consecutive simula-

tions That is why this cycle can be different at each

main loop step

Render the current scene The scene is always

rendered for each simulation step (rendering and

simulation phases are coupled)

11 Continuous simulation disadvantages

The objects sampling implies to access to all the

objects in the scene graph independently that they have

pending events or not The objects priority depends on

ARTICLE IN PRESSI Garcıa R Molla Computers amp Graphics 29 (2005) 195ndash202196

its position in the scene graph Therefore the events are

not executed time ordered They are executed in the

order in which the objects are located in the scene graph

The sampling frequency remains the same for all the

system objects The sampling frequency is not adapted

to the particular needs of each object

12 Disadvantages of coupling simulation and rendering

The scene has to be rendered for every simulation

cycle independently that it is going to be shown on the

screen or not The system sampling frequency is highly

dependent of the computer power and the simulation

and rendering workload Events are synchronized with

the sampling period so the system is not sensitive to

time intervals lower than the system sampling period

2 Improvement

The continuous coupled simulation scheme draw-

backs can be avoided changing the simulation paradigm

to a discrete decoupled one To obtain a discrete

videogame kernel a discrete event simulator is inte-

grated into a videogame kernel The discrete videogame

kernel decouples the simulation phase and rendering

phase It also decouples every object behavior from the

others

21 Discrete events simulation

Discrete events simulators appear in the 1950s as a

way to analyze problems based on the queues theory

[10] A discrete events simulator allows to model

discrete continuous and hybrid behaviors [9] These

simulators are implemented in three different ways

programming languages (GPSS [11] or SIMSCRIPT II5

[12]) general purpose programming languages libraries

(DESK [13] or QNAP [14]) or toolkits (Sand [15] or

AutoMod [16])

22 Simulation phase and rendering phase decoupling

Decoupled simulation separates the simulation and

rendering phases The decoupling goal is to avoid

unnecessary renderings and to adapt the program frame

rate to the screen refresh rate The released computer

power [17] can be used to improve other application

parts such as AI simulation objects sampling fre-

quency or to execute the application at slower compu-

ters The decoupling of the simulation and rendering

phases increase the simulation accuracy and speed-up

[18] but also it allows the independence from other

system processes [19] Real-time virtual reality applica-

tions use this technique The main decoupling utility

is to distribute the system in a network or to use

parallelism Some decoupled virtual reality appli-

cations are MR toolkit [20] Alice amp Diver [21] or

Bridge [18]

23 Tools selection Fly3D and GDESK

Fly3D is the selected graphic kernel where the discrete

event simulator is integrated Fly3D has been selected

because of the following reasons open source and

freeware OO implemented in C++ well structured

documented enough [34] and the simulation functions

(kernel and applications) are completely separated from

other processes

DESK is the selected discrete events simulator (open

source and freeware OO implemented in C++ well

structured and powerful and flexible enough) Never-

theless DESK is not completely suitable for the

integration into a graphic application at its native form

Some internal mechanisms such as the time management

must be adapted The version of DESK adapted to a

graphic kernel is GDESK [22]

24 Objective

The objective is to show the results of the GDESK

integration into the Fly3D videogame kernel in order to

study the availability of changing its paradigm from a

continuous coupled simulation scheme to a discrete

decoupled one

3 Fly3D A real-time graphic applications kernel

Fly3D SDK is a videogame engine and a real-time 3D

applications development environment It includes a

powerful simulation 3D OO engine that takes charge of

tasks like rendering in real time input events capture or

objects physical simulation Fly3D is plugins oriented

The plugins are completely separated from the Fly3D

kernel All the applications have a common front-end

that supports the user interface and the application main

A Fly3D application is a set of objects that inherit

from the Fly3D basic object Each object redefines a set

of virtual functions that are executed in some given

moments during the videogame execution Among these

functions are the simulation and the rendering functions

The programmer defines the object behavior and

physical appearance using these functions The simula-

tion process traverses through all the videogame objects

executing the simulation function for every object The

object simulation function considers the time consumed

since the last simulation The rendering follows a similar

process

ARTICLE IN PRESSI Garcıa R Molla Computers amp Graphics 29 (2005) 195ndash202 197

4 The game discrete events simulation kernel (GDESK)

GDESK is a discrete events simulator adapted to real-

time graphic applications [22] GDESK is a library that is

invoked by the videogame kernel Once the simulator is

integrated into Fly3D it manages all the videogame

events GDESK controls the communication of all the

application objects by means of messages passing The

simulation and rendering processes in Fly3D are merged

producing a single GDESK simulation process The

dispatcher is the GDESK basic structure Its functions are

Support the messages passing process

Maintain the messages time ordered until the message

time stamp is reached

Send the messages to the target objects at the time

specified by the sender objects

Videogame objects inherit from the GDESK basic

object The functions for receiving and sending messages

are defined in this basic object The message data

structure contains two kinds of information

GDESK internal information It contains the neces-

sary parameters to control the messages sending and

receiving process object origin object destiny and

message reception time

Videogame information This part of the message

structure is accessible to the programmer in order to

define the videogame parameters So the programmer

has freedom to define the messages structure without

unnecessary data structures overloads These parameters

are managed directly by the programmer GDESK does

not take account of these parameters structure

5 DFly3D discrete Fly3D

DFly3D is a real-time discrete decoupled graphic

applications kernel It arises from the integration of the

Fig 1 DFly3D

GDESK simulation kernel and the Fly3D graphic

kernel An application created using DFLy3D is a set

of objects being communicated by means of message

passing Integrating GDESK into Fly3D does not

suppose to change videogame processes like the render-

ing process or the collisions detection method or even

data structures like the scene graph DFly3D changes

the videogame simulation methodology and the given

moment each rendering is performed

51 DFly3D main loop

The DFly3D main loop (Fig 1) replaces the simula-

tion and rendering processes with the GDESK simula-

tion process The whole system is split into objects with

independent simulation processes A specific object

controls the rendering process System processes

specially the rendering process are integrated into the

GDESK simulation process These processes are called

each time the GDESK simulation process executes their

associated events (messages)

The GDESK simulation process returns the control to

the main loop when there are not pending messages to

process and only by the time period that it is going to be

inactive (difference between the next scheduled event

time and the current time) The main loop can manage

this remaining time as it considers

52 DFly3D objects

Fly3D separates the kernel from the applications

created using it So there are two DFly3D object kinds

System objects They are the objects that perform the

Fly3D kernel tasks They are created to isolate the

code belonging to certain tasks so that they can be

GDESK objects They can be connected by means of

message passing like any other object in the system

They are not accessible by the programmer Each

object controls a specific DFly3D kernel task

DFly3D maintains the same Fly3D functionality A

specific system object is in charge to control the

rendering process

Videogame objects They are the objects created by

the programmer during the videogame implementa-

tion For example characters walls or projectiles

They are the same objects created in Fly3D (inherit

of the Fly3D basic object) but its behavior is

modeled by means of messages passing (object

simulation function) These objects join the Fly3D

basic objects characteristics with the GDESK basic

objects characteristics

Both objects kinds model their behavior using

messages GDESK manages all messages in the same

way independently of the type of object which it comes

521 DFly3D videogame objects simulation

Fly3D simulates the system by means of objects

sampling Objects are reached following the scene graph

for each main loop step Fly3D objects inherit from a

basic object that defines among others a virtual

function for the object simulation All the objects are

simulated calling their simulation function at each main

loop step

DFLy3D simulates the system by means of messages

passing Each particular object defines its simulation

process in the message reception function The object

only acts as a message arrival consequence Therefore

the object behaviors are the answers to the different

kinds of messages

The programmer defines each object and system

behavior using the mechanism of messages passing

The messages main goals are

Object trajectory

Messages

Model the object behavior An object behavior can be

continuous discrete or hybrid The continuous object

behavior is modeled by means of messages sent to it

at constant or variable time intervals When an object

A wants to change its behavior T time units from now

(for example to modify its position or state)

generates a message directed to itself The message

time will be T Later as the message arrival

consequence the object A modifies its state (its

present state can depend on the message parameters)

Discrete behaviors are modeled in the same way but

the message arrival does not generate other messages

Discrete behaviors are modeled by isolated messages

The messages number generated depends on how the

programmer models the object behavior

Fig 2 Example of messages generation rate according to the

object behavior

Communicate objects Let suppose the object A needs

to communicate with the object B So A generates a

message directed to B As the message arrival

consequence the object B can change its state or to

act of a given way or to generate messages to other

objects

The object defines the message time when it sends the

message to another object If the message time is 0 the

message is received immediately by the target object If

the message time T is greater that 0 the target object

receives the message T time units later

A continuous behavior may be modeled by messages

sent with a constant frequency (all the messages are sent

with the same time value) But the messages frequency

can be adapted dynamically to the object behavior

Fig 2 shows an object with different sampling needs at

each trajectory interval (A B or C) So the sampling

frequency is dynamically adapted to the object behavior

Every sample is shot by a message that the object sends

to itself Each particular message time has to be

dynamically adapted depending on the trajectory inter-

val where the object is

The object behavior is modeled using its message

reception function This function has to discriminate the

object behavior depending on the received message kind

the message parameters or the target object This

function defines the messages the object is sensitive to

and its answer for each message kind

53 The render object

DFLy3D allows the simulation process and the

rendering process independence (system decoupling)

The render object starts the rendering process when it

receives a message When the system is initialized the

launcher object sends a lsquolsquostartrsquorsquo message to all system

objects and videogame objects Then the render object

renders the current scene Once the render object

behavior has begun it has an autonomous behavior

When the render object receives a message it

Renders the current scene n

Calculates the time Tnthorn1 for the next rendering event

(scene n thorn 1)

Generates a message directed to itself that has to be

received after Tnthorn1 time units

Therefore the frame frequency depends on the number

of messages generated by the render object This

rendering rate can be set depending on the videogame

needs and the rendering device performance It may be

constant during the videogame execution or it may be

dynamically adaptable to the system needs The rendering

process is defined and controlled by the programmer

The render object goals are

To generate so many renderings as screen refreshes

and to avoid calculate frames that will be never

shown on the screen If the amount of renderings is

greater the computer power is wasted

To determine the very moment when a rendering is

shot in order to generate a scene just before the next

screen refresh This means that the last scene

calculated has to be shown for every screen refresh

6 Results

Let it be

TG total time consumed during the videogame

execution

TR total time used rendering the scenes

TS total time used simulating the videogame

TF total time assigned to the videogame but not

used by the simulation and rendering processes

(free)

FF frame frequency

OSFi object i sampling frequency

SSF system sampling frequency

O set of application objects (system objects and

videogame objects)

61 Rendering and simulation times

Fly3D and DFly3D accomplish Eq (1)

TG frac14 TR thorn TS thorn TF (1)

0102030405060708090

1 10 20 30 40 50 60 70 80 90 100

Objects Number

Rendering

SimulationFree

Fig 3 Fly3D and DFly3D

In the tests carried out to obtain the results the

system workload depends on the number of system

objects Both the simulation and rendering load are

increased with the amount of objects in the system

Fly3D follows a continuous coupled simulation

scheme The system is continuously simulating and

rendering at the maximum speed (Fig 3) There is no

free time TF frac14 0 An increment in the simulation load

supposes a decrement in the rendering time due to Eq

(1) (Eq (2)) If FF is low the videogame is not rendered

adequately An increment in the rendering load means a

decrement in the simulation time due to Eq (1) (Eq (3))

If the sampling of each object is not enough to

accomplish the NyquistndashShannon theorem some objects

can be sampled insufficiently This can produce loss of

events not detected collisions or incorrect behaviors

TS ) TR ) FF (2)

TR ) TS ) FF (3)

DFly3D assures the simulation and rendering pro-

cesses independence while introducing a discrete simula-

tion scheme DFly3D defines a OSFi for each object i

(including the render object OSFrender frac14 FF ) Each

object i simulation process consume the necessary time

to accomplish its OSFi While the system is not

collapsed the simulation time depends only on the

simulation load and rendering load (scene geometrical

complexity) The application main loop is not continu-

ously simulating and rendering so it releases time for

other tasks TG is not shared by the simulation and

rendering phases (Fig 3) This is why there is released

time TF40 (if the computer power and the videogame

complexity allow it) The rendering and simulations

rates are constant during the videogame execution and

TG and TS are increased lineally with the number of

objects while the system is not collapsed DFLy3D

releases time that can be used to improve other

videogame aspects or it may be sent to other system

applications There is only free time if the system is not

collapsed

0102030405060708090

1 10 20 30 40 50 60 70 80 90 100

Objects Number

Rendering

SimulationFree

DFly3D

times distribution

While the system is not collapsed the simulation and

rendering times are independent Increasing the simula-

tion or rendering time supposes to decrement the free

time (Eqs (4) and (5)) If the system is collapsed the

free time is 0 So the system is unable to guarantee

the videogame quality that is to simulate or to

render sound video or haptics at the appropriate

frequency

TS ) TF ) FF rsquo (4)

TR ) TF ) FF rsquo (5)

62 Free time

DFly3D avoids unnecessary renderings releasing the

computer power for other applications or to improve

other videogame parts such as AI collisions detection

precision or videogame realism

Fig 4 shows the difference among the time released by

DFly3D and Fly3D The discrete system always releases

more time than the continuous one The difference is

always positive until the system is collapsed If the

system is collapsed the difference is close to zero

DFLy3D free time is almost the 97 of the application

time when there is only an object in the scene (Fig 3)

This is due to the following reasons

The rendering and simulation processes are indepen-

dent in DFly3D (decoupled)

The FF is defined by the programmer in DFly3D It

can be constant during the execution or it can change

to be adjusted to the desired system behavior

Each object simulation rate is fixed by the program-

mer It can be constant during the videogame

execution or variable to be adapted to the object

The system uses the 100 of the CPU time only if the

system is collapsed (the system load is greater than

the available computer power)

0102030405060708090

10 20 30 40 50 60 70 80 90

Objects Number

4 Difference between the free time at the discrete and the

ntinuous systems

63 Frame frequency

Fly3D FF depends on the simulation and rendering

phases complexity and it is equal to the global system

sampling frequency The system simulates and renders

up to the maximum speed

DFly3D allows to define the optimum FF the

videogame should generate The defined FF is main-

tained while the system is not collapsed The tests

performed set the FF to 25 fps The Fly3D rendering

time decreases when the amount of objects increases

because the simulation time is enlarged The continuous

system FF is highly dependent on the computer power

and the programmer has very little control on this value

(the FF cannot be set explicitly depending on the

videogame needs) The rendering time in DFly3D is

always smaller than the Fly3D rendering time because

Fly3D generates unnecessary renderings if the computer

power is high or the simulation and the rendering

complexity is low

Fig 5 shows the FF generated by both systems

maintaining the same image quality DFly3D fixes the

FF and it keeps the FF constant while the system is not

collapsed The continuous system renders unnecessarily

wasting computer power

64 Sampling frequency

Fly3D has a global system sampling frequency SSF It

is equal for all objects in the system and it is equal to the

FF (Eq (6)) If a particular object needs to be sampled

with a higher frequency the object is undersampled

(erroneous behavior) If other object needs to be

sampled with a lower frequency it is oversampled

(wasting computer power)

SSF frac14 FF frac14 OSFi 8i 2 O (6)

DFly3D fixes a different sampling frequency for

each object in the system (Eq (7)) The global SSF

does not exist The render process is controlled by

the render object The render object sampling frequency

1 10 20 30 40 50 60 70 80 90 100

Objects Number

Fig 5 Difference between the FPS generated by the discrete

and the continuous systems FPS rendered unnecessarily by the

continuous system

is the FF

OSFRENDER frac14 FF OSFi frac14 OSFj 8i j 2 O (7)

DFly3D allows the programmer to define a particular

object sampling frequency dynamically changing to be

adapted to the object behavior needs in order to avoid

erroneous behaviors and save computer power (Fig 6)

The object sampling frequency is kept at its optimum

value while the system is not collapsed On the other

hand the Fly3D sampling frequency is always the same

for all the objects in the system (if there are not system

workload changes during the execution) Fig 6 shows

the amount of unnecessary samplings that carries out

the continuous system

Table 1 shows a comparative summary of both

systems

7 Conclusions

The traditional videogames use a continuous coupled

simulation scheme They can be improved using a

decoupled discrete events simulator that manages the

application events The continuous coupled simulation

paradigm is replaced by a discrete decoupled one

Samples Number in both Systems

0102030405060708090

0 1 2 3 4 5 6 7 8 9 10Time

ber DFly3D

Fig 6 Objects sampling at the discre

Table 1

Fly3D and DFly3D Comparative

Characteristic Fly3D

Simulation Continuous

Coupled

Videogame Time TG rsquo TR thorn TS

Free Time TF rsquo 0

TS TR FF

TR TS FF

Collapsed system TG frac14 TR thorn TS

System load increase Distribution of the increase among T

FF System load dependent

Variable

Objects Sampling Rate Equal for all system objects

Variable according to the system loa

Discrete decoupled simulations are more precise (pre-

venting erroneous situations) and it saves videogame

computer power (avoiding unnecessary samplings and

renderings)

In the new simulation paradigm the videogame

rendering process has its own sampling frequency The

system is fully decoupled because each object defines its

behavior independently of the rest of objects Every

object sampling frequency is set by the videogame

programmer and it can be adapted dynamically to the

videogame needs and the needs of the object

The new paradigm makes independent the video-

game behavior from the computer power (while the

system is not collapsed) So the same videogame can

be executed in machines with different computer

power with the same simulation quality or to improve

the quality of simulation depending on the computer

Acknowledgements

This work has been funded by the Spanish Ministry

of Science and Technology (MCYT TIC2002-04166-

C03-01)

Difference

0 1 2 3 4 5 6 7 8 9 10Time

te and the continuous systems

DFLy3D

Discrete

Decoupled

TG frac14 TR thorn TS thorn TF

TF frac14 TG TS TR

TF FF rsquo

TG frac14 TR thorn TS

S and TR Proportional increase of TS y TR

Defined by the programmer

Constant or adaptable

Defined by the programmer for each object

d Constant or adaptable

References

[1] Idsoftware Page wwwidsoftwarecomarchivesdoomarc

[2] Quake Developers Page wwwgamersorgdEnginequake

[3] Watt A Policarpo F 3D computer games technology

real-time rendering and software Reading MA Addison-

Wesley 2001

[4] Watt A Policarpo F 3D computer games Reading MA

Addison-Wesley 2003

[5] Conitec Datasystems httpwwwconitecnet

[6] Crystal Space httpcrystalsourceforgenetdrupal

[7] Genesis3D httpwwwgenesis3dcom

[8] Pausch R Burnette T Capehart AC Conway M

Cosgrove D DeLine R Durbin J Gossweiler R Koga

S White J A brief architectural overview of alice a rapid

prototyping system for virtual environments IEEE Com-

puter Graphics and Applications 1995

[9] Banks J Carson II JS Nelson BB Nicol DM Discrete-

event system simulation Prentice-Hall International Series

in Industrial and Systems Engineering 2001

[10] Fishman GS Principles of discrete event simulation New

York Wiley 1978

[11] Stahl I GPSSmdash40 Years of Development Winter simula-

tion conference 2001

[12] CACI Products Company httpwwwcaciaslcom

[13] Garcıa I Molla R Ramos E Fernandez M DESK

Discrete events simulation kernel ECCOMAS 2000

[14] QNAP Queuing network analysis package First interna-

tional conference on the numerical solutions of Markov

chains 1990

[15] Sadowski D Bapat V The arena product family

enterprise modeling solutions Winter simulation confer-

ence 1999

[16] Rohrer M AutoMod Product Suite Tutorial (AutoMod

Simulator AutoStat) by AutoSimulations Winter simula-

[17] Reynolds C Interaction with groups of autonomous

characters Game developers conference proceedings 2000

[18] Darken R Tonnesen C Passarella K The bridge between

developers and virtual environments a robust virtual

environment system architecture Proceedings of SPIE

[19] Agus M Giachetti A Gobbetti E Zanetti G A multi-

processor decoupled system for the simulation of temporal

bone surgery Computing and Visualization in Science

[20] Shaw C Liang J Green M Sun Y The decoupled

simulation model for virtual reality systems CHI proceed-

ings 1992

[21] Randy P Conway M DeLine R Gossweiler R Maile S

Ashton J Stoakley R Alice amp DIVER a software

architecture for the rapid prototyping of virtual environ-

ments Course notes for SIGGRAPHrsquo94 course Program-

ming Virtual Worlds 1994

[22] Garcıa I Molla R Barella T GDESK Game discrete

event simulation kernel Journal of WSCG 200412(1)

121ndash8

Further reading

[23] Schwetman H CSIM A C-based process oriented simula-

tion language Winter simulation conference 1986

Inmaculada Garcıa received PhD in computer science from the

University of Valencia (Spain) in 2004 She is an Associate

professor in the Technical University of Valencia Her current

research interest include simulation and real-time graphics

applications

Ramon Molla is an Associate professor in the Technical

University of Valencia He obtained PhD in 2001 He works

in the computer graphics area since 1992 when he finished his

studies in computer science He works currently in real-time

graphics applications specially in videogames simulation

kernels and in low-level raster conversion primitives

Introduction

Continuous simulation disadvantages

Disadvantages of coupling simulation and rendering

Improvement

Discrete events simulation

Simulation phase and rendering phase decoupling

Tools selection Fly3D and GDESK

Objective

Fly3D A real-time graphic applications kernel

The game discrete events simulation kernel (GDESK)

DFly3D discrete Fly3D

DFly3D main loop

DFly3D objects

DFly3D videogame objects simulation

The render object

Results

Rendering and simulation times

Free time

Frame frequency

Sampling frequency

Conclusions

Acknowledgements

References

bm_fur

its position in the scene graph Therefore the events are

not executed time ordered They are executed in the

order in which the objects are located in the scene graph

The sampling frequency remains the same for all the

system objects The sampling frequency is not adapted

to the particular needs of each object

12 Disadvantages of coupling simulation and rendering

The scene has to be rendered for every simulation

cycle independently that it is going to be shown on the

screen or not The system sampling frequency is highly

dependent of the computer power and the simulation

and rendering workload Events are synchronized with

the sampling period so the system is not sensitive to

time intervals lower than the system sampling period

2 Improvement

The continuous coupled simulation scheme draw-

backs can be avoided changing the simulation paradigm

to a discrete decoupled one To obtain a discrete

videogame kernel a discrete event simulator is inte-

grated into a videogame kernel The discrete videogame

kernel decouples the simulation phase and rendering

phase It also decouples every object behavior from the

others

21 Discrete events simulation

Discrete events simulators appear in the 1950s as a

way to analyze problems based on the queues theory

[10] A discrete events simulator allows to model

discrete continuous and hybrid behaviors [9] These

simulators are implemented in three different ways

programming languages (GPSS [11] or SIMSCRIPT II5

[12]) general purpose programming languages libraries

(DESK [13] or QNAP [14]) or toolkits (Sand [15] or

AutoMod [16])

22 Simulation phase and rendering phase decoupling

Decoupled simulation separates the simulation and

rendering phases The decoupling goal is to avoid

unnecessary renderings and to adapt the program frame

rate to the screen refresh rate The released computer

power [17] can be used to improve other application

parts such as AI simulation objects sampling fre-

quency or to execute the application at slower compu-

ters The decoupling of the simulation and rendering

phases increase the simulation accuracy and speed-up

[18] but also it allows the independence from other

system processes [19] Real-time virtual reality applica-

tions use this technique The main decoupling utility

is to distribute the system in a network or to use

parallelism Some decoupled virtual reality appli-

cations are MR toolkit [20] Alice amp Diver [21] or

Bridge [18]

23 Tools selection Fly3D and GDESK

Fly3D is the selected graphic kernel where the discrete

event simulator is integrated Fly3D has been selected

because of the following reasons open source and

freeware OO implemented in C++ well structured

documented enough [34] and the simulation functions

(kernel and applications) are completely separated from

other processes

DESK is the selected discrete events simulator (open

source and freeware OO implemented in C++ well

structured and powerful and flexible enough) Never-

theless DESK is not completely suitable for the

integration into a graphic application at its native form

Some internal mechanisms such as the time management

must be adapted The version of DESK adapted to a

graphic kernel is GDESK [22]

24 Objective

The objective is to show the results of the GDESK

integration into the Fly3D videogame kernel in order to

study the availability of changing its paradigm from a

continuous coupled simulation scheme to a discrete

decoupled one

3 Fly3D A real-time graphic applications kernel

Fly3D SDK is a videogame engine and a real-time 3D

applications development environment It includes a

powerful simulation 3D OO engine that takes charge of

tasks like rendering in real time input events capture or

objects physical simulation Fly3D is plugins oriented

The plugins are completely separated from the Fly3D

kernel All the applications have a common front-end

that supports the user interface and the application main

A Fly3D application is a set of objects that inherit

from the Fly3D basic object Each object redefines a set

of virtual functions that are executed in some given

moments during the videogame execution Among these

functions are the simulation and the rendering functions

The programmer defines the object behavior and

physical appearance using these functions The simula-

tion process traverses through all the videogame objects

executing the simulation function for every object The

object simulation function considers the time consumed

since the last simulation The rendering follows a similar

process

Fig 1 DFly3D

51 DFly3D main loop

52 DFly3D objects

rendering process

loop step

kinds of messages

Object trajectory

Messages

object behavior

objects

(scene n thorn 1)

6 Results

Let it be

execution

(free)

FF frame frequency

videogame objects)

0102030405060708090

1 10 20 30 40 50 60 70 80 90 100

Objects Number

Rendering

SimulationFree

TS ) TR ) FF (2)

TR ) TS ) FF (3)

collapsed

0102030405060708090

1 10 20 30 40 50 60 70 80 90 100

Objects Number

Rendering

SimulationFree

DFly3D

times distribution

frequency

62 Free time

0102030405060708090

10 20 30 40 50 60 70 80 90

Objects Number

ntinuous systems

63 Frame frequency

complexity is low

1 10 20 30 40 50 60 70 80 90 100

Objects Number

continuous system

is the FF

systems

7 Conclusions

0102030405060708090

0 1 2 3 4 5 6 7 8 9 10Time

ber DFly3D

Table 1

Coupled

TS TR FF

TR TS FF

Variable

renderings)

Acknowledgements

C03-01)

Difference

0 1 2 3 4 5 6 7 8 9 10Time

DFLy3D

Discrete

Decoupled

TF frac14 TG TS TR

TF FF rsquo

References

Wesley 2001

Addison-Wesley 2003

York Wiley 1978

chains 1990

ence 1999

ings 1992

121ndash8

Further reading

applications

Introduction



Improvement




Objective




DFly3D main loop

DFly3D objects


The render object

Results


Free time

Frame frequency

Sampling frequency

Conclusions

Acknowledgements

References

bm_fur

Fig 1 DFly3D

51 DFly3D main loop

52 DFly3D objects

rendering process

loop step

kinds of messages

Object trajectory

Messages

object behavior

objects

(scene n thorn 1)

6 Results

Let it be

execution

(free)

FF frame frequency

videogame objects)

0102030405060708090

1 10 20 30 40 50 60 70 80 90 100

Objects Number

Rendering

SimulationFree

TS ) TR ) FF (2)

TR ) TS ) FF (3)

collapsed

0102030405060708090

1 10 20 30 40 50 60 70 80 90 100

Objects Number

Rendering

SimulationFree

DFly3D

times distribution

frequency

62 Free time

0102030405060708090

10 20 30 40 50 60 70 80 90

Objects Number

ntinuous systems

63 Frame frequency

complexity is low

1 10 20 30 40 50 60 70 80 90 100

Objects Number

continuous system

is the FF

systems

7 Conclusions

0102030405060708090

0 1 2 3 4 5 6 7 8 9 10Time

ber DFly3D

Table 1

Coupled

TS TR FF

TR TS FF

Variable

renderings)

Acknowledgements

C03-01)

Difference

0 1 2 3 4 5 6 7 8 9 10Time

DFLy3D

Discrete

Decoupled

TF frac14 TG TS TR

TF FF rsquo

References

Wesley 2001

Addison-Wesley 2003

York Wiley 1978

chains 1990

ence 1999

ings 1992

121ndash8

Further reading

applications

Introduction



Improvement




Objective




DFly3D main loop

DFly3D objects


The render object

Results


Free time

Frame frequency

Sampling frequency

Conclusions

Acknowledgements

References

bm_fur

rendering process

loop step

kinds of messages

Object trajectory

Messages

object behavior

objects

(scene n thorn 1)

6 Results

Let it be

execution

(free)

FF frame frequency

videogame objects)

0102030405060708090

1 10 20 30 40 50 60 70 80 90 100

Objects Number

Rendering

SimulationFree

TS ) TR ) FF (2)

TR ) TS ) FF (3)

collapsed

0102030405060708090

1 10 20 30 40 50 60 70 80 90 100

Objects Number

Rendering

SimulationFree

DFly3D

times distribution

frequency

62 Free time

0102030405060708090

10 20 30 40 50 60 70 80 90

Objects Number

ntinuous systems

63 Frame frequency

complexity is low

1 10 20 30 40 50 60 70 80 90 100

Objects Number

continuous system

is the FF

systems

7 Conclusions

0102030405060708090

0 1 2 3 4 5 6 7 8 9 10Time

ber DFly3D

Table 1

Coupled

TS TR FF

TR TS FF

Variable

renderings)

Acknowledgements

C03-01)

Difference

0 1 2 3 4 5 6 7 8 9 10Time

DFLy3D

Discrete

Decoupled

TF frac14 TG TS TR

TF FF rsquo

References

Wesley 2001

Addison-Wesley 2003

York Wiley 1978

chains 1990

ence 1999

ings 1992

121ndash8

Further reading

applications

Introduction



Improvement




Objective




DFly3D main loop

DFly3D objects


The render object

Results


Free time

Frame frequency

Sampling frequency

Conclusions

Acknowledgements

References

bm_fur

6 Results

Let it be

execution

(free)

FF frame frequency

videogame objects)

0102030405060708090

1 10 20 30 40 50 60 70 80 90 100

Objects Number

Rendering

SimulationFree

TS ) TR ) FF (2)

TR ) TS ) FF (3)

collapsed

0102030405060708090

1 10 20 30 40 50 60 70 80 90 100

Objects Number

Rendering

SimulationFree

DFly3D

times distribution

frequency

62 Free time

0102030405060708090

10 20 30 40 50 60 70 80 90

Objects Number

ntinuous systems

63 Frame frequency

complexity is low

1 10 20 30 40 50 60 70 80 90 100

Objects Number

continuous system

is the FF

systems

7 Conclusions

0102030405060708090

0 1 2 3 4 5 6 7 8 9 10Time

ber DFly3D

Table 1

Coupled

TS TR FF

TR TS FF

Variable

renderings)

Acknowledgements

C03-01)

Difference

0 1 2 3 4 5 6 7 8 9 10Time

DFLy3D

Discrete

Decoupled

TF frac14 TG TS TR

TF FF rsquo

References

Wesley 2001

Addison-Wesley 2003

York Wiley 1978

chains 1990

ence 1999

ings 1992

121ndash8

Further reading

applications

Introduction



Improvement




Objective




DFly3D main loop

DFly3D objects


The render object

Results


Free time

Frame frequency

Sampling frequency

Conclusions

Acknowledgements

References

bm_fur

frequency

62 Free time

0102030405060708090

10 20 30 40 50 60 70 80 90

Objects Number

ntinuous systems

63 Frame frequency

complexity is low

1 10 20 30 40 50 60 70 80 90 100

Objects Number

continuous system

is the FF

systems

7 Conclusions

0102030405060708090

0 1 2 3 4 5 6 7 8 9 10Time

ber DFly3D

Table 1

Coupled

TS TR FF

TR TS FF

Variable

renderings)

Acknowledgements

C03-01)

Difference

0 1 2 3 4 5 6 7 8 9 10Time

DFLy3D

Discrete

Decoupled

TF frac14 TG TS TR

TF FF rsquo

References

Wesley 2001

Addison-Wesley 2003

York Wiley 1978

chains 1990

ence 1999

ings 1992

121ndash8

Further reading

applications

Introduction



Improvement




Objective




DFly3D main loop

DFly3D objects


The render object

Results


Free time

Frame frequency

Sampling frequency

Conclusions

Acknowledgements

References

bm_fur

is the FF

systems

7 Conclusions

0102030405060708090

0 1 2 3 4 5 6 7 8 9 10Time

ber DFly3D

Table 1

Coupled

TS TR FF

TR TS FF

Variable

renderings)

Acknowledgements

C03-01)

Difference

0 1 2 3 4 5 6 7 8 9 10Time

DFLy3D

Discrete

Decoupled

TF frac14 TG TS TR

TF FF rsquo

References

Wesley 2001

Addison-Wesley 2003

York Wiley 1978

chains 1990

ence 1999

ings 1992

121ndash8

Further reading

applications

Introduction



Improvement




Objective




DFly3D main loop

DFly3D objects


The render object

Results


Free time

Frame frequency

Sampling frequency

Conclusions

Acknowledgements

References

bm_fur

References

Wesley 2001

Addison-Wesley 2003

York Wiley 1978

chains 1990

ence 1999

ings 1992

121ndash8

Further reading

applications

Introduction



Improvement




Objective




DFly3D main loop

DFly3D objects


The render object

Results


Free time

Frame frequency

Sampling frequency

Conclusions

Acknowledgements

References

bm_fur

Documents

Videogames decoupled discrete event simulation