Lab: Fancy Sprites

Take the new code from 2D Scenes and Geometry and add it to the code as of the end of the textured triangle lab.

The rest of this lab is split into two categories: game programming and graphics programming. Pick and choose from the categories and show me what you've got. It might be a solid foundation for your first unit 2 game! Next time around we'll look at how to organize our code a little more cleanly and get more of a game/engine split going.

• Game programming
  • Use your own spritesheet
  • Arrange a world out of big and small sprites
    • The rotation feature in the graphics programming area could be really useful
  • Have some sprites move randomly or according to some rules
  • Control two different sprites (with different keys?) and notice when they overlap
  • Make a game where you click on sprites to "destroy" them (whatever that means!)
  • Implement scrolling by moving the camera around; possibly implement zooming in and out too
    • Do you need to change GPUCamera and the shader to implement zooming? Why or why not?
  • Implement sprite animation by cycling a sprite between different sheet_regions from time to time
  • Write a convenience wrapper around Texture called SpriteSheet which maps sprite indices or names onto sheet_region values, to make updating the GPUSprites easier
  • Next to sprites, have a parallel Vec of Thing structs
    • Thing could have properties like health, speed, or other "gamey" things
    • As long as things[i] corresponds to sprites[i], it's easy to keep both in sync when you change one
    • Make the sprites' appearance or behavior depend on their corresponding Thing
• Graphics programming
  • Add a rotation point and angle to GPUSprite, updating the vertex shader
  • Add a color-shifting color to GPUSprite, updating the vertex and fragment shaders
    • It's easiest to pass this color offset data through to the fragment shader from the vertex shader
  • Load multiple images into an array texture (modify load_texture to take &[impl AsRef<std::path::Path>] and use a larger number of depth_or_array_layers, updating the sampling in the fragment shader to match), so that you can have e.g. background objects and foreground sprites from different spritesheets.
  • Make it so that your sprites stay the same shape, no matter how the window is resized
    • Part zero: Figure out your desired screen size and compute its aspect ratio by dividing its width by height (4:3 and 16:9 are common; for example, 1024x768 is 4:3)
    • Approach one: Viewport manipulation
      • Part one: When the window size changes (and at launch), compute the part of the window you want to draw into
        • Hint: either the window is too wide or too tall, so compare the window's aspect ratio to your desired ratio.
          • If it's smaller than yours, that means the window is too narrow and you should only use some of the vertical space and all the horizontal space (but how much? Your aspect ratio will tell you!)
          • If it's bigger than yours, then the window is too wide and you should use all the vertical space and some of the horizontal
          • If it's the same, then you can pick either one
      • Part two: use the set_viewport method of RenderPass to prevent drawing outside of that rectangle
      • Drawback: If the window is very large or very high-resolution, you'll find that the game slows down as its size increases
    • Approach two: Render to texture
      • Part one: Instead of using the swapchain texture, draw your render pass into your own texture with the size that you selected earlier
      • Part two: Add a second render pass that draws a quad textured with your render target texture, appropriately placed within the viewport (as in approach 1)
      • Besides letting you control the resolution at which you render, this also lets you do post-processing effects on the rendered image! Cool!
      • Drawback: There might be funny interactions between your camera's screen size and your off-screen texture's size that could cause blurriness sometimes