SUBSIM Radio Room Forums - View Single Post - Realism- and gameplay-related hardcode fixes for SH3.EXE

h.sie · 09-13-10, 02:09 AM

@Makman: Thanks, mate.

In theory, all is possible now.

But in reality, I have to restrict on "easy-to-fix-bugs" like the repair times which could be fixed using a simple floating-point division (besides about 20 other assembler commands to shift, save and restore CPU registers).

Without the SDK, you see a huge amount (some gigabytes) of bytes when you look at the dynamically allocated memory of sh3.exe without knowing the meaning of that all. no names, no labels, nothing. Only Hex values from 0 to F.

4F09 3B44 1200 FF0A 4F09 6571 8237 ABDD 6571 8237 ABDD 3B44 1200
FF0A 6571 8237 ABDD 1200 FF0A 4F09 6571 8237 ABDD 6571 8237 ABDD
3B44 1200 FF0A 6571 8237 ABDD 4F09 3B44 1200 FF0A 4F09 6571 8237
ABDD 6571 8237 ABDD 3B44 1200 FF0A 6571 8237 ABDD 1200 FF0A 4F09
6571 8237 ABDD 6571 8237 ABDD 3B44 1200 FF0A 6571 8237 ABDD.

(shown are about 200 bytes. sh3 has about 1000000000 bytes in memory)

So first of all you have to identify and search for the variables you need. Therefore you have to make some assumptions. If these assumptions are wrong, you'll fail. E.g. trying to fix the repair times, I failed for weeks because, I always thought there were some Hitpoint-counter coded in Integer format responsible for damage and repair times. But short before giving up, I made the assumption, that the damage is coded in "float" format and is 0,0 if no damage and 1,0 if destroyed. And I furtheron hoped that they decrease during repairs and keep constant when silent running and so on. knowing this, "only" some tenthousands of bytes, which behave this way, remain so you have to make your search better, and so on and on and on until only one variable remains, which hopefully is the variable you searched for. that search and identification process can take much time, days, weeks, sometimes without any success, because maybe your starting assumption was wrong.

after identifying your variable which contains the damage, you have to search for the assembler routines which modify the damage. these routines have to be fixed accordingly. it is very hard (for me) to understand compiler-generated assembler code without any comments.

Long story short: Easy fixes can maybe be done in a hard job. But complex things like AI, wolfpacks and other additions are impossible (for me), because too many variables are involved and interdependencies not understood.

sorry for damping down your euphoria ("NEW AGE" and so on).
but even if I fail to fix other bugs in the future,
these new repair times combined with the stock flooding behaviour,
make this game very much playable for me now.
and I really look forward to start to play a career for the first time.

h.sie

09-13-10, 02:09 AM	#79
h.sie Admiral Join Date: Jul 2008 Posts: 2,192 Downloads: 131 Uploads: 0	@Makman: Thanks, mate. In theory, all is possible now. But in reality, I have to restrict on "easy-to-fix-bugs" like the repair times which could be fixed using a simple floating-point division (besides about 20 other assembler commands to shift, save and restore CPU registers). Without the SDK, you see a huge amount (some gigabytes) of bytes when you look at the dynamically allocated memory of sh3.exe without knowing the meaning of that all. no names, no labels, nothing. Only Hex values from 0 to F. 4F09 3B44 1200 FF0A 4F09 6571 8237 ABDD 6571 8237 ABDD 3B44 1200 FF0A 6571 8237 ABDD 1200 FF0A 4F09 6571 8237 ABDD 6571 8237 ABDD 3B44 1200 FF0A 6571 8237 ABDD 4F09 3B44 1200 FF0A 4F09 6571 8237 ABDD 6571 8237 ABDD 3B44 1200 FF0A 6571 8237 ABDD 1200 FF0A 4F09 6571 8237 ABDD 6571 8237 ABDD 3B44 1200 FF0A 6571 8237 ABDD. (shown are about 200 bytes. sh3 has about 1000000000 bytes in memory) So first of all you have to identify and search for the variables you need. Therefore you have to make some assumptions. If these assumptions are wrong, you'll fail. E.g. trying to fix the repair times, I failed for weeks because, I always thought there were some Hitpoint-counter coded in Integer format responsible for damage and repair times. But short before giving up, I made the assumption, that the damage is coded in "float" format and is 0,0 if no damage and 1,0 if destroyed. And I furtheron hoped that they decrease during repairs and keep constant when silent running and so on. knowing this, "only" some tenthousands of bytes, which behave this way, remain so you have to make your search better, and so on and on and on until only one variable remains, which hopefully is the variable you searched for. that search and identification process can take much time, days, weeks, sometimes without any success, because maybe your starting assumption was wrong. after identifying your variable which contains the damage, you have to search for the assembler routines which modify the damage. these routines have to be fixed accordingly. it is very hard (for me) to understand compiler-generated assembler code without any comments. Long story short: Easy fixes can maybe be done in a hard job. But complex things like AI, wolfpacks and other additions are impossible (for me), because too many variables are involved and interdependencies not understood. sorry for damping down your euphoria ("NEW AGE" and so on). but even if I fail to fix other bugs in the future, these new repair times combined with the stock flooding behaviour, make this game very much playable for me now. and I really look forward to start to play a career for the first time. h.sie __________________ My Mediafire page: http://www.mediafire.com/hsie Last edited by h.sie; 09-13-10 at 09:25 AM.