Httpai.eecs.Umich.edu.Soar.classes.494.Talks.lecture 3 Arcade Game Architecture

7/31/2019 Httpai.eecs.Umich.edu.Soar.classes.494.Talks.lecture 3 Arcade Game Architecture

1/46

Architecture and 2D Graphics

John Laird

ep em er ,


2/46

Examples

ss e omman , pace nva ers, rea out, ent pe e,

Pac-Man, Frogger, Tempest, Joust,

2D environment

Move objects around screen in 2D

Major interaction is via collisions

Simple rules

Simple goals

Hit things: get points

Avoid getting hit: stay alive


3/46

Easy-to-learn simple controls

Single-screen or simple scrolling Often Infinite Pla

Multiple Lives

Little to no story


4/46

=Discrete simulation: each cycle computes a ``snapshot'' of the world

erence e ween a ec n ca s mu a on an a game:

Continual behavior Not ust run a ro ram and et an answer

Real-time and highly interactive Update at around 30 times/second

Necessary to avoid clunky action or missed player input

Rendered time always lags behind real time/game time by at least 1 frame

Consistency is important (to both)

Simple physics: velocity, elastic collisions, ,


5/46

Initialization Overall Game Game Session

Control

Exit

Control

Player Input

Main Logic

Physics1 cycle/frame

ame

Collision Processing

Render scene

to buffer

Copy buffer toTime sync

wait


6/46

-Initialization Overall Game Game Session

Control

Exit

Control

Local Player

1 cycle/frameMain Logic Consistency

remote players

Receive remote Physics

Game AI

Collision Processing

players input

Render scene

to buffer

waitCopy buffer to

display

me sync


7/46

Fixed Discrete (tied to real time)

p ate wor mo e eac t me step

Each time step is same size

Wait if done too earl Game events

Detect interactions by examination

Pros: Simpler physics

Smoother graphics

Cons: Computation must fit into time step

User inputs


8/46

Variable Discrete

me steps are var a e

dictated by amount of computation

fast as ossible Game events

Pros: No bus wait

Faster hardware gives smoother

interaction and higher frame rate

Cons Requires a little bit more work on

User inputs

Jerky motion if frame rate too low


9/46

Event-based

(collision) Game time stretches and contracts as

Game events

Computed analytically

Not suitable for real-time interactive game u can e use w some s mu a on

game (fast forward to when the shipreaches port or meets pirates)

User inputs


10/46

Directly control

electronic gun of CRT

raw ngs e ne as nes Lines stored as endpoints

Look like wireframes

No curved lines

Limited variation in color or intensity.


11/46

Example: Asteroids, Battlezone

. . .

Advantages: Control the electronic un directl so can be fast Only draw what is on the screen

No jagged lines (aliasing) ro ems:

Hard to draw filled objects Must draw everything as lines: text, circles, surfaces, ...

$$s: Cant use commercial TV technology

Example Displays: extron cs,


12/46


13/46

Advantages:

Can easily draw solid surfaces Maps screen onto 2D memory an move oc s o mage aroun , contro n v ua p xe s

Problems: Aliasing problems


14/46


15/46

x,y Lines

4,4

Two points

Draw all points in between--2,-1


16/46


17/46

Defined by vertices

Closed: all lines connected Draw one line at a time

100,100

Can be concave or convex

Basis for many games

Re uired data:

Position: x, y Number of vertices

moveto(100,100)

lineto(100,300)

Color (shading) lineto(500,100)

lineto(100,100)


18/46

Translation: moving

Scaling: changing size Rotation: turnin

Clipping and scrolling


19/46


20/46

Problem: If we move an object, do we need to change

t e va ues o every vertex

Solution: change frame of reference Worldcoordinate system for object positions

coordinates relative to screen

Local coordinate system for points in object coordinates relative to the position of the object (frame of reference)

Triangle location: 4,0P1: 0, 1

P2: -1, -1

P1

P3: 1, -1P3P2


