Mark Nelson mjas@itu.dk

Graphics hardware & Game worlds

Fall 2013 www.itu.dk

Exercise from last week

Choose a game

Does it generalize into a game engine?

Engine levels

Hardware Graphics primitives In-memory representations In-engine representations Gameplay

In the beginning

Oscilloscope X-Y mode

Two wire inputs Phosphor beam points at the (x,y) given by their voltages

Vary voltages to move beam Fast-moving beam simulates image, due to phosphor decay

Bouncing oscilloscope ball

Tennis for Two (1958)

Oscilloscope properties

No memory: Points start to fade nearly instantly Write-only

Multiple objects mean flicker

Brilliant, smooth outlines, but no sprites

Programming an oscilloscope game

Programming is strange

Continuous time: no frames, time advances continually

Must ”know” where everything is

Lag in drawing borks the display

Pixel grid with a framebuffer

The ”standard” 2d graphics interface

int pixels[640][480]; pixel[50][200] = 10;

Graphics driver redraws the framebuffer to the screen N times per second

Framebuffer plusses

Memory: Pixels stay when you set them Pixel values can be read

Discrete time: draw image, then image is displayed

Complex shapes & sprites are easy

Framebuffer drawbacks?

Can you think of any?

Erasing the old image

If the ball moves, how do we get rid of its old position?

Oscilloscope images decay for us, so just wait

With the framebuffer, we have to handle this

One way

Redraw everything (perhaps w/ double-buffering)

for (int x = 0; x < WIDTH; x++) { for (int y = 0; y < HEIGHT; y++) { pixelBuf[x][y] = 0;for (int i = 0; i < objects.size(); i++) { objects[i].draw(pixelBuf);drawBuffer(pixelBuf)

Redrawing everything

What if the framebuffer is on the graphics card? What if our memory bandwidth to the card is low?

Don’t want to re-send all data, just what changed

Blitting

Moving sprites have a mask Draw by combining with background

Movement involves Undraw Redraw somewhere else

Also: overlaps, etc.

Hardware sprite support

Stick sprites in some registers, let card handle blitting

Higher-level API: Move sprite to (x,y) Move sprite 5px left Set sprite to be moving at px-left-per-frame velocity

Hardware sprite pros

No manual blitting Maybe faster Maybe sprites can have extra features

Higher-res Built-in collision detection

Hardware sprite cons

Any downsides?

Hardware sprite cons

Assumes a particular way of using the framebuffer

Number of sprites

Size of sprites

Becomes a strange low-level graphics device if assumptions not met

Example: Atari 2600

Framebuffer: but only enough for half of one low-res line

2x higher-res hardware sprites, plus 2x ’missile’ and a ’ball’

Draws one TV scanline at a time

Pulls out of the registers whatever is in them when the electron beam is ready for them

Racing the beam

Programming the Atari 2600

Background will be vertical lines unless you do something Change the values as lines are being drawn

Normally, exactly two sprites, two missiles, and a ball

Combat

Programming the Atari 2600 more

Change registers on the fly

Count cycles and change background in mid-line

Recycle sprite registers between lines

Flicker between sprites

Pac-Man

What about 3d?

Doom

Doom: 3d? 3d room interiors

2d sprites 8 or 16 angles 2d in the vertical plane, parallel to the screen

2d entity positions 2d in the horizontal plane

2d skyboxes

Doom: why sort-of 3d? No moving 3d

Pre-render lighting/textures/collision boxes 2d collision detection No high-poly models

One result: 2d level design / movement

Static v. dynamic Static meshes

Pre-render effects No checks for updates Precomputed data structures

Downsides Deformable terrain? Consistent lighting?

Completely different approach: voxels 3d volumetric-pixel grid

int voxel[1000][1000][1000]; voxel[50][0][22] = ROCK;

Render visible surfaces

Minecraft’s use of voxels One-to-one mapping between voxels and game-world

World is made of building blocks

The blocks are voxels

Convert to renderable scene when ”nearby”

Minecraft

Minecraft pros/cons? Compared to a poly-based ”regular” 3d engine

[discuss]

Design considerations of a 3d pipeline

What’s retained on the GPU? What kind of model, camera, T&L pipeline? What’s built in v. programmable?

Previous trend was towards specialized hardware support for a fixed pipeline

Current trend is towards program-everything, but on the GPU

Built-in hardware features

Like engine features, make some things easier, but can be too opinionated/constraining

Different in that it’s not just a design/architecture consideration. Choice also needs to align with technical constraints.

First project

A 2d platform-game engine

First steps: Set up a 2d drawing context, (e.g. SDL with SDL_Surface) Draw background Blit & move sprites Begin thinking about data structures