ViewAngle offsets

Moderator: GZDoom Developers

User avatar
Major Cooke
Posts: 8059
Joined: Sun Jan 28, 2007 3:55 pm

ViewAngle offsets

Post by Major Cooke »

Pull Request

Adds some new functions, A_SetView<Angle/Pitch/Roll> which modifies the view without affecting the actual actor's angles. This primarily useful for changing camera angles cosmetically.

Currently in D4D, the Hell Knight and Baron of Hell player morphs turn the angle and pitch, which also affects the player's direction as a result, making it very easy for them to run themselves off thin ledges.
You do not have the required permissions to view the files attached to this post.
Last edited by Major Cooke on Sun Feb 09, 2020 1:18 pm, edited 6 times in total.
User avatar
Caligari87
User Accounts Assistant
Posts: 5994
Joined: Thu Feb 26, 2004 3:02 pm
Discord: Caligari87#3089
Github ID: caligari87
Preferred Pronouns: He/Him

Re: [WIP]View/Angle offsets

Post by Caligari87 »

At least two threads where this was previously requested, for reference. If this is added these can be closed.

viewtopic.php?t=61733
viewtopic.php?t=58979

Certainly hope the interpolation bit can be figured out in a way that still allows robust manipulation. Things like "leaning" and "freelook" would be actually possible instead of just emulated.

8-)
User avatar
Major Cooke
Posts: 8059
Joined: Sun Jan 28, 2007 3:55 pm

Re: [WIP]View/Angle offsets

Post by Major Cooke »

It'll still allow for robustness alright. I expect the only part to be going away so far is viewpos, turning back to viewz if it works better in the renderer.

There is another problem to contend with though... the player sprite. It becomes visible when the view and the player are between each other. Considering you'll have the power to set the distance away from the player actor, merely comparing distances of the view camera to the original, and then comparing distances to the portal'd variants of the player should solve this issue. The edge case being that the portal'd player actor blips invisible if equally as distant, but that's solved by simply comparing angles to them. That should ensure only the main one is permanently invisible.

Just need to modify this bit of code to accommodate:

Code: Select all

// Some added checks if the camera actor is not supposed to be seen. It can happen that some portal setup has this actor in view in which case it may not be skipped here
if (thing == camera && !vp.showviewer)
{
	DVector3 thingorigin = thing->Pos();
	if (thruportal == 1) thingorigin += di->Level->Displacements.getOffset(thing->Sector->PortalGroup, sector->PortalGroup);
	if (fabs(thingorigin.X - vp.ActorPos.X) < 2 && fabs(thingorigin.Y - vp.ActorPos.Y) < 2) return;
}
User avatar
Nash
 
 
Posts: 17283
Joined: Mon Oct 27, 2003 12:07 am
Twitch ID: nashmuhandes
Github ID: nashmuhandes
Location: Kuala Lumpur, Malaysia

Re: [WIP]View/Angle offsets

Post by Nash »

Great, always felt dirty that to do camera effects (weapon kickback, tilting, etc), the player's angles had to be physically manipulated and sent across the wire. For those kinds of use cases - like in other engines - they should be render-only, which I hope is what this PR is supposed to do.
User avatar
Major Cooke
Posts: 8059
Joined: Sun Jan 28, 2007 3:55 pm

Re: [WIP]View/Angle offsets

Post by Major Cooke »

Fixed the interpolation. My suspicions were correct. Even standard player movement had been slightly impacted, at least a little bit, until I moved the main chunk of code I had set up in CalcView to R_SetupFrame().
Nash wrote:Great, always felt dirty that to do camera effects (weapon kickback, tilting, etc), the player's angles had to be physically manipulated and sent across the wire. For those kinds of use cases - like in other engines - they should be render-only, which I hope is what this PR is supposed to do.
Correct. There's five new properties available for PlayerPawn and PlayerInfo, each one pretty much acting as an offset. Included is five flags for manipulating these as well.
  • ViewHeightAbsolute (+up/-down) (too many things modify the viewheight and viewz, so better to be safe and give it a variable of its own)
  • ViewForward (+forward/-backward)
  • ViewSide (+right/-left)
  • ViewAngle (+left/-right)
  • ViewPitch (+down/-up)
  • ViewRoll (+clockwise/-counter clockwise)
