05-03-2015, 08:56 PM
Here's what I came up with for Amplitude 
. Sorry for the delay.
Background:
In case anyone's wondering, here's an overview of how I rebuilt 2007excalibur2007's dynamic live memory discovery into a game-wide ELF hack.
I converted the original version of the float value 2007excalibur2007's found into its HEX representation (3F988B62), then searched for portions of it in the Amplitude demo's ELF file. No luck. That meant creating this hack wouldn't be very straightforward.
Using Cheat Engine, I found that the demo's menus didn't use the aforementioned HEX value, but it was used while in-game. Since that HEX value is always written to different memory addresses every time you go in-game, I thought up a way of making the addresses predictable. I adjusted PCSX2's slow motion mode to run at 1% speed, then pressed Tab+Shift to activate it just before clicking a menu item to go in-game. Immediately after clicking the menu item (while still in slow motion mode), I created a save state. That caused the game's processing timings to no longer be dependant on user input. In other words, upon loading that save state, the HEX value would now always get written to the exact same addresses, every time. Keep in mind that this save state is from a point in time prior to when Amplitude's game engine writes that HEX value into live memory. The save state would've been useless if the value was already in memory at the time of the state's creation.
So, what is there to gain by getting the game to always write that HEX value to the same addresses? It makes it possible to use PCSX2's built-in debugger! I tracked writes to one of the aforementioned addresses to determine which of the game's functions was writing the X field of view (FOV) into memory. From there I spent a long time trying to hack that function's hardcoded float values to no avail.
My last option turned out to be the most complex kind of hack. I injected custom MIPS code into the previously-mentioned function, right before it writes the X FOV value into memory. My hack just loads in a 0.75 float value, then multiplies it by what the game is about to write into memory. What gets written to memory is now the result of that calculation.
Hacks involving custom MIPS code can potentially be risky. Injecting code into the wrong place can totally break down a game. Why? Because you're overwriting the game's own logic or values with your own "extra" logic. If you accidentally overwrite something important, you run the risk of introducing unexpected glitches and/or game crashes. In Incognito's games, I've been lucky enough to find plenty of orphaned (unused) functions that I can safely place custom logic into. Unfortunately, Harmonix didn't leave any orphaned functions in Amplitude.
So... what now? I ended up searching for a "host0" string in Amplitude's ELF file and overwrote the logic that uses it with my custom logic. The logic I overwrote was probably only useful to Harmonix while developing the game. I doubt it ever runs in demo/retail versions.
Lastly, the full NTSC-U and PAL versions of this game use multiple ELF files... so I added E-type codes (Codemasters Project - Code Type E) to make the hacks activate only when they're supposed to. Same deal for the magazine demo too.
Pnaches:
What's covered:
What's missing:
Notes:
. Sorry for the delay.Background:
In case anyone's wondering, here's an overview of how I rebuilt 2007excalibur2007's dynamic live memory discovery into a game-wide ELF hack.
I converted the original version of the float value 2007excalibur2007's found into its HEX representation (3F988B62), then searched for portions of it in the Amplitude demo's ELF file. No luck. That meant creating this hack wouldn't be very straightforward.
Using Cheat Engine, I found that the demo's menus didn't use the aforementioned HEX value, but it was used while in-game. Since that HEX value is always written to different memory addresses every time you go in-game, I thought up a way of making the addresses predictable. I adjusted PCSX2's slow motion mode to run at 1% speed, then pressed Tab+Shift to activate it just before clicking a menu item to go in-game. Immediately after clicking the menu item (while still in slow motion mode), I created a save state. That caused the game's processing timings to no longer be dependant on user input. In other words, upon loading that save state, the HEX value would now always get written to the exact same addresses, every time. Keep in mind that this save state is from a point in time prior to when Amplitude's game engine writes that HEX value into live memory. The save state would've been useless if the value was already in memory at the time of the state's creation.
So, what is there to gain by getting the game to always write that HEX value to the same addresses? It makes it possible to use PCSX2's built-in debugger
! I tracked writes to one of the aforementioned addresses to determine which of the game's functions was writing the X field of view (FOV) into memory. From there I spent a long time trying to hack that function's hardcoded float values to no avail.My last option turned out to be the most complex kind of hack. I injected custom MIPS code into the previously-mentioned function, right before it writes the X FOV value into memory. My hack just loads in a 0.75 float value, then multiplies it by what the game is about to write into memory. What gets written to memory is now the result of that calculation.
Hacks involving custom MIPS code can potentially be risky. Injecting code into the wrong place can totally break down a game. Why? Because you're overwriting the game's own logic or values with your own "extra" logic. If you accidentally overwrite something important, you run the risk of introducing unexpected glitches and/or game crashes. In Incognito's games, I've been lucky enough to find plenty of orphaned (unused) functions that I can safely place custom logic into. Unfortunately, Harmonix didn't leave any orphaned functions in Amplitude.
So... what now? I ended up searching for a "host0" string in Amplitude's ELF file and overwrote the logic that uses it with my custom logic. The logic I overwrote was probably only useful to Harmonix while developing the game. I doubt it ever runs in demo/retail versions.
Lastly, the full NTSC-U and PAL versions of this game use multiple ELF files... so I added E-type codes (Codemasters Project - Code Type E) to make the hacks activate only when they're supposed to. Same deal for the magazine demo too.
Pnaches:
- Amplitude (NTSC-U) [SCUS-97258] [2F7B4DB8]
2F7B4DB8.pnach (Size: 1,02 KB / Downloads: 515)
- Amplitude (PAL-Unk) [SCES-51706] [F7DC0006]
F7DC0006.pnach (Size: 1,02 KB / Downloads: 460)
- KIOSK Demo Disc 2.9 (NTSC-U) [SCUS-97270] [7656425F]
Jampack Demo Disc - Summer 2003 [T-Rated] (NTSC-U) [SCUS-97280] [7656425F]
Jampack Demo Disc - Summer 2003 [M-Rated] (NTSC-U) [SCUS-97281] [7656425F]
Official U.S. PlayStation Magazine Demo Disc 067 (NTSC-U) [SCUS-97242] [7656425F]
Official U.S. PlayStation Magazine Demo Disc 104 (NTSC-U) [SCUS-97532] [7656425F]
7656425F.pnach (Size: 11,16 KB / Downloads: 463)
What's covered:
- Widescreen field of views have been setup for all in-game viewports. Indirectly impacts a few other things...
- HUDs are thinned out properly and center-aligned.
- Full-screen images (e.g. loading, logo, demo, etc... screens) are thinned out properly. I had mistaken them for FMVs in my other post.
- HUDs are thinned out properly and center-aligned.
What's missing:
- Avatars need to be widened in order to look "normal".
- Draw distance differences between 4:3 and 16:9 aspect ratios need to be looked into.
- HUDs should be repositioned to the far left/right of the viewport as needed.
- Training tutorial's top/bottom black bars need to be stretched.
- Credits screen's square box needs to be stretched.
- Widescreen hacks are still needed for the PS2 network configuration utility that comes with the full versions of this game. The utility is in a separate ELF file and doesn't appear to be based on Amplitude's game engine.
- FMVs need to be resized. Commented-out experimental FMV hacks are included in the pnaches of the full NTSC-U and PAL versions of the game (demo lacks FMVs). Enabling them resizes the FMVs' picture to a 4:3 aspect ratio, but it isn't center-aligned and lacks black side bars.
- Ports to various other demo versions are still needed:
- Amplitude [Demo] (NTSC-U) [SCUS-97262]
- Amplitude [Demo] (NTSC-U) [SCUS-97292]
- Amplitude P.O.D. [Demo] (NTSC-U) [SCUS-97869]
- PAL Amplitude demo(s)
- Amplitude [Demo] (NTSC-U) [SCUS-97262]
Notes:
- Draw distances seem to differ slightly between 4:3 and 16:9 aspect ratios. In the 1 player screenshots, a distant ground surface isn't rendered in widescreen. However, in the 4 player screenshots, only the widescreen shot contains glowing objects in the distance. So it seems to be a win/lose situation.
- Two variants of Amplitude's network configuration utility exist: "\NETGUI\NTGUICD.ELF" and "\NETGUI\NTGUIDVD.ELF". Launching the utility within the game crashes PCSX2. It's possible to use PCSX2's "Run ELF..." feature to directly launch the appropriate version of the utility, but the interface is practically unusable due to text positioning issues in the emu.
- It appears that all multi-game NTSC-U demo discs developed from February 2002 and onwards use a game CRC of "7656425F". That means there's possibly over a hundred (or more) demo discs out there that share the exact same CRC
...
- To anyone that may decide to rep this post, please don't forget 2007excalibur2007 too! Without his initial live memory find, these hacks would've never become a reality. Same goes for any other co-developed widescreen hacks.
- @Devina Feel free to include this post's version of 7656425F.pnach in the widescreen archive's "cheats_ws" folder. It covers Hitman 2 as well as the magazine demos of Amplitude/War of the Monsters. Conflicts won't occur.
![[Image: pNm13X9.gif]](https://i.imgur.com/pNm13X9.gif)
