mark nelson [email protected] graphics hardware & game worlds fall 2013
TRANSCRIPT
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