Hi all,

I code along in real-time to the videos, pausing to write code and make notes and check things. Most of the bugs I find are either 1) mistakes I've made when typing, or 2) bugs that are addressed immediately.

However, sometimes there are bugs that aren't noticed on the stream at that moment (e.g. certain edge cases I bump into that Casey happens not to).

I know these are all addressed eventually, sometimes an episode or two later, sometimes 10 minutes later. But it's hard to cross my fingers and just keep going if I don't know when it'll be fixed. (And I'd prefer not to proceed while there's a known bug, 'cause I don't wanna complicate it by possibly adding more!). So, for people who do follow the videos in this way, I think it might be worth having a master thread where they can be reassured about bugs like these. What do y'all think? Would that be useful to anyone else?

E.g. note the day number, the timestamp where the bug occurs, a description, and either a fix if somebody has come up with one and doesn't know what Casey's eventual solution was, otherwise a day#/timestamp where it is addressed, and/or a link to a thread discussing the bug if available? (I have one right now that I really can't find a thread about).

For example:

Day 032, minute 35

Description: player movement stops working entirely and tilemaps don't change to new ones when going through doors (behaviour may change depending on xy-specific values).

Solution: Damn it, I left the video playing while I typed (and retpyed 'cause I hit the back button, damn it) a long explanation and the fix, and he just found the bug (and fixed it) at the 1h00m30s mark.

(Short description of the fix anyway: RecanonicalizeCoord was using an axis-specific value [World->CountX] in one of the if-statements, that hadn't got changed out for the axis-neutral version [TileCount] when rewriting, and when RecanonicalizePosition calls RecanonicalizeCoord, it was passing World->TileMapCountX/Y instead of World->CountX/Y, so the code was comparing tile values to the number of tilemaps on each axis of the world, instead of the number of tiles on each axis of the tilemap.)

Again, episode 32:

When getting everything in metres instead of pixels, the offset (and as a result, the collision-detection) gets out-of-whack because the tile-relative positions TileRelX and TileRelY are initialized in pixels, but are used in calculations with metres. (Again, this might only be apparent when restarting the .exe instead of just reloading a recompiled .dll).

I don't know when this gets addressed, but for now the fix that made it work for me was to convert them to metres when we initialize the player position in handmade.cpp:

Interesting use-case and idea! I could (reasonably trivially) get this reassurance into the annotations by editing the annotation marking a bug's first encounter to link to the annotation marking its resolution. From memory, the annotations have tended not to be forward-thinking, focusing only on the stuff happening at the present moment, but I should totally be able to shift that focus.

A further possibility would be introducing into the annotation system the formal notion of bugs, probably UUID'd, with every annotation pertaining to a bug being tagged with that bug's UUID. This would join everything up, and enable auto-generation of a master page (an insectarium, if you will) of all bugs encountered. Let me mull this over to see if it feels at all tenable.