Está en la página 1de 16

Videogames Decoupled Discrete Event

Simulation

Inmaculada Garcı́a, Ramón Mollá


Computer Graphics Section, Dep. of Computation and Computer Systems,
Technical University of 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,...).

Key words: Simulation, discrete events, videogames

1 Introduction

Traditional videogames, as Doom v1.1 [11], Quake v2.3 [14] or Fly3D [22,23]
follow a continuous coupled simulation paradigm. Videogames kernels (3D
GameStudio [4], Crystal Space [5] or Genesis 3D [10]), 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 [12]:

Email address: ingarcia,rmolla@dsic.upv.es (Inmaculada Garcı́a, Ramón


Mollá).

Preprint submitted to Elsevier Science 27 September 2004


(1) Test the user events.
(2) 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 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
sampling produces in the system a continuous simulation scheme [2]. The
simulation cycle or sampling is the time interval among two consecutive
simulations. That is why this cycle can be different at each main loop
step.
(3) Render the current scene. The scene is always rendered for each sim-
ulation step (rendering and simulation phases are coupled).

1.1 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 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.

1.2 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 drawbacks can be avoided changing


the simulation paradigm to a discrete decoupled one. To obtain a discrete
videogame kernel, a discrete event simulator is integrated into a videogame

2
kernel. The discrete videogame kernel decouples the simulation phase and
rendering phase. It also decouples every object behavior from the others.

2.1 Discrete Events Simulation

Discrete events simulators appear in the 50’s, as a way to analyze problems


based on the queues theory [7]. A discrete events simulator allows to model dis-
crete, continuous and hybrid behaviors [2]. These simulators are implemented
in three different ways: programming languages (GPSS [21] or SIMSCRIPT
II.5 [3]), general purpose programming languages libraries (DESK [8] or QNAP
[13]) or toolkits (Sand [18] or AutoMod [17]).

2.2 Simulation Phase and Rendering Phase Decoupling

Decoupled simulation separates the simulation and rendering phases. The de-
coupling goal is to avoid unnecessary renderings and to adapt the program
frame rate to the screen refresh rate. The released computer power [16] can
be used to improve other application parts, such as AI, simulation, objects
sampling frequency or to execute the application at slower computers. The
decoupling of the simulation and rendering phases increase the simulation
accuracy and speed-up [6], but also, it allows the independence from other
system processes [1]. Real time virtual reality applications use this technique.
The main decoupling utility is to distribute the system in a network or to use
parallelism. Some decoupled virtual reality applications are: MR toolkit [19],
Alice & Diver [15] or Bridge [6].

2.3 Tools Selection: Fly3D and GDESK

Fly3D is the selected graphic kernel where the discrete event simulator is inte-
grated. Fly3D has been selected because of the following reasons: open source
and freeware, OO, implemented in C++, well structured, documented enough
[22,23] 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). Nev-
ertheless, 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 [9].

3
2.4 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 loop.

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 simulation
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.

4 The Game Discrete Events Simulation Kernel GDESK

GDESK is a discrete events simulator adapted to real time graphic applica-


tions [9]. 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.

4
  
       

  
       
   
 

 !  "   !  


   

    #$    
",   (
    )  
 *    #$    + 

-
 #$    

%& '    
% 
+"  ,  
  
%
+"  ,  

Fig. 1. DFly3D main loop.


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 necessary parameters to con-


trol 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 pro-
grammer 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 GDESK simulation kernel and the Fly3D graphic
kernel. An application created using DFLy3D is a set of objects being commu-
nicated by means of message passing. Integrating GDESK into Fly3D does not
suppose to change videogame processes like the rendering process or the colli-
sions detection method, or even data structures like the scene graph. DFly3D
changes the videogame simulation methodology and the given moment each
rendering is performed.

5.1 DFly3D Main Loop

The DFly3D main loop (figure 1) replaces the simulation and rendering pro-
cesses with the GDESK simulation process. The whole system is split into

5
objects with independent simulation processes. A specific object controls the
rendering process. System processes, specially the rendering process, are in-
tegrated into the GDESK simulation process. These processes are called each
time the GDESK simulation process executes their associated events (mes-
sages).

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.

5.2 DFly3D Objects

Fly3D separates the kernel from the applications created using it. So, there
are two DFly3D object kinds:

(1) 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.
(2) Videogame objects. They are the objects created by the programmer
during the videogame implementation. 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
from.

5.2.1 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.

6
A B C

Object trajectory

Messages

Fig. 2. Example of messages generation rate according to the object behavior.

DFLy3D simulates the system by means of messages passing. Each partic-


ular 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:

• Model the object behavior. An object behavior can be continuous, dis-


crete 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 parame-
ters). 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.
• 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 fre-


quency (all the messages are sent with the same time value). But the messages
frequency can be adapted dynamically to the object behavior. The figure 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.

7
Each particular message time has to be dynamically adapted depending on
the trajectory interval 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.

5.3 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
”start” 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 Tn+1 for the next rendering event (scene n + 1).
• Generates a message directed to itself that has to be received after Tn+1
time units.

