Genesis game crashes exclusively within libretro core emulation

[ner00]

I recently patched a Genesis ROM which alters the movement of the player, a QoL improvement. The patch seems to work completely fine in every emulator (and hardware) except for Genesis libretro cores. While ROM hacking and patching can be considered inherently unstable, I am still curious why this particular patch only seems to have issues with libretro cores, like Genesis Plus GX, but not their standalone counterparts.

Before going further, I have tested the patched ROM successfully in the following standalone emulators: Genesis Plus GX 1.6, Bizhawk 2.6.2, Gens r7, Kega Fusion 3.64. I have tested and confirmed the issue happening in latest versions of these libretro (RA) cores: Genesis Plus GX, PicoDrive, BlastEm.

To be more precise, the actual game is Landstalker (USA), ROM crc32 FBBB5B97, and the applied patch is the following: https://www.romhacking.net/hacks/5495/

Landstalker is an isometric game, it originally requires the player to press a diagonal direction on the D-Pad to set and toggle the horizontal/vertical axis directions in which the character will move along; if you press diagonally up+right, or the opposite, down+left then it will set D-up to move diagonally up, D-right to also move diagonally up, D-down to move diagonally down, D-left to also move diagonally down. What the patch does, in practice, is to enforce vertical and horizontal inputs directly into their respective directions for the character in relation to the isometric world plane without the explicit usage of diagonals.

In order to crash the (patched) game on any Genesis libretro core I have to simply do the following:

• Boot and start the game
• (assuming new game) wait for the intro to play out (or fast-forward it)
• Once the intro is done and you have control to move the character, quickly press: up, down, up, down.
• The game should have glitched and frozen

For reference, here's a screenshot of the glitch:

This is not actually an issue exclusive of this particular emulator since its implementation in standalones works perfectly fine, as is the case with Bizhawk. Also, the fact that it works fine in every standalone emulator but causes issue exclusively within libretro cores points towards an influence external to the core. Unfortunately I do not have the technical expertise to speculate on why that might be the case, let alone debug it or provide more helpful insight on the matter.

This isolated case is nothing too serious, but I assume that it may encompass other minor misbehaviors that may have other vectors negatively impact this and/or other cores running in libretro. I'll be more than happy to close/move this issue to another repo if deemd more appropriate - at this point I just don't know where to place the issue beside the repo of the most popular Genesis emulator on the block.

Reference in https://github.com/ekeeke/Genesis-Plus-GX/issues/370

[negativeExponent]

the simple fix here is to disable simultaneous button presses of dpad. meaning up+down should not be allowed, nor left+right. this causes the glitch you mentioned. Pressing them fast enough (quickly in your case) might have registered such opposite dpad presses which would have not been possible on a real controller.

[ner00]

Makes sense since I was using a keyboard at the time of testing, on a controller that would have been physically impossible. Since standalone versions of the emulators don't have this behavior even with a keyboard, I'm assuming the simultaneous presses of opposite directions is allowed by RetroArch.

Which begs the question, is the patch fix supposed to be at the backend level (RA input) or core level?

In terms of directional buttons, I think there is no single instance where you should, would, or could simultaneously press opposite directions.

[negativeExponent]

for the mean time, just avoid pressing such combinations until someone add them to cores affected, or better, the option will be added to the frontend (where i think they should belong)

[ner00]

Sure, this was actually the first time anything like this ever happened. In part I blame the patch, but the fact that I cannot crash the game under the same circumstances on the real hardware nor standalone emulators tells me that the back-end of RetroArch should be sanitizing the input to prevent this issue in any core.

Thanks for the helpful comments though, I hope developers pick on this eventually, if not I might address it in the main repo to bring some attention to it. Doesn't seem like a serious or widespread issue though, which is a good thing.

[ekeeke]

This should rather be reported to the patch developers and fixed in the patch itself, as it clearly is a bug in that patch (does not occur with original game).

According to some Sega Tech Bulletin (see attached file), it's actually possible for an used controller to report both UP and DOWN buttons as pressed and games should be robust to this edge case so the fact that the libretro port input backend allows that is correct. Similarely, for the core, it would be inaccurate to prevent both pins to be asserted when a control pad is connected, as it depends on the physical controller behavior, which is handled by the frontend.

[ner00]

Interesting, didn't know this. I don't expect the patch will be fixed, but now I know that libretro isn't the actual problem, as it allows for a real case scenario.

I assume that the original game had a control scheme logic that caught or prevented unexpected behaviour, like receiving two directions at the same time. Anyway, thanks for clarifying.