Display: add CameraSmoothing setting to adjust smoothing ratio

[emoose]

Seems to work fine, adds an INI/UI setting to Display section, and a Game_SetCameraSmoothness func that lets us adjust it in code (could let freecam code call that to override/restore it too)

Sadly setting the smoothness too low makes camera movements pretty jerky, as explained at #436 - would be nice if we could let smoothing only affect movements made by the game (eg. camera movements when player char climbs up/down), while player inputs would use a different value, seems game code treats them both the same though AFAIK :/

This should affect both mouse & controller movements, not sure if it might affect camera movements in cutscenes, I couldn't see any change in the starting car cutscene at least.

E: added code to disable the smoothing while in freecam, works pretty well there IMO, but feel free to revert if you like, or we could change it so it just reduces the smoothing instead of disabling it entirely (you can still change smoothing in cfgMenu when in freecam to try other values)

Build at https://github.com/nipkownix/re4_tweaks/suites/10270563416/artifacts/504249207 for anyone that wants to try it (smoothing setting is inside Display section)

[emoose]

Finally found a way to get rid of the camera orbiting, this took way too long to figure out, was about to try decompiling GC's debugCamera stuff but decided to try out zeroing the CAMERA_POINT stuff first, was surprised to see that did the trick 😸

Had to adjust the fFreeCam_depression = std::clamp(fFreeCam_depression, values from 2.33 to 6 for it to work properly though, not sure if 6 is actually the best value for that, but seems to allow it to fully look up/down without camera reversing everything at least.

Freecam feels a bit better to use now, there does still seem to be some jittering when looking up/down though, not sure if that's a problem with the game code, or maybe the way we update fFreeCam_depression...
(increasing the smoothing that the earlier commit removed helps with the jittering, but would be sweet if we could fix it without needing the camera smoothing active, side-to-side camera movement doesn't seem to jitter at all..)

Build can be found at https://github.com/nipkownix/re4_tweaks/suites/10363460126/artifacts/510943414 (if you want to re-enable smoothing in freecam just go to Display menu and adjust the smoothing option)

E: there does seem to be certain angles where it always starts to jitter at least, or feel like it's "sticking"... one guess for the jitteriness is maybe to do with the calcOffset code that calculates camera rotation/offset, maybe when it hits certain rotation values it starts changing the CAMERA_POINT stuff that we zeroed, rather than the actual camera rotation itself (eg. for when the orbiting camera shifts a little when you move camera above/below character...), the code is pretty maths heavy though, nothing really obvious there like bounds for the rotations or anything :/

---

E: If anyone wants to try looking into it here's an IDB with some extra vars labelled around the CameraQuasiFPS stuff: https://www.mediafire.com/file/6wu31t8sqfw78wx/bio4-230114-tmp.zip/file
Think orbiting is calculated using the g_readyOfs / g_transOfs data, there's a bunch of different camera locations defined via those (CameraQuasiFPS::bindDefaultCamera has labelled names for them)

Those are made of QFPS_OFS_ARRAY / QFPS_OFFSET[2][3] structs, calcOffset func seems to be using 3 of the QFPS_OFFSET vectors (at around 59C5F4), looks like if mouse Y (m_depression_ratio_204) is below 0 it uses offset[2] * offset[0], else if above 0 it uses offset[1] * offset[0] (multiply is handled with VecLinearCombination, seems to just do a simple scale + add), guessing that's how the different orbits for when going above / below character are handled.

p_offset->m_campos_0[0] at the end of calcOffset is what defines the orbiting position, and instead of setting the camera rotation here it seems to set p_offset->m_target_18 to a position where camera should point at? (guess something else later converts that to rotation but not sure what yet, don't think that conversion is the problem though, AFAIK it's something up with m_target)

[nipkownix]

Ah, pretty nice improvements!

Sadly setting the smoothness too low makes camera movements pretty jerky, as explained at #436

I ended up hitting the same roadblock a few months ago. Was trying to make the mouse-look camera more responsive by removing this smoothing. Meh.

Finally found a way to get rid of the camera orbiting, this took way too long to figure out, was about to try decompiling GC's debugCamera stuff but decided to try out zeroing the CAMERA_POINT stuff first, was surprised to see that did the trick 😸

Ohh! Nice work! I'm not at home for a couple of days, so I can't test this right now, but I'm looking forward to it.

Edit: Ah, btw, would you mind taking a look at #419 and #409 when you have some time? No rush :p

[emoose]

Figured a way to get rid of some of the sticking issues, took a while but think I got it calculating the m_target value mostly correct now (so none of the g_transOfs stuff should be involved any more)

Still some jitteryness when looking up/down though, strange because left/right doesn't seem to have that issue, there is some code (@ 0x59E27A) that uses a lr_rate.1171 variable which seems to be adding to a target_aim_eff.1170 vec each frame, only seems to add the X axis though, for the others it's using the direction directly, maybe some kind of smoothing...
(if you disable that block by nopping 0x59E23F that does seem to make left/right start to jitter too, wonder if editing this stuff could help us get rid of the Y axis jitter in-game when smoothing is disabled...)

Also some weirdness when trying to look directly up/down, starts slowing down the rotation for some reason, don't really get why.. maybe some issue with whatever is using the m_target value, but not really sure.
For now I've just left it clamp to -6 - 6, should stop it just short of when it starts slowing the movement, means we can't look directly up/down anymore though...
(E: aha managed to get rid of that weird slowdown, had to use sin/cos on the Y axis value for some reason, seems to let it work fine now 🐱)

E: added something to copy that lr_rate stuff for Y axis, don't think that can be done in the same section as lr_rate since that gets ran after Y has been matrix multiplied etc (so probably wouldn't be able to help with the in-game judder with smoothing disabled), but making it work on our fFreeCam_depression value seems to work fine at least - not completely sure how much this helps with the jitter/judder tho... maybe would be better to use 50% cam smoothing.

---

E2: bah, seems there's an issue with the freecam movement now, looking at extreme angles makes A/D strafing go really slow, guess it's similar to the slow rotation issue, probably just needs a sin/cos somewhere... (E3: should be fixed now, along with the diagonal movement being sped up)

[emoose]

Rebased it onto latest master, there is one weird thing I noticed with this though, if you hold RMB while in freecam then moving the mouse will shift the camera position - that could actually be useful for lining up position instead of trying to tap WASD keys, but seems there's some problem with it which makes it move camera in a weird pattern.

I'm not sure how that's actually being done, doesn't seem we're checking for RMB or moving camera based on move movement anywhere...
(seems this was present before this PR at least)

E: think it's game doing it, key_btn_on gets KEY_FORWARD etc set when moving mouse forward with RMB pressed even without freecam enabled, guess aim mode must be checking for those KEY_FORWARD flags.

Tried adding a check in our code that updated m_depression / m_direction so it wouldn't update if KEY_KAMAE (aim button) is pressed, seemed to fix the weird pattern at least.

Doesn't really work that well tho, looks like it doesn't care about amount of mouse movement, just sets KEY_FORWARD flag no matter how much you move it, so can't really make subtle adjustments or anything...
Could probably add something that would update based on AnalogLX etc instead, but meh, I'll probably just prevent checking for KEY_FORWARD etc if that KAMAE key is pressed for now.

[nipkownix]

E: think it's game doing it, key_btn_on gets KEY_FORWARD etc set when moving mouse forward with RMB pressed even without freecam enabled

Ah yeah, IIRC that has been a thing since forever. You can reproduce the same issue if you hold RMB and move the mouse while not having a weapon equipped. Probably yet another weird quirk in PadRead.

[nipkownix]

Just tested this - very nice!
Did notice some jerky movement if I looked down all the way, though. Maybe increasing the camera smoothness would help here?

[emoose]

Do you mean it's jerky as you move it down, or is it when you pull it straight down and it seems to shift left/right a little at the end? I couldn't really find a good way to fix that, tried loading up an FPS with noclip mode and tried the same there and that also seemed to have the exact same issue, so I figured that's not a huge deal (then again I only checked with HL1 which is pretty old, maybe newer games might have fixed that, hm..)

Smoothing might be able to help with those, you can try changing the smoothing setting in Display while in freecam and see if it helps (thought about adding a seperate FreecamSmoothing option for that but idk, maybe just setting freecam to a low smoothing value would be good enough)

It seemed like the camera code does its own smoothing as well with the lr_rate stuff I mentioned, wonder if patching that out while keeping the CamSmooth stuff active might be any better.

[nipkownix]

or is it when you pull it straight down and it seems to shift left/right a little at the end?

This. Not a big deal though. Does HL1 really have the same issue? Never noticed it before :p

Another thing before we merge this: It was mentioned in #436 that the camera goes to Leon's feet when free cam is enabled. Maybe there's a way to position it at Leon's eye level instead or something like that?

[emoose]

Ah yeah was meaning to add something for that, guess we can just add some hardcoded Y/Z offset to the character position for now.

Would be nice if we could keep the current camera rotation too but not sure how that would translate to this new cam stuff.. will try playing around with it soon.

[nipkownix]

Are we good to merge this as is? I don't think the camera rotation is that big of a deal, tbh. It already feels pretty nice with the Y change.