is presently its sole maintainer,
You can support him:
Review of the live code editing feature
Building a demo to show gameplay tuning workflow
Testing the demo
Necessary improvements to square drawing
Problems with gameplay tuning and a solution
Making a loop editor for code
The ease of storing the input stream in memory
Writing it out to disk instead
Creating a win32_state structure that we can pass around
Press L to record
Usage code for recording and playback
Implementing the record and playback functions
Functions to handle the recording output file
Functions to handle reading in the recording file
Some code to loop the input playback
Testing the recording and playback
Input record success, moving on to record game state
Implementing recording of game state
Testing, and a failure to loop
Successful looped editing demonstration
Playing around with window types
Transparent Window! And Access Violation!
Improvements to transparent window.
Start of Q&A
Does Win32PlayBackInput need to return status in case the file read fails and/or reaches the end, since in those cases the function output data structures will be stale or invalid?
Will this break when you make changes to the game_state structure?
Why didn't you use a switch for all the VKCode stuff?
Since it's mostly zeroes, do you think it'd be worth writing out the game state in a sparse way using a simple RLE or something, or is performance sufficient? Or perhaps that would make performance worse?
What's on the schedule for next week?
Are you going to show how to create more debug tools like this?
Regarding saving game state for recording, won't we run into problems if we port a system that doesn't allow us to specify a base address?
Any chance for a high-level overview while cleaning up?
Isn't a two gig snapshot of your game memory crazy huge though?
I think your sine wave is a tad bit off on land of the jump.
I'm thinking maybe less about the error and more about what happens at the end of the stream when it loops, doesn't that generate an extra repeated input event played back, or am I missing something?
Can you clarify if function pointers are part of that game_state block, maybe elaborate on what could ever cause it to fail or misalign?
How can we make the playback work if we have no base address?
Wouldn't the address spaces of two game_state's clash?
Would a memory-mapped file that doesn't commit to disk be faster to read/write from?
I thought you were going to use the memory snapshot as a game save, but you're using it like a save state in an emulator.
How easy do you think it is to re-arrange an existing codebase so that it supports the instant live code editing feature, and what steps would need to be taken to get there?
Will there be a Christmas special?
How will replay work once you have start-up logic for the game? How will it be skipped? Will it just work?
Clarification of earlier question (How often do you look up code?) How often do you study code on your own?
Perhaps ReBaseImage() regarding loading dll at location?
Suggestion to add -mix to the linker for fixed dll location.
How long did it take for you to get to a point where you can concieve of a feature and with little effort know exactly what you need to accomplish to realize that feature?
Couldn't you create an offset pointer struct which overloads the unary * operator?
Have you got some good explanation on how you architect code, is that in the text you wrote about your work on the Witness?
I have to spend a lot of time unlearning what I was taught just to get to features which should be easy, but were made hard by the kind of programming I learned in school. Have you had a similar painful unlearning process?