Emulator Issues #4291
closed
Do not truncate hex value in game patch dialog and store long hex values correctly
0%
Description
What steps will reproduce the problem?
- Right click the game and choose properties.
- Select the Patches tab.
- Add a patch and for the value, enter a long hex value (such as an ASM patch).
- A value > 4 bytes or 8 characters is either truncated or turned into 0x00000000 if it's too long to be stored.
What is the expected output? What do you see instead?
The value entered is expected to not be truncated or removed (see above).
Dolphin version with the problem? Other Dolphin version without the
problem?
All revisions. This was tested on the latest revision, which is 7369 as of now.
32-bit or 64-bit and any other build parameters?
64 bit with no parameters passed to either cmake or make.
OS version and versions of tools/libraries used?
OS: Arch Linux
Gcc: 4.5.2-6
Cmake: 2.8.4-1
Make: 3.81-5
Please provide any additional information below.
This was tested using hex values from the memory patch portion of "Another Mario World's" riivolution xml.
A value of 616E6F746865722E is truncated to the last 4 bytes/8 characters and a value of <look at attachment> is reverted back to 0x00000000. I'm assuming that the int/long/long long used in the source can't store such a large variable.
I don't know too much about C++, but from a quick look at the sources, it seems like the problem lies in these 2 source files:
Source/Core/DolphinWX/Src/PatchAddEdit.cpp (for the truncation maybe?)
Source/Core/Core/Src/PatchEngine.cpp (inability to store super long hex value?)
It doesn't seem like too hard of a problem to fix. Let me know if you need more information.
Updated by cxl9261995 over 13 years ago
By the way, using byte, word, and dword all yield the same results.
Updated by sl1nk3.s over 13 years ago
Unfortunately the patch engine doesn't support qword values (8 bytes)
This is indeed a bug/issue and it should show a warning there when someone enters an invalid/overflowing value.
For now the only thing you can do is split your qword into two dword and adjust the offset accordingly.
Updated by cxl9261995 over 13 years ago
Thanks for the information. I assume that the long hex value will have to be split into a ton of dword values then.
Hopefully this will be fixed soon.
Updated by bztdlinux over 13 years ago
"A ton of dword values" being two for a qword, yes.
Updated by Anonymous over 13 years ago
uhmmm yes, if you are planning on hacking in new ppc, you might as well hardcode it in dolphin for your purposes, or add better support to the patch engine. Obviously adding qword support won't matter much if you have a whole function to patch.
Perhaps just accept word or byte-aligned values, and automatically generate all the entries required (ie a 32byte patch would automatically create 4 dword entries).
Updated by Anonymous over 13 years ago
- Status changed from New to Fixed
This issue was closed by revision r7672.