[GZDoom Submission]Quake Camera Roll Inclusion

[Major Cooke]

ZDoom
GZDoom
ACC

---

Behaves just like A_QuakeEx's intensity and wave capabilities. However, there is one small difference. rollIntensity is UNCAPPED. There is no reason for it to be capped at all and in fact, I rather like the broader range of intensities for use with rolling.

It follows the exact same routines as the intensity and waves, so nothing new there.

Test Package
Download, unzip somewhere, and load the quakerolltest.pk3 file.
Press reload to initialize a quake, and then primary fire to roll the camera.

Graf: Some things I have not yet addressed which I need your input on.

1. Save version? Do I need to bump up both the minsavever and savever? I have not done that yet so I wanted to clarify before I do anything I'm not supposed to.
2. I did nothing in terms of interpolation because this is simply part of QuakeEx. Do I really need to do anything for that, or can this just be left as is?

[Xeotroid]

You mean something like this?

[Major Cooke]

More like:
Turn down your volume, it can be annoying. Just watch how the camera shakes whenever close to the explosions.

[Caligari87]

Honestly I think something like this is better suited to mod-side add-ins, not an engine feature. Mods like Brutal Doom already include their own explosion shaking effects, and an automatic engine-side effect would potentially not match the effects intended in the mod. Also, some mods leverage things like A_Explode for non-explosive effects, and the engine would have no way of telling what's actually an "explosion" or not without extending some flags to say "this is an explosion-explosion", which by default would have to be set to "no" to avoid breaking anything, thus making the whole thing moot.

[Gez]

I can see this closed with [lol no].

As Nash's mod demonstrate, it's already possible to control camera roll with a mod. You want explosions to do some camera roll, you mod it in.

[Major Cooke]

I think you're all missing the point.

If this becomes a thing, doing rolling on the player side while maintaining accurate sprite rolls would become a clusterfuck. It would in short rely upon actors not having any roll, when say for example I have roll on a sideways cyberdemon that I don't want to affect if the player is a cyberdemon. Yes, I could take off +ROLLSPRITES flag if that were to happen, but guess what? BAM. He's standing up right again. That's counterintuitive.

So I disagree, it should not be done mod side when I want to not affect the sprite OR MODEL for that matter. Using an actor to perform a QUAKE EFFECT just adds more overhead than necessary.

Graf: Some things I have not yet addressed which I need your input on.

1. Save version? Do I need to bump up both the minsavever and savever? I have not done that yet so I wanted to clarify before I do anything I'm not supposed to.
2. I did nothing in terms of interpolation because this is simply part of QuakeEx. Do I really need to do anything for that, or can this just be left as is?

EDIT: Thanks for moving this, Weasel.

[Major Cooke]

Update: Moved the CamRoll out of the TRotator and into AActor directly instead.

[Graf Zahl]

Why is CamRoll even part of the actor?
The shaking is a property of the view, not the camera actor, so ideally this should be one single global ViewRoll variable.

That said, what was there already is just as wrong. The place to set this up should not be in the GL code but in R_SetupFrame. There's also no interpolation.

Also, I can't merge a GZDoom PR that contains everything that's already in the one for ZDoom, it'd create a rather messy merge history.

[Major Cooke]

Why is CamRoll even part of the actor?

If rolling sprites are introduced, I thought it might be pertinent to not have them being included with quaking rolls.

The shaking is a property of the view, not the camera actor, so ideally this should be one single global ViewRoll variable.

Should I be making use of iview then, new and old?

That said, what was there already is just as wrong. The place to set this up should not be in the GL code but in R_SetupFrame. There's also no interpolation.

I think Nash had it done in there to prevent overhead in ZDoom. I'm unsure about what you want me to do there for moving that stuff from GL to R_SetupFrame.

Also, I can't merge a GZDoom PR that contains everything that's already in the one for ZDoom, it'd create a rather messy merge history.

Right, I'll fix that.

[Graf Zahl]

Nash's stuff was just a quick addition. But if you want to do more with the roll it should be done right and be tracked properly, yes, that includes the interpolation viewer and other stuff that's done in R_SetupFrame. The overhead of this is marginal, and maybe someone finds a way to make it work with software rendering later.

[Major Cooke]

Okay. While I'm working on redoing this, I've opened a new pull request on ZDoom's side so you can see what's going on.

I know the interpolation is not complete yet, still working on that bit. In fact... I'm unsure of how to handle the interpolation or how to really even test it.

On GZDoom's end:

in RenderViewpoint.

Is that what you meant? Is there more? Save for the interpolation, this is working thus far.

[Graf Zahl]

The interpolation should be in R_SetupFrame. The GL code should only see the interpolated values.

[Major Cooke]

I never placed it in the GL renderer. In fact all the interpolation for ViewRoll is indeed being done inside R_SetupFrame.

ZDoom PR updated.
GZDoom PR too, this time stripped the hell down to only what changed in the GL section.

Updated the first post's links.

[Graf Zahl]

Ok, I'll review this ASAP.

[Major Cooke]

Awesome. Thanks!

For those of you who want a partly perfect rollover...

Code: Select all

Actor Quakin
{
	const int flags = QF_WAVE;
	+NOINTERACTION
	States
	{
	Spawn:
		TNT1 A 0 NoDelay A_QuakeEx(3,3,3,35*5,0,256,"",flags,0,0,0,64,35,180*randompick(-1,1),0.1)
		TNT1 A 1 A_SetTics(88)
		Stop
	}
}

This can roll in one of two directions. Which makes me wonder if we could extend the clamp to a range of [-9, 9] instead of [1,9]? Because it works.