Therefore, the frame frequency depends on the number of messages gener-


ated 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 program-
mer.

The render object goals are:

(1) 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.
(2) 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.

8
100

90
  100

90
 
80 80

70 70
% Videogame Time

% V ideogam e Tim e
60 60

50 50

40 40

30 30

20 20

10 10

0 0

10

20
30

40

50

60

70

80

90

100

110

120

130

140

150

160

170

180

190

200
1

10

20

30

40

50

60

70

80

90

100

110

120

130

140

150

160

170

180

190

200
Objects Number Objects Number

Rendering Simulation Free Rendering Simulation Free

Fig. 3. Fly3D and DFly3D times distribution.


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).
F F frame frequency.
OSFi object i sampling frequency.
SSF system sampling frequency.
O set of application objects (system objects and videogame objects).

6.1 Rendering and Simulation Times

Fly3D and DFly3D accomplish the equation 1:

TG = TR + TS + TF (1)

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 contin-


uously simulating and rendering at the maximum speed (figure 3). There is
no free time TF = 0. An increment in the simulation load supposes a decre-
ment in the rendering time due to the equation 1 (equation 2). If F F is low,
the videogame is not rendered adequately. An increment in the rendering load
means a decrement in the simulation time due to the equation 1 (equation 3). If

9
the sampling of each object is not enough to accomplish the Nyquist-Shannon
theorem, some objects can be sampled insufficiently. This can produce loss of
events, not detected collisions or incorrect behaviors.

TS ↑⇒ TR ↓⇒ F F ↓ (2)

TR ↑⇒ TS ↓⇒ F F ↓ (3)

DFly3D assures the simulation and rendering processes independence while


