Adding Hitpoints — Handmade Hero — Episode Guide

1:55Recap and plan for the day ahead

3:46Describe the "sumo mandarin" still being eaten

4:46Fix jump shadow

7:13Modify shadow alpha on floating head

10:43Reiterate the fact that PushPiece is in pixel space

11:46Make the familiar stop a little way from the hero

13:41Add Hitpoint to hero

15:25handmade.h: struct hit_point

16:02Should hitpoints themselves be entities?

17:18Draw those hitpoints

23:38Blackboard: How to center hitpoints around the guy?

29:30Implement the code to draw these hitpoints in the right place

30:45Change the Offset in PushPiece into meter

38:51Run the game and watch the Familiar bob heavily

39:03Reduce the BobSin multiplier

39:36Place the hitpoints in their correct positions

41:24Blackboard: Explain why hitpoints stick together

42:08Flip the y coordinate in PushPiece

43:20Unify PushPiece and PushRect

46:03Fix jump hitpoints

46:19Basic v3 and v4

51:56Explain why templates are bad

55:14Q&A

🗩

55:14Q&A

🗩

55:14Q&A

🗩

56:17Q: Isn't making a struct for HP is preprogramming a little?

57:48Q: Why not just use HitPointMax = 12 instead of dividing into 3 hearts and 4 segments?

58:24Q: I noticed the floating head was always behind the player. Are you going to go for a depth buffer approach or draw back-to-front to handle this?

1:07:36Q: Would it be entirely possible to completely reconstruct the current code by following every episode of the series without preordering the game?

1:08:08Q: Do you think that I, as a totally new person of programming, would be able to follow along with the pace you are working at, doing rapid changes to the code without sometimes telling us why?

1:09:11Q: Is there ever gonna be a moment of reflection at some point in the future where you provide a somewhat high level overview of the engine components we have been encountered so far, what they will provide and why we need them?

1:10:34Q: I think it would be really cool if you implement a smooth scrolling room-based combination

1:11:19Q: Is the translucent thing you were talking about hard to do on 2D UI? Do you write the UI in the same Z-buffer or is it separate?

1:12:51Q: Will you be implementing more memory handling code and, if yes, what kind of things?

1:14:58Q: If you do a bounding box, which is an inset X amount of meters / tiles from the room edge, you could use the collision of the player with the bounding box to start smooth scrolling to the next room, etc.

1:15:36Q: How will we be handling resolution variance?

1:16:41Q: What kind of error handling / logging do you have in place now, and how will that possibly change?

1:17:35Q: Why are strings such a problem for so many engines?

1:17:45Q: How hard is it to port a 32-bit game engine to compile a 64-bit output client if the origin game splits executables to surpass the 4-gig cap?

1:18:30Q: Zelda had scrolling when you transition between rooms. Are you going to have something similar?

1:18:47Q: Would you mind giving a brief walkthrough of the memory management going on right now in the code from the game boot and forward?

1:22:21Q: Why is it impossible to resize a raster image and why does everything have to be rasterized for drawing? Why can't textures be vector-based?

1:24:51Q: Couldn't we build handmade.cpp and win32_handmade.cpp in separate threads? Is there a way to pipe the error messages in a sane way using the build.bat approach?

1:25:57Q: SWTOR does it (about 32-bit splits into 2 separate processes question)

1:26:54Q: Binding of Isaac does have scrolling between rooms, albeit a very quick transition

1:27:37Q: What is the drawing app we are using?

1:28:13Internet: Check out the scrolling in The Binding of Isaac

1:29:54We've finish up on the stream

1:29:59Save our giant drawing in Mischief

Keyboard Navigation

Global Keys

Menu toggling

In-Menu and Index Controls

Quotes and References Menus and Index

Quotes, References and Credits Menus

Filter Menu

Filter and Link Menus

Credits Menu