Open cher-nov opened 3 years ago
I don't think this is appropriate for the joystick patch. I intended to keep games with joystick support playable, just without the joystick support. It doesn't produce any error messages, it just reports that there are no joysticks connected. The scheduler patch replaces one of the joystick functions, which is why the joystick patch is mandatory if the scheduler patch is desired. I suppose the DirectPlay point is more valid though, since that is probably going to access violate or something. I'll look into that at some point.
I don't think this is appropriate for the joystick patch. I intended to keep games with joystick support playable, just without the joystick support. It doesn't produce any error messages, it just reports that there are no joysticks connected.
The problem is that joystick patch alone just makes what you've described which is ok. But scheduler patch also make these functions *broken*, which means that calls to them most likely will lead to segfault. So this makes sense to delete them from the function table in order to properly support e.g. cases with external code (plugins etc).
The scheduler patch replaces one of the joystick functions, which is why the joystick patch is mandatory if the scheduler patch is desired.
Maybe force that option if scheduler patch was desired? Because now ReadMe states that it's possible to apply scheduler patch *without* the joystick one, "at your own risk".
It would be nice to have option to remove names of broken functions from the lookup table to make game literally uncompilable if it uses them. This will help not only to debug them but also to show much more production-ready error messages, especially in case of dynamic code execution (
execute_string() etc
).For example, with DirectPlay patch it will remove
mplay_*
functions, and with scheduler patch it will remove functions that depend on the changed DLL import. Maybe it also should removejoystick_*
functions as well with joystick patch.Please note that for Delphi strings it's not enough to set first string byte to
'\0'
, but the Pascal string header should be edited too. Or, if they're being added at run-time on initialization, we could just NOP these calls.