Cheats revamp (turing completeness, more PC-like)

[mirh]

trying not to clutter #1918
EDIT: this was originally just about Automatic Aspect Ratio, but then, you know, ideas expand

---

So.. @rz5 kindly pointed me out to this code, where I finally get why frame (window) becomes magically different than "rendered resolution" (video mode).

And after some other discussion on irc, I also get ws hacks are just "pre-squashing" the image, so that when subsequently stretched the final result will look cool.
Which I guess is some nice way to workaround the fixed resolution (assuming tinkering video mode itself isn't viable), and also why we cannot do away with manual AR settings.

So... can't we just like add a "Targeted Aspect Ratio" value to ws hacks?
I mean, I imagine pcsx2 has no way to know what's the meaning of specific patches, so coder should provide it.

Then, if all ws_hacks we ship are supposed to just be 16:9, we could just do as well if (enable_WS_hacks && enable_cheats && game_has_WS_hack_available) then aspect_ratio = 16/9; (®rz5)
But.. Then this would a little screw up life for some people.

....
In other news, little OT even for this issue, once you pinpoint the UI/aspect "addresses", is writing a ws hack for ps2 all that much different from pc?
Because it starts to feel pretty lame in 2017 to just hardcode 16:9, and screw everybody else.

[MrCK1]

If I'm understanding this correctly, all this is doing is switching the aspect ratio automatically to 16:9 when as WS patch is applied instead of having the user do it?

It seems unecessary considering it would require an overhaul of the entire database.

[FlatOutPS2]

So.. @rz5 kindly pointed me out to this code

Didn't consider reading the PR code then...

if (enable_WS_hacks && enable_cheats && game_has_WS_hack_available) then aspect_ratio = 16/9; (®rz5)

enable_cheats != widescreen patches

The only workable way of implementing an automated system is to only automatically apply 16:9 aspect ratio to patches from the cheats_ws.zip archive(not the cheats_ws folder), and add an option to disable this on the GSWindow tab(or a combo box that also allows applying it to all WS patches if desired).

In other news, little OT even for this issue, once you pinpoint the UI/aspect "addresses", is writing a ws hack for ps2 all that much different from pc?
Because it starts to feel pretty lame in 2017 to just hardcode 16:9, bye bye everybody else.

It depends on the game. In PC games it's usually a much more obvious value to edit, it hardly ever involves modifying ASM code, and there's less of a risk of rendering issues.

[avih]

If I'm understanding this correctly, all this is doing is switching the aspect ratio automatically to 16:9 when as WS patch is applied instead of having the user do it?

That's what I understood too.

it would require an overhaul of the entire database

I don't think it would, or at least it would depend on the implementation. For instance, everything at at the "built in" cheats_ws.zip is always 16:9, so it's fair to use this fixed AR if a patch was loaded from it. This would cover the vast majority of use cases for anyone who just uses the release or otherwise doesn't add more custom ws patches.

As for user patches at the cheats_ws folder, it's also fair to assume that if there's no AR specified at the patch, then 16:9 is assumed, and use that.

However, there is indeed an issue of how to specify an AR at the ws patch. It's a regular pnach file, so extending its format to include directives to PCSX2 would be a bit weird. So not sure about that.

Also, even if we only change it for patches in cheats_ws.zip, then there's still the issue of whether or not, and if so when, do we restore the AR to the one the user had before we changed it. And mind that it could span several invocations of PCSX2 if the user always runs games with built in ws patches...

[FlatOutPS2]

Also, even if we only change it for patches in cheats_ws.zip, then there's still the issue of whether or not, and if so when, do we restore the AR to the one the user had before we changed it. And mind that it could span several invocations of PCSX2 if the user always runs games with built in ws patches...

There's no reason to affect the user selected AR at all.

[avih]

There's no reason to affect the user selected AR at all.

So you're saying that if a patch was loaded from cheats_ws.zip then the user cannot change the AR manually?

[FlatOutPS2]

So you're saying that if a patch was loaded from cheats_ws.zip then the user cannot change the AR manually?

No. I'm saying there's no need to change the aspect ratio that has been selected in the UI. An automatic aspect ratio for WS patches should override(ignore) the UI selection, not change it.

It will check if it needs to override(if WS patches enabled and if there a WS patch for this game in the archive) on every (re)boot.

[avih]

An automatic aspect ratio for WS patches should override(ignore) the UI selection, not change it.

So if the UI is ignored, how can the user change it?

Or do you mean the AR UI can be either explicit or automatic, and if automatic then 16:9 is selected if a ws patch is loaded? If yes, what do we do in automatic mode if we don't load a ws patch?

[FlatOutPS2]

So if the UI is ignored, how can the user change it?

An automatic WS patch aspect ratio is only applied once on boot, any subsequent user changes won't get ignored. ;)

Or do you mean the AR UI can be either explicit or automatic, and if automatic then 16:9 is selected if a ws patch is loaded? If yes, what do we do in automatic mode if we don't load a ws patch?

No. It will always use the UI selection if no patch is found.

[avih]

An automatic WS patch aspect ratio is only applied once on boot

That's a reasonable behavior IMO, so we can probably say the behavior part is covered.

Not sure how its implementation will work though, because I think the AR is used more than just on boot. If so, we'll need to keep track of it somehow, such that when the time comes to use the AR, we'll need to apply either the automatic one if it was booted with a ws patch and the user hasn't changed it since, or the one stored at the config if the user did change it since boot.

[FlatOutPS2]

Actually, the WS patch aspect ratio will also be applied when "Enable Widescreen Patches" is enabled while playing(still only applied once so any subsequent user changes won't get ignored).

There is no change on disabling it.

[mirh]

The only workable way of implementing an automated system is to only automatically apply 16:9 aspect ratio to patches from the cheats_ws.zip archive

In the file of patches themselves, sure.

and add an option to disable this on the GSWindow tab

And why anybody in their even insane mind would not want to use 16:9 aspect ratio.. With a 16:9 patch?

In PC games it's usually a much more obvious value to edit, it hardly ever involves modifying ASM code

Mhhhh, I'm not sure you checked the link I had put there.
If the only difficulty would be just having to work with asm then, I'm really starting to feel about right on the possibility of "universal hacks".
EDIT: here we are

However, there is indeed an issue of how to specify an AR at the ws patch. It's a regular pnach file, so extending its format to include directives to PCSX2 would be a bit weird.

Uh, I hadn't thought about this.
I see the format is already quite extensive though. Would it be possible to make it also write the used/hacked AR somewhere else in pcsx2 memory (where this can interpret it), if I can explain?

Or to even solve the aforementioned "universal problem", could the patches be written with "variables" and/or some sort of math? Making possible for pcsx2 to read them, replace X with its current height/width/AR/whatever and profit?

trivia: I wanted to know what pnach means.. I just found out the loading mechanism was implemented between versions 0.4.1 and 0.5

There's no reason to affect the user selected AR at all.

My aim would be to drop that monstrosity eventually.

[FlatOutPS2]

In the file of patches themselves, sure.

And why anybody in their even insane mind would not want to use 16:9 aspect ratio.. With a 16:9 patch?

My aim would be to drop that monstrosity eventually.

PLEASE START READING THINGS PROPERLY. GET IT IN YOUR HEAD THERE IS NO FULL AUTOMATIC WIDESCREEN DETECTION !!

Mhhhh, I'm not sure you checked the link I had put there.
If the only difficulty would be just having to work with asm then, I'm really starting to feel about right on the possibility of "universal hacks"

No, I'm just sure you don't know how to read.

[mirh]

GET IT IN YOUR HEAD THERE IS NO FULL AUTOMATIC WIDESCREEN DETECTION

And there is where I'm looking forward to?
Video mode + this for hacks.

Or is there any other way for "frame" to be unrepresentative of "rendering" once you take auto-zoom away?

[mirh]

So.. @FlatOutPS2 is MIA, could somebody reopen this?

[refractionpcsx2]

I'll reopen this. Thinking logically after FlatOut's outburst, I don't think it's inconceivable to have it auto switch to 16:9 if a widescreen patch is detected.

[rz5]

Forgive me for not doing my homework but after reading Dolphin's progress report, I know they have an anamorphic widescreen heuristic (https://dolphin-emu.org/blog/2017/05/02/dolphin-progress-report-april-2017/).

It was @ligfx who was responsible for reworking said heuristic, so maybe we can pick his brain.

To me it's straightforward: for now, add an "Auto" AR option. At the moment all it would do is alter AR to 16:9 if cheats are on, WS hacks are on and a WS hack is available for the current game's CRC.
Then, in the future, add more complex behavior to that setting, if at all possible.

[mirh]

I'm not sure on when, ever, doing comparisons between two different consoles revealed to be smart..
Indeed, I'm not sure they need all that registers sorcery plus auto-zoom on wii (did I understand the aforementioned passage between rendering and "frame" right btw?)

Anyway, yes, I see and I know current cheat_ws.zip is actually 16:9 only (anybody that can double-confirm this?), thankfully I'd add.
But I have this feeling that once your [not wrong, absolutely] idea is brought in, we'll call it a day and fuck 'best™ ideas'?
This is why I had opened a specific issue to extensively reason about it.

Now, where did pnach format even came from for the records?

[refractionpcsx2]

Pnach is named after nachbrenner, an old team member who made patches in the beginning, meaning "patch nachbrenner", shortened to Pnach :)

[mirh]

Ooohh

...

Seems like it's not such a difficult format to extend then (should one whatever decide).

[mirh]

Ok, so.. I talked with experts™
And, for as much adding a couple of new patchfunctions for the little idea I had in mind shouldn't be hard, I think like we'd only be straining a doomed system, especially when ideal code is this complex

https://github.com/TheOfficialFloW/GTA_Remastered/blob/master/main.c
https://github.com/ThirteenAG/WidescreenFixesPack/blob/master/source/TonyHawksAmericanWasteland.WidescreenFix/dllmain.cpp

To retain a similar degree of "developer freedom", I guess we'd really need some scripting capability of sort.
Something like this for example.

Yes, I see how this feature request difficulty escalated quickly, but still.
And please, no "but what about older patches" comments, converting the very basic ones we have at the moment should be a cakewalk to just any whatever format we'll adopt.

EDIT

[mirh]

I wonder if stuff like CRC hacks (latest ssakash gave me the epiphany) couldn't be [one very far day of course] moved to this system?

[mirh]

^ Or we could put to use the dynacrchack thing @avih suggested.
I'm astonished I had forget about that after just 2 weeks.

It would feel kind of polluted though to ship, say, thousands of dlls (with lots of redundant initialization stuff nonetheless)

Ok, you'd ship C source code. Really not bad at all then (almost like C was a script language, lol)
Highly compressible and easily workable (and almost everyone knows it).

And in this case [of this thread] I think we shouldn't have any of those gsdx-CRC hacks concerns.

Though, put that aside, C does feel quite overpower - especially for the dumbest "patch=1,EE,00000000,word,00000000" hacks.

[mirh]

@gocha @DocSkellington @pocokhc
Do you think lua could seamlessly fit "mainline" pcsx2 too?
Is there also any impediment to implement complexity (even outside of "inputs", contrarily to I'd guess your use case) like this?

[gocha]

@mirh I don't understand the context of the topic and the exact meaning of "seamless" , however, in my opinion "yes". Good lua implementation won't make the core pcsx2 source code very messy, I guess.

For the time being, I have rebased my lua code to the official master branch. My version has only the very basic part of the Lua engine, though. You can download the Windows binary from the appveyor badge, if you interested.

The WS hack code is searching a PS2 code block from memory and installing a hook there? Then doing some memory read/write operation? There are some well-known emulua functions for such (memory.readbyte, writebyte, registerexecute, etc.) and if there are no suitable function, developers can add new interface functions to the lua engine.

[gocha]

Also, I have noticed that @xTVaser is working on merging all changes for TASing based on the pcsx2/master. rr-dev@xTVaser/pcsx2-rr

[mirh]

Cool, very very nice.
I guess like that answer my questions.

Not sure if at this point I shouldn't mention lua in the thread title, or if other developers might not have other ideas to.. "reliably" expose/tinker with game internals just like one would do with native pc games.

[pocokhc]

@mirh I also think "YES".
I think that there are not components where mainline pcsx2 depends on lua.
However, in realizing the function in lua, pcsx2 will need to realize the function. (Eg game stop/start, frameadvance, memory read/write, joypad set/get , gui draw etc ...)
In implementing these functions, I think that pcsx2 side may be affected.

[lightningterror]

While good in theory
If ws hacks on && Auto aspect ratio

This still leaves out games that have ingame widescreen options so this implementation won't be fully working.

[mirh]

[putting aside this has got a tad more bigger than just ws hacks] .. then why would you be making a ws hack, for 16:9 ar at least, if that's unneeded?

(also, I don't see how a new cheat system would be trivial)

[lightningterror]

I was thinking more of a Low Priority case.

[lightningterror]

Closing as trivial.

[mirh]

It's not trivial in any possible sense of the word
At most it can be simplified into #5539
https://github.com/ThirteenAG/PCSX2PluginInjector