introducing a discrete simulation scheme. DFly3D defines a OSFi for each ob-
ject i (including the render object, OSFrender = F F ). 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 continuously simulating and rendering, so it releases time for other tasks.
TG is not shared by the simulation and rendering phases (figure 3). This is
why there is released time TF > 0 (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 num-
ber 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.

While the system is not collapsed, the simulation and rendering times are in-
dependent. Increasing the simulation or rendering time supposes to decrement
the free time (equations 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 ↓⇒ F F ' (4)

TR ↑⇒ TF ↓⇒ F F ' (5)

6.2 Free Time

DFly3D avoids unnecessary renderings, releasing the computer power for other
applications or to improve other videogame parts, such as AI, collisions de-
tection precision or videogame realism.

The figure 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

10
100

90

%Videogame Time (Difference)


80

70

60

50

40

30

20

10

0
1

10

20

30

40

50

60

70

80

90

100

110

120

130

140

150

160

170

180

190

200
O bje cts Numbe r

Fig. 4. Difference between the free time at the discrete and the continuous systems.
the 97% of the application time when there is only an object in the scene
(figure 3). This is due to the following reasons:

• The rendering and simulation processes are independent in DFly3D (decou-


pled).
• The F F 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 programmer. It can be constant
during the videogame execution or variable to be adapted to the object
needs.
• 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).

6.3 Frame Frequency

Fly3D F F 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 F F the videogame should generate.


The defined F F is maintained while the system is not collapsed. The tests
performed set the F F to 25fps. The Fly3D rendering time decreases when
the amount of objects increases because the simulation time is enlarged. The
continuous system F F is highly dependent on the computer power and the
programmer has very little control on this value (the F F cannot be set ex-
plicitly depending on the videogame needs). The rendering time in DFly3D is
always smaller than the Fly3D rendering time because Fly3D generates un-
necessary renderings if the computer power is high or the simulation and the
rendering complexity is low.

The figure 5 shows the F F generated by both systems maintaining the same

11
100

-100

-200
FPS

-300

-400

-500

-600
1

10

20

30

40

50

60

70

80

90

100

110

120

130

140

150

160

170

180

190

200
Obje cts Num be r

Fig. 5. Difference between the F P S generated by the discrete and the continuous
systems. F P S rendered unnecessarily by the continuous system.

100 Samples Number in both Systems 78


Difference
90 76

80 74
70
72
S a m p le s N u m b e r

S am p les N u m b er

60
70
50
68
40
66
30

20 64

10 62

0
60
0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10
Tim e Tim e

DFly3D Fly3D

Fig. 6. Objects sampling at the discrete and the continuous systems.


image quality. DFly3D fixes the F F and it keeps the F F constant while the
system is not collapsed. The continuous system renders unnecessarily wasting
computer power.

6.4 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 F F (equation 6). If a particular object
needs to be sampled with a higher frequency, the object is undersampled (er-
roneous behavior). If other object needs to be sampled with a lower frequency,
it is oversampled (wasting computer power).

SSF = F F = OSFi , ∀i ∈ O (6)

DFly3D fixes a different sampling frequency for each object in the system
(equation 7). The global SSF does not exist. The render process is controlled

12
Characteristic Fly3D DFLy3D
Simulation Continuous Discrete
Coupled Decoupled
Videogame Time TG ' TR + TS TG = TR + TS + TF
Free Time TF ' 0 TF = TG − TS − TR
TS ↑ TR ↓, F F ↓ TF ↓, F F '
TR ↑ TS ↓, F F ↑ TF ↓, F F '
Collapsed system TG = TR + TS TG = TR + TS
System load increase Distribution of the increase Proportional increase of TS
among TS and TR y TR
FF System load dependent Defined by the program-
mer
Variable. Constant or adaptable.
Objects Sampling Equal for all system ob- Defined by the program-
Rate jects. mer for each object.
Variable according to the Constant or adaptable.
system load.
Table 1
Fly3D and DFly3D Comparative.

by the render object. The render object sampling frequency is the F F .

OSFREN DER = F F, OSFi = OSFj , ∀i, j ∈ O (7)

DFly3D allows the programmer to define a particular object sampling fre-


quency dynamically changing to be adapted to the object behavior needs in
order to avoid erroneous behaviors and save computer power (figure 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). The figure 6 shows the amount of unnecessary
samplings that carries out the continuous system.

Table 1 shows a comparative summary of both systems.

13
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. Discrete decoupled simulations are more pre-
cise (preventing 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 fre-
quency 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 videogame behavior from the com-
puter power (while the system is not collapsed). So, the same videogame can
be executed in machines with different computer power with the same simula-
tion quality or to improve the quality of simulation depending on the computer
power.

8 Acknowledgements

This work has been funded by the Spanish Ministry of Science and Technology
(MCYT TIC2002-04166-C03-01).

References

[1] Agus M, Giachetti A, Gobbetti E, Zanetti G. A Multiprocessor Decoupled


System for the Simulation of Temporal Bone Surgery. Computing and
Visualization in Science, 2002.

[2] Banks J, Carson II JS, Nelson BB, Nicol DM. Discrete-Event System
Simulation. Prentice Hall International Series in Industrial and Systems
Engineering, 2001.

[3] CACI Products Company. http://www.caciasl.com/.

[4] Conitec Datasystems. http://www.conitec.net/.

[5] Crystal Space. http://crystal.sourceforge.net/drupal/.

14
[6] Darken R, Tonnesen C, Passarella K. The Bridge Between Developers and
Virtual Environments: a Robust Virtual Environment System Architecture.
Proceedings of SPIE 1995.

[7] Fishman GS. Principles of Discrete Event Simulation. John Wiley & Sons, 1978.

[8] Garcı́a I, Mollá R, Ramos E, Fernández M. DESK Discrete Events Simulation


Kernel. ECCOMAS, 2000.

[9] Garcı́a I, Mollá R, Barella T. GDESK: Game Discrete Event Simulation Kernel.
Journal of WSCG 12(1), pp. 121-128, 2004.

[10] Genesis3D. http://www.genesis3d.com/.

[11] Idsoftware Page. www.idsoftware.com/archives/doomarc.html/.

[12] 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 Computer Graphics
and Applications, 1995.

[13] QNAP: Queuing Network Analysis Package. 1st Int. Conf. on the Numerical
Solutions of Markov chains, 1990.

[14] Quake Developers Page. www.gamers.org/dEngine/quake/.

[15] Randy P, Conway M, DeLine R, Gossweiler R, Maile S, Ashton J, Stoakley R.


Alice & DIVER: A Software Architecture for the Rapid Prototyping of Virtual
Environments. Course notes for SIGGRAPH’94 course, Programming Virtual
Worlds, 1994.

[16] Reynolds C. Interaction with Groups of Autonomous Characters. Game


Developers Conference Proceedings, 2000.

[17] Rohrer M. AutoMod Product Suite Tutorial (AutoMod, Simulator, AutoStat)


by AutoSimulations. Winter Simulation Conference, 1999.

[18] Sadowski D, Bapat V. The Arena Product Family: Enterprise Modeling


Solutions. Winter Simulation Conference, 1999.

[19] Shaw C, Liang J, Green M, Sun Y. The Decoupled Simulation Model for Virtual
Reality Systems. CHI Proceedings 1992.

[20] Schwetman H. CSIM: A C-based Process Oriented Simulation Language. Winter


Simulation Conference, 1986.

[21] Ståhl I. GPSS - 40 Years of Development. Winter Simulation Conference, 2001.

[22] Watt A, Policarpo F. 3D Computer Games Technology: Real-Time Rendering


and Software. Addison-Welsey. 2001.

[23] Watt A, Policarpo F. 3D Computer Games. Addison-Welsey. 2003.

15
Inmaculada Garcı́a received the PhD in computer science from the University
of Valencia (Spain) in 2004. Associate professor in the Technical University
of Valencia. Her current research interest include simulation and real time
grahics applications.

Ramón Mollá. Associate professor in the Technical University of Valencia.


PhD since 2001. He works in the computer graphics area since 1992, when
he finished his studies in computer science. He works currently in real time
grahics applications, specially in videogames simulation kernels and in low
level raster conversion primitives.

16