Add CWCHEAT for postprocessing

[iota97]

This allow to set uniform with CWCHEAT with 0xA2 code:

0xA20000UU 0xVVVVVVVV

U: uniform number [0..3]
V: float value in hex

Example on MHFU (EU version) using Color Correction shader

_C0 Low HP saturation fade
_L 0xA2000001 0x3F800000
_L 0xD08B3724 0x20200010
_L 0xA2000001 0x3E4CCCCD

This should allow to edit the first shader of the chain with #12905 (will test after it's merged) that it's probably fine for the use case (CWCHEAT handling a chain could be done with a offset, but not sure if is worth the trouble).

[LunaMoo]

You could add a version that reads value from memory like 0xA1, then instead of an instant change, you could write a cheat that gradually reduces colors with HP going down etc.

[iota97]

Added, but not sure the best way to parse value that might end up in different format, may shader can handle bit conversion to a certain degree.

0xA300SSUU 0xVVVVVVVV

U: uniform number [0..3]
V: address
S: format (0: byte, 1: half-word, 2: word, 3: float)

MHFU example (shader will get 100.0 with 100HP so must be scaled down in the shader)

_C1 Low HP saturation from memory
_L 0xA3000101 0x090B3724

Edit:
What is the offset (0x08800000) from code like 0x1 to write address and these address btw?

[LunaMoo]

Don't worry, CWCheat can be used to inject your own code to be executed by the game, so you can make the game scale down any values to whatever format and range you wish. You could even do some fun things like pass just a flag which will play animation of screenshaking after being hit etc. imagination(and time) is the limit of how you can mod the game and just making it provide some feedback info is really no rocket science.:)

Edit: As for the offset, I'm not sure what you're asking for, is it about 0xA1 ~ similar code type for vibration? Then I just used 8 following bytes to check for the values stored one after another, it's for the cheat author to format the data in such way to fit the code type.

[iota97]

_C0 Vibration read from memory TEST
_L 0xA1000000 0x08801000
//activate this cheat after the read from memory test to start vibration
_C0 write to memory vibration values
_L 0x20001000 0xF000F000
_L 0x20001004 0x00F000F0

Here for instance address in the read is 0x08801000 but in the write is 0x00001000, I was wondering why that offset 0x08800000 is there.

[LunaMoo]

Ah, that. The offset comes from CWCheat itself, that format considers user memory start as it's 0x0 address as it's only able to interact with that and user memory starts at 0x08800000 so basically all CWCheats make use of that, maybe except pointer codes which read pointers from game memory and those are actual addresses without that offset.

However we don't have to and might even not want to keep that dependency for PPSSPP specific code types and it's quicker to copy&paste actual address from disassembly without having to type it reduced by 0x08800000.

[iota97]

Added chain support:

0xA2PP00UU 0xVVVVVVVV

U: uniform number [0..3]
V: float value in hex
P: pass offset in chain

0xA3PPSSUU 0xVVVVVVVV

U: uniform number [0..3]
V: address
S: format (0: byte, 1: half-word, 2: word, 3: float)
P: pass offset in chain

[unknownbrackets]

I think this can do some cool things, although I guess each cheat will be associated with a very specific post-processing shader.

