PINE: handle more messages

[Tomasak]

Description of Changes

Updated PINE messages to return more information

Rationale behind Changes

There are only a few of data available, providing more gives more use cases.

Suggested Testing Steps

[stenzek]

You'll need to provide a concrete and reasonable explanation as to why these fields should be added. A few of them are already accessible, others make no sense, like window dimensions, or the ELF entry point.

[Tomasak]

MsgCurrentCRC - allows to precisely check executable version

MsgElfEntryPoint - allows making pattern searches if start of memory is known

MsgWindowSizeX/MsgWindowSizeY/MsgAspectRatioSetting - required to make dynamically adjusting widescreen fixes

[stenzek]

So why not use pnach.... Turning pine into a patch system when we already have one is silly.

As I said in the other PR, if you need dynamicness, a scripting system is the proper way to do it.

[Tomasak]

Before a scripting system (no idea how it would be better) would be implemented, this would be plenty enough to make proper widescreen fixes for games as right now PCSX2 widescreen fixes in most cases only fix 3D aspect ratio without touching 2D elements at all - by getting aspect ratio values dynamically from PCSX2 it's possible to write widescreen fixes that react to eg. resizing window.

Besides, a scripting system can't really be made for code edits. Something like PSP plugins needs to be implemented instead (ideally load some extra .elf module and append it to VM?), with a scripting system you would need to expose a lot of MIPS calls to do anything meaningful that isnt just read and write memory.

[stenzek]

And how does modifying pine allow for any of this? Having a separate external program for every game you want to patch is ridiculous.

[TheLastRar]

And how does modifying pine allow for any of this?

I'm curious as well. What is the hypothetical workflow going to be?
Are you planning on injecting code into a running game and then feeding any data it needs from the outside word?
Or are you planning on doing the bulk of the logic in the external program?

Is this primarily for widescreen fixes for varying aspect ratios? or do you intend other use cases?

As for getting information about the current elf

MsgCurrentCRC

Maybe MsgExecutableUUID is a better name?, as it is more inline with MsgUUID

MsgUUID currently returns the disc CRC (in PCSX2), with the version being identified via MsgGameVersion
However, some games contain multiple executables that may need to be worked on differently.

I decided to check what RPCSC3 does, they return the executable hash for MsgUUID so a MsgCurrentCRC/MsgExecutableUUID would be redundant for them.

Edit: PINE states that MsgUUID is a "Request the UUID of the game currently running." so I think getting the UUID of the current executable could still be a reasonable addition

Whatever gets added will need to also be added to the pine spec here https://github.com/GovanifY/pine

[stenzek]

Closing, since there is clearly no interest in doing this properly.