Attempts to patch out latency from Xbox 360 SDOJ

[meepowl]

Hi,

I've recently asked this question on the Cave STG forum but without much success. I hope it's OK to also ask it here:

Is anyone aware of any attempts to patch out some of the latency from the Xbox 360 port of SDOJ? I can't find evidence that anyone has and I've looked pretty thoroughly but thought it worth checking, especially as there's been a lot of discussion of the issue here.

Thanks.

[emphatic]

Running it in 480p improves performance (at least the slowdowns) greatly. Perhaps it affects input latency as well?

[StrzxgvNuvWvfld]

Has there ever been on instance of anyone patching out latency on a modern release? I could see it might sometimes be possible on an older game that was written in a low-level language, but it seems a stretch for a port to a modern system. Though I may be missing something...

[PC Engine Fan X!]

Has there ever been on instance of anyone patching out latency on a modern release? I could see it might sometimes be possible on an older game that was written in a low-level language, but it seems a stretch for a port to a modern system. Though I may be missing something...

Not to mention the already well-known seven to eight frames of lag associated with the Nintendo Switch gaming platform, could Live Wire address that particular issue when running/playing the Xbox 360 port of DoDonpachi SaiDaiOuJou? I've yet to see if the Switch port of DDP-SDOJ will finally go on sale below it's original MSRP of $34.99 -- time will tell if that's the case here though.

PC Engine Fan X! ^_~

[meepowl]

Has there ever been on instance of anyone patching out latency on a modern release? I could see it might sometimes be possible on an older game that was written in a low-level language, but it seems a stretch for a port to a modern system. Though I may be missing something...

Whether one is easier than the other is an interesting question. Ghidra can disassemble Motorola 68000 (DoDonPachi) and SuperH (SDOJ) binaries out of the box, so I assume at least as well as it can the Xbox 360 flavour of PPC64 (which need a plugin). A lot of this comes down to documentation, which is pretty good for the Xbox 360 and someone has documented a process for patching SDOJ to display hitboxes (https://epozzobon.it/re/sdoj/), though I can't get the method to work. There are other ways of patching the binary though, including using Ghidra. If I can find one that works or work out where I'm going wrong with building the hitbox patch I'll start experimenting.

[Firehawke]

On "modern" platforms (those that have a full OS underneath it, so 360, PS3, and newer) you're going to get enforced triple buffering and a rendering pipeline that's designed for slower-paced games. Outside of emulation, where you can force the game to run in conditions it wasn't originally in (e.g. progressive scan for Wii Mega Man 9/10), you're not likely to see any improvement patches simply because the OS is going to be a major limiting factor.

[davyK]

Has there ever been on instance of anyone patching out latency on a modern release? I could see it might sometimes be possible on an older game that was written in a low-level language, but it seems a stretch for a port to a modern system. Though I may be missing something...

Not to mention the already well-known seven to eight frames of lag associated with the Nintendo Switch gaming platform, could Live Wire address that particular issue when running/playing the Xbox 360 port of DoDonpachi SaiDaiOuJou? I've yet to see if the Switch port of DDP-SDOJ will finally go on sale below it's original MSRP of $34.99 -- time will tell if that's the case here though.

PC Engine Fan X! ^_~

I think that's using the worst example of Switch ports. The M2 ports have lower lag - typically one frame more than that achieved on PS4/5.

[meepowl]

On "modern" platforms (those that have a full OS underneath it, so 360, PS3, and newer) you're going to get enforced triple buffering and a rendering pipeline that's designed for slower-paced games. Outside of emulation, where you can force the game to run in conditions it wasn't originally in (e.g. progressive scan for Wii Mega Man 9/10), you're not likely to see any improvement patches simply because the OS is going to be a major limiting factor.

I think this is absolutely right but I'm a bit more optimistic. Between the reverse engineering notes (linked in my original post) and studying the executables in Ghidra, I have a memory location (0x888791f8) which always contains a pointer to the Direct3D device. This is created in default.xex (handles the menus/frontend) and the memory location is somehow passed to CA022100.bin (the arcade version executable) and a pointer placed at that address.

There doesn't seem to be a way of changing the buffering or v-sync settings after the Direct3D device is instantiated. Right now, I can't work out where this happens in default.xex but if I can then I can change the settings. I *think* for triple buffering this really is just an on/off switch and - as you say - the OS handles everything from there. V-sync is a little harder but I think I've found the code in CA022100.bin (function starting at 0x880331F0) which handles the frame timings and with a bit of trial and error might be able to stop it holding up the frames.

[bobrocks95]

I remember the Lego games on 360 had to option to disable Vsync for a higher, unlocked framerate with tearing. So it's definitely configurable inside software.

I do think that's the best you'll be able to do to improve lag without some extremely in-depth reverse engineering though. Certainly doable given what fan translations and decompilation work have been done for that gen, but a whole different ballgame.