More detail on Tint Background event commands (50h and 51h)

the first parameter byte (and the only for Command 50h) has been regarded as the color desired, with Lockirby2 estimating Bit 6 as a reversal, and giving some sample color arguments.

it turns out there's more to it, with multiple flags and sub-commands within the parameter byte.  and not all of them make sense or seem useful.  here's what i've found (it was done purely by studying the code; i have yet to test any of it), and some observations that resulted:

http://assassin17.brinkster.net/forum-po...d-C0-2.txt

comments and questions welcome.

Nice findings, I'm sure someone will eventually test this.

@Lockirby2 : Time to maybe update your event document!

Nice! I'll probably take a look into it during the week because I can only use the onscreen keyboard right now and it is painful.

can't analyze Command 51h usage (nor 53h) because the event script dump no longer lists the parameter byte, instead offering its own guesses.  but as for Command 50h (and 52h when noted):

1) Subcommand 2 only appears to be called in a single place: CA/2AC9.  and Square feeds it an (unused) argument to affect all 3 color components, with an index of 3 (so a value of 31).  what all this means is that we can un-hobble the subcommand to respect parameters instead of always adding 31, and vanilla's behavior won't change!  simply enter Function C0/1289 at C0/1296 instead.
- the above also seems to be true for Command 52h (Tint objects).  relevant numbers are: CA/2ACB script address, C0/14D1 subcommand function, C0/14DE new entry point.

2) when using subcommand 4 (for both Commands 50h and 52h), Square appears quite mindful of the fact that they joined the Subcommand and Invert Flag at the hip.  nearly all calls to it, done to decrease components towards targets, have either:
a. an index of 3 in bits 0-1, loading a 31 value, giving 0 after the inversion.  makes sense for darkening.
b. for components they don't want to affect, corresponding bit 2, 3, or 4 is 0.  this loads 0, or 31 post-inversion.  makes sense to exclude a component from darkening, as the subcommand function exits when already <=.

the ONE place that's baffling me is: CA/CEEE.  they decrement all 3 color components towards target of 27 (index of 0 loads 4, gets inverted), doing so 16 times in a loop.  this doesn't make sense, as you should need 4 iterations max.  not to mention, it'll exclude all but the brightest color values.  i almost wonder whether the event coders briefly forgot about inversion and wanted the target of 4.  this is during the Baram and Clyde knife scene.

3) usage of subcommand 5 is similarly aware of said hip-joining.  all calls (several for Command 50h, one for 52h) use index 0 for all 3 components, which loads 4, then is inverted to 27, and the subcommand function adds 4 to get our final decrementor.  so we subtract 31; aka set to black. now, they could've done the same thing by setting bits 2-4 to 0, and not having the function add 4.  but maybe there was some (eventually unused) reason during development they wanted the addition.

but that said, given their limited use of subcommand 5, and the more popular subcommand 4 having the same arguments over and over, i'm still not entirely sure what they needed the Invert Flag for.  i guess it lets Subcommand #4 mirror #1 in terms of excluding components, but having 3 in bits 0-1 would have accomplished the same thing.  it seems that much of the time, the flag is just an obstacle they work around.

a 9-bit parameter byte would've been sooo much more flexible.

the same lightening targets of 31 and darkening of 0 are used over and over.  guess when Commands 50h and 52h use 8 or 16 for a target or decrementor/incrementor?  never, that's when!  when Square wants to lighten or darken by multiple steps, they just loop multiple times in the event code.  when they don't want to fully lighten or darken, they just loop less times, though this doesn't give the same floor/ceiling that having an intermediate target would.

4) Subcommands 3 and 6 totally disregard the parameter bytes.  meaning you can't (slowly) restore just 1 or 2 color components to normal palette levels; it has to be all 3.  for Square's usage, this turns out fine, given they tend to call the command after having modified just a single component.  so the restoring for the other 2 components simply does nothing.  however, suppose we had made all 3 color components brighter than usual.  and we wanted to gradually lower the Green to normal, then the Blue, then the Red.  i don't see a way to do this.

now, we could repurpose Bits 2-4 to control whether a component is affected by these subcommands.  however, unlike my proposed modification back in #1, we WOULD need to modify the vanilla event code to retain existing functionality, because Square has all sorts of values in the parameter byte when using Subcommands 3 and 6.

guess whether it's worth the effort depends on whether hackers see uses for scenarios like the one provided above.

-----------

summary of non-technical, non-function-rewriting stuff: near end of Baram and Clyde no-knife scene.  minimal darkening occurs.  was more intended?  would taking 16 steps towards 4 target instead of 27 target make more sense or look better?

that's quite the find

thanks.. it's not exactly world-changing, but it's interesting to encounter stuff that was arguably unintentionally (nearly) dummied out.  to see what i mean, take a savestate during the dream, right after Baram says he's lost too much blood.  hack the ROM so C0/A744 has 80h.  then reload state, and pay attention when Clyde says, "I'm sorry...".  normally, the screen darkening that the event script does at this point is imperceptible to me, and the visible fade doesn't start until Baram replies.  the hacked way is how i suspect the event writer intended it, lining up with the eerie sound effect.