BizHawk's Lua interface is indeed quite different from the one in Gens, and I'm not sure how much of the Sonic HUD code would be reusable without major modifications. For example, I went to write a basic jump predictor and found that apparently BizHawk Lua has no equivalent to gens.emulateframeinvisible(), or even a way to automate frame advance at all since every call to emu.frameadvance() just defers the script. I'll have to write that functionality as a "jump finder" bot instead, it seems.
The other option I considered was figuring out how speed is calculated during a jump and doing the prediction that way. I unfortunately wasn't able to figure that out, but I
did figure out that the values at FFC204 and FFC206 are the forward and lateral components of Sonic's speed. These values are computed from his angle and X/Z speed, and might only be used for choosing animations and detecting skids. Comicalflop was calling FFC204 "speed" and was optimizing based on that. This does reflect Sonic's speed if he's moving in the same direction he's facing, but if facing a direction other than the one he's moving (such as when turning) the value at FFC204 will be
less than Sonic's absolute speed. I spent last night converting some code into C, starting at loc_3510 and going backwards, since I understand C better, and
here's the code that computes those values. This is a very short part of sub_2DDE which is called from IngameRun and
appears to be the subroutine to update Sonic's motion. (Sonic's base address is loaded into a6 pretty early and not touched for the rest of the subroutine.)
By the way, here's
the .wch file I've put together so far. It doesn't have a lot you don't have already, but should save a bit of time.
(Also, I did manage to save some frames, and now am only 7 frames away from the level timer showing 0:42. Guess I'm not done with GGz1 yet!)