21/46

Multiply the coordinates of each vertex by the scaling

actor.

Everything just expands from the center.

object[v1].x *= scale

object[v1].y *= scale


22/46

Spin object around its center in the z-axis.

Rotate each point the same angle Positive angles are clockwise ega ve ang es are coun erc oc w se

x = x0 * cos(angle) - y0 * sin(angle)

0 0

Note: angle measured in radians not degrees!


23/46

Translation rotation scalin can all be colla sed into

matrix operations:

rans a on:

0 1 0

dx d 1

x y 1 *

Scaling:sx 0 0

0 sy 0sx, sy =

scaling valuesx y 1 *

Rotation:0 0 1

cos -sin 0

sin cos 0

0 0 1

x y 1 *


24/46

sx*cos -sx*sin 0

* **

dx dy 1

Using Standard Trig functions-

Prestore all rotations you are going to need


25/46

Common Problems:

c er an ear ng Video update slower than display

Change video buffer during updating Solution:

Frame 1 Frame 2 Displayed

Double buffering -- write to a virtual screen that isnt being

displayed.

, .

Video Pointer

Video

Buffer

Backup

Buffer


26/46

Ob ect that moves around, dis la ed as a bit ma

NxM pixels:12 x 12 = 144. 100 x 100 = 10,000. Displayed on a background

ome aspec s can e ransparen


27/46


28/46

2D Gimp

o os op

Paint

3D u o ax Maya

Blender 3D

Milksha e 3D

Save as file


29/46

Some parts of the sprite are transparent

se a spec a co e to e transparent or a p a c anne

When drawing the pixels, dont copy that code Is ex ensive if done in software because done for ever ixel

Todays computers have hardware support

Some s rites have no trans arencies Can have separate draw function

Avoid test for transparency


30/46

Options:

Can lead to very blocky pictures when they get big

Pre-store different sizes

Pre-store different sizes for major size changes: x2 Dynamically compute intermediate sizes

Supported in Direct-X (in hardware and software)


31/46

Can fake depth by scaling but what if overlap?

Associate depth with each Sprite - usually small number Image space solution

Maintain shallowest depth rendered

Add pixel if closer than previous

Lots of work at each pixel if in software Hardware Z-buffer to rescue -

Object space solution

O(#_of_objects * log(#_of_objects))

Draw back to front


32/46

16 different pictures is reasonable start

Pick the closest one to the current orientation

ow supporte y ar ware


33/46


34/46

Display the parts of the objects on the screen an get array out o oun errors not care u

Easy for sprites done in DirectX

Border vs. image space or object space


35/46

Image space:

at s go ng to e sp aye

Primitives are pixels O erations related to number of ixels

Bad when must do in software

Good if can do in parallel in hardware have one processor/pixel

Object space: Objects being simulated in games

Primitives are objects or polygons Operations related to number of objects


36/46


37/46

Image Space:

e p xe - eve representat on o t e comp ete mage.

Clipping or eac p xe , es s ns e e v s e reg on

If buffer is 320x200, test 0-319 in x, 0-199 in y.

Easy to implement

Works for all objects: lines, pixels, squares, bit maps

Works for subregions Expensive! Requires overhead for every point rendered if done

Cheap if done in hardware (well the hardware cost something)


38/46


39/46


40/46


41/46


42/46

Tile map

screen


43/46

Object-based

Each time render those objects in current view Go through list of object linear in # of objects

Grid-based Overlay grid with each cell having a list of objects

n y cons er o ects n ce s t at are n v ew


44/46

Image Space:

. .

Object Space: Hard for com lex and concave s aces:

Standard Approach:

Cheat! Create a bounding box or circle test each vertex to see in another object

Hide this by making your objects boxy or round

Don t ave o ects e:


45/46


46/46

e extra care u var a e t me step s use n game oop

Documents

Httpai.eecs.Umich.edu.Soar.classes.494.Talks.lecture 3 Arcade Game Architecture