ZDoom

I don't know if you are still looking for feedback on this, but I just wanted to say I used this method of replacing SPF_INTERPOLATE with SPF_SCALEDNOLERP in BoA 3.1 and it made the tilt effects work very nicely in that mod, though I think it's basically just Tilt++ code.

On the other hand I tried this method with ZMovement v3.2.1 and it did not go as hoped; it was very choppy, though I don't know if that was to be expected or not...

Ah, right. I believe mjr4077au has plans, in future, to make these changes "drop-in". As in, user doesn't have to do anything.

Well just to answer my own question, I guess the solution is opt in now. After doing some digging I changed SPF_INTERPOLATE to SPF_SCALEDNOLERP in TiltPlusPlus.zc and it seems to be working now.

vid of 4.10 for me with Tilt++ (git), 60fps cap (for example)

https://drive.google.com/file/d/1XnSDgUmO42Ay9GFocP-L8LYRyxajoWjZ/view?usp=sharing

it's fine at multiples of 35, but always was...

With GZDoom 4.10, seems to just work for me, with Tilt++.

First of all, thank you very much for continuing to work on this!

This might be a dumb question, but do mods have to opt in to this now, or is there a new cvar I'm missing? Because I'm still getting the jitter in Tilt++ in post-merge builds at framerate limits that aren't multiples of 35...

Addressed with https://github.com/ZDoom/gzdoom/pull/1854

Please see the new PR I've completed to address this. I'm happy with what I'm presenting, but would love for it to be tested within the community against a variety of mods, ensuring it doesn't affect multiplayer, etc.

https://github.com/ZDoom/gzdoom/pull/1854

Thank you for your efforts! Great to see this finally being addressed. :)

Nash has reached out the BoA team who have fixed an issue with their TC, there was no issue with the code in my branch.

This has now been presented for review. https://github.com/coelckers/gzdoom/pull/1414

[quote="mjr4077au"]If `boa_tilteffects` is enabled but `boa_strafetilt` is disabled, what's the effect like?[/quote]

Same result as boa_tilteffects true and boa_strafetilt true; view rolls aren't applied during the c3m5_c level tilt sequence.

EDIT/ I just remembered you can actually trigger this sequence on any BoA level with "pukename settilt 15" --should make testing easier.

		// Allow all other effects to be disabled via CVar
		if (!boa_tilteffects) { return; }

		double curRoll = 0;

		// If on the ground or on an object
		if ((owner.Pos.Z == owner.FloorZ || owner.bOnMObj) && owner.Health > 0)
		{
			if (boa_strafetilt) { curRoll += CalcStrafeTilt(); } // Do strafe tilt, if enabled
			curRoll += CalcMovementTilt(); // Do movement tilt
		}

		curRoll += CalcDeathTilt(); // Always check if we need to do death tilt

		if (abs(curRoll) > 0.000001) { curRoll *= 0.75; } // Stabilize tilt

		// Apply the sum of all rolling routines (including after stabilization)
		owner.A_SetViewRoll(owner.viewroll + (curRoll - lastRoll), SPF_INTERPOLATE);
		lastLevelTilt = curLevelTilt;
		lastRoll = curRoll;

Thanks for the insight, I haven't played the TC right through so I wasn't aware precisely. I'm sure we can get this right, these are just typical problems with a new solution.

This is the code that does the tilting:

[code] // Allow all other effects to be disabled via CVar
if (!boa_tilteffects) { return; }

double curRoll = 0;

// If on the ground or on an object
if ((owner.Pos.Z == owner.FloorZ || owner.bOnMObj) && owner.Health > 0)
{
if (boa_strafetilt) { curRoll += CalcStrafeTilt(); } // Do strafe tilt, if enabled
curRoll += CalcMovementTilt(); // Do movement tilt
}

curRoll += CalcDeathTilt(); // Always check if we need to do death tilt

if (abs(curRoll) > 0.000001) { curRoll *= 0.75; } // Stabilize tilt

// Apply the sum of all rolling routines (including after stabilization)
owner.A_SetViewRoll(owner.viewroll + (curRoll - lastRoll), SPF_INTERPOLATE);
lastLevelTilt = curLevelTilt;
lastRoll = curRoll;[/code]

If `boa_tilteffects` is enabled but `boa_strafetilt` is disabled, what's the effect like?

[quote="mjr4077au"]I do assume that the current dev branch of BoA works 100% as expected on the latest release of GZDoom, albeit interpolated?[/quote]

Yes. It also works as expected in this branch with cl_nointerpactorangles set to false.

I can also get it working again in your branch by setting boa_tilteffects to false (not the default). This is not required in mainline gzdoom, or in this branch with cl_nointerpactorangles set to false. It is only with cl_nointerpactorangles set to true that having boa_tilteffects set to true causes the failure.

EDIT/ Also I don't know if you're familiar with the sequence I'm talking about in BoA, but if you go to c3m5_c and kill monsters, give all, noclip, turn to the wall on your left and travel to the engine room towards the marked objective point and interact with it (hold interact for some time, it's a slow burn), and once the timer begins the effect should kick in around the 2:50 mark on the countdown. Don't forget to disable noclip before the effect kicks in otherwise it could interfere since it moves you around too.

I'll probably only be able to check out BoA next week at this stage. I'm away this weekend immediately after close of business today.

I've really only tested this with the two test files Nash provided in the first post, so it's not surprising that there's potentially issues with pitch and yaw in real-world examples like BoA. Hopefully nothing too serious though.

I do assume that the current dev branch of BoA works 100% as expected on the latest release of GZDoom, albeit interpolated?

It looks like the commit that actually broke compatibility with this branch was not the initial rework, but rather this:

https://github.com/Realm667/WolfenDoom/commit/cec1b4b996425822cac51dbfbf10d7b3451f3ce8