1000:37b5 eb 00 JMP LAB_1000_37b7
ahh yes, jmp to the next instruction, I'm sure there's many reasons why you'd want to do this, and it's not just your compiler being dumb
@foone fan theory: JMP is slightly slower than NOP;NOP - so they’re using it for timing!
(i doubt it, but one can dream)
@domi well it is in the middle of palette programming, maybe EGA is slightly too slow?
@charlotte this game is running on an original 8086, there is no speculative execution here
@wolf480pl a code cave is some space in the memory or binary that you can safely stuff new code into. You mainly need them when patching, because you gotta put your new code somewhere
I can't recall (or easily look up) how I'd do a dynamic far call on segmented 16bit x86, so I'm just pushing the target CS:IP and doing a RETF.
is it wrong? yes. does it work? also yes
Evil hacking accomplished. I'll reveal what this was later when the video comes out.
I had to inject approximately 16 bytes of jump code, then adjust the EXE to be bigger for a new code cave, where I stuck in a modified version of the original routine.
And the embargo is lifted!
I hacked id Software's Rescue Rover for an Ancient DOS Games video:
https://www.youtube.com/watch?v=YdRN2SUUAEg
I made a patch to make the game less flashy for the video. It's trying to color-cycle fire at (I think) 60hz, which probably looked fine on a CRT, but on an LCD/OLED that can actually respond that fast, it turns into a frightening flashy mess, which can fill much of the screen at times
The patch is here:
https://github.com/foone/rescue-rover-unflash
@foone this is so funny, I was speaking to a friend + their colleague who run a games course about Rescue Rover. Because {colleague} is building a game somewhat inspired by a more complex game in the family.