1. Mark Nelson mjas@itu.dk Graphics hardware & Game worlds Fall 2013 www.itu.dkwww.itu.dk

2. Exercise from last week  Choose a game  Does it generalize into a game engine?

3. Engine levels  Hardware  Graphics primitives  In-memory representations  In-engine representations  Gameplay

4. In the beginning

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

6. Bouncing oscilloscope ball

7. Tennis for Two (1958)

8. Oscilloscope properties  No memory:  Points start to fade nearly instantly  Write-only  Multiple objects mean flicker  Brilliant, smooth outlines, but no sprites

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

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

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

12. Framebuffer drawbacks?  Can you think of any?

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

14. 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)

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

16. Blitting  Moving sprites have a mask  Draw by combining with background  Movement involves  Undraw  Redraw somewhere else  Also: overlaps, etc.

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

18. Hardware sprite pros  No manual blitting  Maybe faster  Maybe sprites can have extra features  Higher-res  Built-in collision detection

19. Hardware sprite cons  Any downsides?

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

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

22. Racing the beam

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

24. Combat

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

26. Pac-Man

27. What about 3d?

28. Doom

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

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

31. Static v. dynamic  Static meshes  Pre-render effects  No checks for updates  Precomputed data structures  Downsides  Deformable terrain?  Consistent lighting?

32. Completely different approach: voxels  3d volumetric-pixel grid  int voxel[1000][1000][1000];  voxel[50][0][22] = ROCK;  Render visible surfaces

33. 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”

34. Minecraft

35. Minecraft pros/cons?  Compared to a poly-based ”regular” 3d engine  [discuss]

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

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

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