FWIW, the chain will return an empty vector if "Off", so no need to check for that (doesn't hurt though.)

No real opinion about the addresses. Maybe there's something to be said for consistency... though cwcheat isn't very consistent to begin with.

-[Unknown]

[iota97]

With "Off" I got a vector with that item and size 1, I added the check to not add "OffSettingValue1" in the map and so on that would be kinda weird in the .ini setting once saved.

About association I think there are 2 way:

1. Cheat and specific shader, this is simpler as it allow to access value such as health and so by copying the address in the many "max health/immortal" cheat around (same for other stats as they are usual target for cheat) and just convert them in shader.

2. Create a generic shader and let the cheat do the conversion of value (using code injection which require more time for sure) and shader that might have 4 effect (or more using a chain) and the cheat just activate them setting the right value.

[unknownbrackets]

Oh, that must be a bug then, I'll check. That might confuse other things...

-[Unknown]

[unknownbrackets]

Sorry, I'm wrong. Everywhere else, we check for "Off" before grabbing it. My bad.

Hm. If we really wanted the cheats and shaders to go hand in hand, you'd almost want a Cheats=cheatfile.db in the shader ini. We do support multi game id cheat files now, and could in theory process multiple files in the cheat system.

-[Unknown]

[iota97]

Should Cheats=cheatfile.db just add it to the cheat list or even have a option to activate it directly (activating cheat without user explicit intention might be a bit too much).

Here a complete example for reference (MHFU ULES01213, saturation based on HP, blur on low stamina, kinda not the best blur tbh).

Setting 1 and 2 are used by the CWCheat, while 3 and 4 in the UI menu as a flag (step to 1 make it kinda fine as "bool" UI wise) to enable or disable the 2 effect (one would like only one or to disable them in village (stamina is 0 there sadly, hp are fine).

Cheat:

_C1 Status based shader
_L 0xA3000100 0x090B3724
_L 0xA3000101 0x090B399A

Ini:

[MHFUHP]
Name=MHFU Status
Fragment=mhfu_hp.fsh
Vertex=fxaa.vsh
SettingName3=HP Saturation
SettingDefaultValue3=1.0
SettingMaxValue3=1.0
SettingMinValue3=0.0
SettingStep3=1.0
SettingName4=Stamina Blur
SettingDefaultValue4=1.0
SettingMaxValue4=1.0
SettingMinValue4=0.0
SettingStep4=1.0

Fragment:

#ifdef GL_ES
precision mediump float;
precision mediump int;
#endif

uniform sampler2D sampler0;
uniform vec2 u_pixelDelta;
uniform vec4 u_time;
uniform vec4 u_setting;
varying vec2 v_texcoord0;

void main()
{
  float blur_fac = 0.0;
  if (u_setting.y < 150.0 && u_setting.w > 0.5)
    blur_fac = (1.0-u_setting.y/150.0)*10.0*sin(u_time.x);
  float sat_fac = 1.0;
  if (u_setting.z > 0.5)
    sat_fac = u_setting.x/100.0;

  vec2 offset = u_pixelDelta*blur_fac;
  
  vec3 rgbSimple0 =  1.0 * texture2D(sampler0, v_texcoord0.xy + offset * vec2( 0.0,-2.0)).xyz;
  vec3 rgbSimple1 =  3.0 * texture2D(sampler0, v_texcoord0.xy + offset * vec2(-1.0,-1.0)).xyz;
  vec3 rgbSimple2 =  8.0 * texture2D(sampler0, v_texcoord0.xy + offset * vec2( 0.0,-1.0)).xyz;
  vec3 rgbSimple3 =  3.0 * texture2D(sampler0, v_texcoord0.xy + offset * vec2( 1.0,-1.0)).xyz;
  vec3 rgbSimple4 =  1.0 * texture2D(sampler0, v_texcoord0.xy + offset * vec2(-2.0, 0.0)).xyz;
  vec3 rgbSimple5 =  8.0 * texture2D(sampler0, v_texcoord0.xy + offset * vec2(-1.0, 0.0)).xyz;
  vec3 rgbSimple6 = 10.0 * texture2D(sampler0, v_texcoord0.xy + offset * vec2( 0.0, 0.0)).xyz;
  vec3 rgbSimple7 =  8.0 * texture2D(sampler0, v_texcoord0.xy + offset * vec2( 1.0, 0.0)).xyz;
  vec3 rgbSimple8 =  1.0 * texture2D(sampler0, v_texcoord0.xy + offset * vec2( 2.0, 0.0)).xyz;
  vec3 rgbSimple9 =  3.0 * texture2D(sampler0, v_texcoord0.xy + offset * vec2(-1.0, 1.0)).xyz;
  vec3 rgbSimple10=  8.0 * texture2D(sampler0, v_texcoord0.xy + offset * vec2( 0.0, 1.0)).xyz;
  vec3 rgbSimple11=  3.0 * texture2D(sampler0, v_texcoord0.xy + offset * vec2( 1.0, 1.0)).xyz;
  vec3 rgbSimple12=  1.0 * texture2D(sampler0, v_texcoord0.xy + offset * vec2( 0.0, 2.0)).xyz;
  
  vec3 rgb =  rgbSimple0 + 
              rgbSimple1 +
              rgbSimple2 +
              rgbSimple3 +
              rgbSimple4 +
              rgbSimple5 +
              rgbSimple6 +
              rgbSimple7 +
              rgbSimple8 +
              rgbSimple9 +
              rgbSimple10 +
              rgbSimple11 +
              rgbSimple12;
  rgb = rgb / 58.0;

  gl_FragColor.rgb = mix(vec3(dot(rgb, vec3(0.299, 0.587, 0.114))), rgb, sat_fac);
  gl_FragColor.a = 1.0;
}

[unknownbrackets]

If the shader has options to enable/disable the cheat, maybe it could auto activate? I could definitely see it being confusing, though. I guess it really depends on the shader. And I don't think we should enable cheats by default, so they'd still have to enable cheats - meaning the shader wouldn't work "out of the box."

-[Unknown]

[LunaMoo]

Maybe some new "effects" pack? We could combine a cheat file with PPSSPP specific cheats, shader and maybe leave the format open to whatever someone could add in the future, then store those packs in separate folder and just activate them with a separate option.

Edit: I'm thinking something alike:

[Options]
Effect1name = "Name of the effect to show in some new menu"
Effect1 = cheat1;cheat2;shader1 #activates all required cheats/shaders/future features
Effect2name = -||-
Effect2 = cheat3,shader2
Effect3name = -||-
Effect3 = cheat4
Effect4name = -||-
Effect4 = futurefeature1

[Cheats]
-cheat1
-cheat2
-cheat3
-cheat4

[Shader1]
-vertex shader
-fragment shader
[Shader2]
-vertex shader 2
-fragment shader 2
(...)
[future features]

Or just a zip file with cheat and shader files and extra file that assign it to some options. Zip could be named gameIDpackName. For example based on the above ULES01213HP.zip and it would show in some custom effects - specific to the game - menu with all the assigned options under a label HP, so another mod would have it's own options under it's own label etc. I know that's a lot of work, so just throwing an idea for the future.

[LunaMoo]

@hrydgard what do you think about merging this before release? Features like that which require community support really benefit from existing in the release version and this could easily grow later on based on the feedback it get's from larger pool of users.

[hrydgard]

@LunaMoo Thanks for the reminder, that is true. I'll take a closer look at this soon.

[hrydgard]

Looks good!