is presently its sole maintainer,
You can support him:
Recap on what we're set out to do
About canonical position and using it for the player position
GetCanonicalPosition() to RecanonicalPosition()
Debugging the new code
Movement units from pixels to meters per second
Recanonicalize edge case debugging after assertion fail
Back to changing movement units
Casey enjoying the little things
Debugging player position
Would this be the time to put on screen text for debug info?
What is the variable called 'Gray'?
How does the difficulty of conceptualising this type of code compare to say coding the backend to a web application?
The window title bar is a nice place to spit out some text!
About replay buffers: I don't think we ever use the 0th buffer in the Win32State
When do you decide to add visual cues to help with debugging?
What are your thoughts on the progress you make daily?
Does the code actually handle skipping a tilemap?
Can the player go diagonally through two wall tiles joined by corners with the current collision detection code?
Why are you so fond of inline?
Are you going to have input envelopes for feel like acceleration and fricksion?
Can you explain what you meant by canonicalization in some simpler terms?
Would this kind of code be good for unit tests/fuzz tests to make sure strange corner cases don't creep around?
Are there reasons why programmers of older adventure games chose to move the character around the map and not vice versa?
Earlier you said const is ugly? Ugly because of how it looks or for some other reason?
What's your preferred 2D coordinate system? Y going up or down?
Now that there's no raw_position can we rename canonical_position to position and recanonicalize to fix or rebase?
Will we be using the tilemap for path finding or some other way to get smoother movement?
Will you release your version control system?