byuu wrote:
I think it might have something to do with slow decay/transition states of the real hardware buttons, but I'm not sure how to emulate that to prevent this behavior.
The only transition states that exist are between when you select a line and when you read out the button state. On a DMG, when you write a 0 to activate one of the lines, this signal is propagated through the ribbon cable up to the display board and back to the relevant input pin on the CPU. Because of capacitance and series resistance, it may take a couple of microseconds for the state to propagate. This is why you see games read out $FF00 multiple times. This is nothing more than a delay, and only the last read does anything. As you might have noticed, the button group usually has a longer delay in the readout routine than the D-pad group, likely because the start/select group has a longer propagation delay than the other buttons, especially if it's worn/dirty. (I've tested this.)
That said, the propagation delay never needs to be emulated for gameplay of licensed ROMs. The only time when it would matter is if a program is actively checking for it, as in reading the button input early and making sure the input hasn't propagated. Even then, GBC completely lacks this delay, as it has 8 input pins and this switching is handled in logic inside the chip, which means there's no propagation delay. However, I convinced beware to implement it into BGB, to discourage people from writing ROMs that don't work on real hardware. (As a primary use of BGB is as a development tool.)
One theory I had was that the problem might happen if only left was pressed in one frame, and then only right was pressed the next frame, a situation unlikely to occur on a real console as it would likely take a human more than one frame to pivot the D-pad from one side to the other. But this would be trivially reproducible in BGB by single frame stepping, and that's not it.
I tried to reproduce this in Higan 093 (the latest publicly available version as of writing this) and this game has another problem, which is the implementation of the priority sprite bit, which makes Samus almost invisible for the first screen. I don't know if you've fixed this in the beta you're working on or if this happens to me because of different settings.
I cannot reproduce the reported problem in Higan 093, however. If you stand against a wall facing right, and press right+left, Samus' animation gets stuck in the turning state, which is consistent with BGB, and probably hardware if you could press left+right. But not when walking freely.
Maybe you should consider the possibility that this bug is due to something other than the joypad input, for example that the sprites are not getting updated properly in the rendering pipeline, or in the ROM, for whatever reason, and that the turning animation that is normally visible for two frames sticks. Try firing a shot and see if that animates normally while Samus is in this state.