Decided maybe my project stuff would be better off outside of the "last thing you thought" thread.

If others have their own things they did that they are proud of/want to share/teach us about, feel free to post your own stuff, too!

-----------------------------
I figured out how to patch the English language translation of Touhou Project 4 (Lotus Land Story) to fix a crash/out of memory bug.

Most of the work had [rec98.nmlgc.net] already been done by people cleverer/more dedicated than I am, but I don't have any assemblers/compilers installed, and didn't want to try to figure out the stupid Windows-specific build system for the ReC98 project's decompilation of the game just to build my own version that changes exactly two bytes.

So instead, I took note of the amount of memory that the game tries to reserve without the patch (as explained in the link above):


The patch replaces 320000 with 324000.

So what we have to do in the MAIN.EXE binary file is to find where these numbers are being set and change them.

First, to find the numbers:
Notice the >> 4 at the ends of the lines. The '>>' sign next to it means "shift right" - this is a mathematical operation where the ones and zeroes that make the numbers 320000 and 324000 get moved rightwards by four positions. In all likelihood, a compiler or assembler will perform that calculation ahead of time and store the result of the calculation in the program. Touhou does do this. So we don't actually want to find the hexadecimal code for 320,000 in the EXE file - we actually want that number bit shifted four spots to the right.

320,000 in binary is:
1001110001000000000
so basically we lop off the bottom four digits and get:
100111000100000
which is 20,000 (twenty thousand). In hexadecimal, that's 4E20.

Now there's another gotcha; because Intel CPU's were designed by mongoloids retards very special engineers, if they're given a number that's more than eight bits, they make the last byte they read in the 'most significant.' Let me show you what I mean. Since two hex characters form one byte, this is easily illustrated in hexadecimal with four hex digits (0 through F, where 0 is 0, 9 is 9, A is 10, and F is 15).
On a system architecture that isn't brain-damaged, you'd expect for '00 01' to be the number 'one' (1).
But on retarded platforms like Intel PC's, numbers are stored in "little endian" which means they are stored ass backwards. So on a little endian system, '00 01' in hexadecimal is 64 in decimal, rather than 1.
To get a 1 on a little endian (retarded) platform, you need to put the bytes in the order '01 00' instead.

So, since we're trying to replace the number 20,000 (which is '4E20' in hexadecimal), but are on a system architected by inept fools, we need to search for '204E' in hex instead. In my 'GAME.EXE,' this shows up in three places. One of them is in a string of English text, which we can safely ignore. Of the remaining two, when I look at the hexadecimal in a hex editor, one of the locations looks strangely like a data table, with everything nicely lined up in rows.
My text cursor is highlighting the bytes in question.

I don't think this is part of program code, necessarily; it could be some other kind of data. Notice how every set of four bytes (32 bits) starts with '6E.' That's not typical in program code, where 'operation codes' (CPU instructions) are much more varied.

So, based on instinct, that leaves one other possible location.


Now, doing the same calculation, we need to figure out the hex value of '324000 >> 4'. To skip the clutter and keep this a little less confusing, I'll just cut to the chase and say that it's '4F1A,' or, in wrong-endian, '1A4F.' So we just replace '20 4E' with '1A 4F' and save.

I tested it out on my PC-98, and it works! The game no longer crashes.

[postimg.cc] (IMG:[i.postimg.cc] https://i.postimg.cc/T17DmmZb/mpv-shot0483-med.png)
[postimg.cc] (IMG:[i.postimg.cc] https://i.postimg.cc/VNQbjzHK/mpv-shot0694-med.png)

This post has been edited by dragontamer8740: Jan 1 2024, 08:23