All of those are relative offsets. The flags to modify that behavior are:
  • ViewAbsPos - ViewForward, ViewSide and ViewHeightAbsolute become your position XYZ coordinates instead of an offset. Furthermore, ViewHeight will be allowed to go above ceilings and below floors in this mode. Good for cinematic cutscenes... If it doesn't cause any issues. I don't see any reason why it would though. Quakes go through floors and ceilings all the time.
  • ViewAbsOffset - Angle is not accounted for (not relative).
  • ViewAbsAngle - Absolute angle.
  • ViewAbsPitch - ^ pitch.
  • ViewAbsRoll - You get the point...
So yes. This means bye bye A_SpawnProjectile hacks and doing crazy offset shit at last. And I know what you mean by dirty. I had to disable D4D's angle and pitch adjusting on some of the demon morphs because they made the player run with the angle changes.
User avatar
Major Cooke
Posts: 8059
Joined: Sun Jan 28, 2007 3:55 pm

Re: View/Angle offsets

Post by Major Cooke »

Alright, it turns out the issue with the portals and hiding the player sprite is beyond my understanding.

As that's the only bug that I'm having trouble with, I've opened the PR for review/merging.
User avatar
Nash
 
 
Posts: 17283
Joined: Mon Oct 27, 2003 12:07 am
Twitch ID: nashmuhandes
Github ID: nashmuhandes
Location: Kuala Lumpur, Malaysia

Re: View/Angle offsets

Post by Nash »

I just tested this with a homebrew build, seems to work perfectly so far, minus the portal thing. Good work, MC.
User avatar
Major Cooke
Posts: 8059
Joined: Sun Jan 28, 2007 3:55 pm

Re: View/Angle offsets

Post by Major Cooke »

Thanks! Sadly I will need help with the portal stuff. I have tried everything I could think of.

Furthermore, I did some additional testing with Arookas' portal map. Simplistic visual + teleporter portals don't take into account Vec#Offset functions, so people who rely upon those will notice the camera actually goes through the line itself, and NOT the portal.
User avatar
Major Cooke
Posts: 8059
Joined: Sun Jan 28, 2007 3:55 pm

Re: View/Angle offsets

Post by Major Cooke »

Alright, I've made a second PR which contains the view angle changes only as part 1. Should also make this easier to merge. The original PR is still available for all-in-one however, so there's still options.

I made this in an effort to help boost the chances of at least some parts that are guaranteed to be working, which has nothing to do with the portal issue involved with the positional offsets. If the first part is accepted, I'll make a part 2 PR which contains the rest.

Part 1 - Angles
User avatar
Nash
 
 
Posts: 17283
Joined: Mon Oct 27, 2003 12:07 am
Twitch ID: nashmuhandes
Github ID: nashmuhandes
Location: Kuala Lumpur, Malaysia

Re: View/Angle offsets

Post by Nash »

Good idea separating the angle-only part out. That one is more immediately-useful (like those tilt and weapon view-kickback mods).
User avatar
Major Cooke
Posts: 8059
Joined: Sun Jan 28, 2007 3:55 pm

Re: View/Angle offsets

Post by Major Cooke »

Thanks!
I completely forgot to upload a test example. See first post, ViewAngle.pk3.
User avatar
Nash
 
 
Posts: 17283
Joined: Mon Oct 27, 2003 12:07 am
Twitch ID: nashmuhandes
Github ID: nashmuhandes
Location: Kuala Lumpur, Malaysia

Re: View/Angle offsets

Post by Nash »

Cooke, I was curious as to why did you make this only for the PlayerPawn and not all actors? If you are viewing through security cameras/monsters/other actors, you might want to do some view angle scripting on those, too.
User avatar
Major Cooke
Posts: 8059
Joined: Sun Jan 28, 2007 3:55 pm

Re: ViewAngle offsets

Post by Major Cooke »

I've redone the submission once more. Now includes A_SetView<Angle/Pitch/Roll> which works just like A_Set<Angle/Pitch/Roll>.

Also updated the test package.

As Nash rightfully points out, there's no clean way to do this without having the actor vectors on them directly, especially since any actor can serve to be a camera. So this can affect all actors now.
User avatar
Major Cooke
Posts: 8059
Joined: Sun Jan 28, 2007 3:55 pm

Re: ViewAngle offsets

Post by Major Cooke »

Not going to close this thread yet because the first half was merged. I'm reworking the second half now and am going to dedicate more time to figuring out the offsetting and tackling the outstanding problems if possible.

Return to “Closed Feature Suggestions”