1 / 37

Graphics hardware & Game worlds

Graphics hardware & Game worlds. Mark Nelson mjas@itu.dk. 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

posy
Download Presentation

Graphics hardware & Game worlds

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Graphics hardware & Game worlds • Mark Nelson • mjas@itu.dk Fall 2012 www.itu.dk

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

  3. In the beginning

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

  5. Bouncing oscilloscope ball

  6. Tennis for Two (1958)

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

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

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

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

  11. Framebuffer drawbacks? Can you think of any?

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

  13. One way Redraweverything (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)

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

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

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

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

  18. Hardware sprite cons Any downsides?

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

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

  21. Racing the beam

  22. Programming the Atari 2600 Background willbevertical lines unlessyou do something Change the values as lines arebeingdrawn Normally, exactlytwosprites, two missiles, and a ball

  23. Combat

  24. Programming the Atari 2600 more Change registers on the fly Count cycles and changebackground in mid-line Recyclesprite registers between lines Flickerbetweensprites

  25. Pac-Man

  26. What about 3d?

  27. Doom

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

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

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

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

  32. Minecraft’suse 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”

  33. Minecraft

  34. Minecraft pros/cons Pros Deformable everything Infinite world Cons Lower-res surfaces (constant resolution everywhere) GPU mismatch

  35. Engine exercise Think of an engine Or a distinctive feature of an engine What does it make easier? What does it make harder?

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

More Related