[Added] ViewAngle offsets

Moderator: GZDoom Developers

ViewAngle offsets

Postby Major Cooke » Thu Aug 15, 2019 1:32 pm

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
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: [WIP]View/Angle offsets

Postby Caligari87 » Thu Aug 15, 2019 2:06 pm

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
Caligari87
I'm just here for the community
User Accounts Assistant
 
Joined: 26 Feb 2004
Location: Salt Lake City, Utah, USA
Discord: Caligari87#3089

Re: [WIP]View/Angle offsets

Postby Major Cooke » Thu Aug 15, 2019 5:08 pm

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 allExpand view
// 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
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: [WIP]View/Angle offsets

Postby Nash » Thu Aug 15, 2019 8:15 pm

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
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: [WIP]View/Angle offsets

Postby Major Cooke » Thu Aug 15, 2019 10:30 pm

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
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: View/Angle offsets

Postby Major Cooke » Fri Aug 16, 2019 4:11 pm

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
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: View/Angle offsets

Postby Nash » Sun Aug 25, 2019 12:14 am

I just tested this with a homebrew build, seems to work perfectly so far, minus the portal thing. Good work, MC.
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: View/Angle offsets

Postby Major Cooke » Sun Aug 25, 2019 6:26 pm

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
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: View/Angle offsets

Postby Major Cooke » Sat Sep 07, 2019 11:49 am

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
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: View/Angle offsets

Postby Nash » Sun Sep 08, 2019 1:17 am

Good idea separating the angle-only part out. That one is more immediately-useful (like those tilt and weapon view-kickback mods).
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: View/Angle offsets

Postby Major Cooke » Tue Sep 10, 2019 10:16 am

Thanks!
I completely forgot to upload a test example. See first post, ViewAngle.pk3.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: View/Angle offsets

Postby Nash » Wed Oct 02, 2019 7:24 pm

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
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: ViewAngle offsets

Postby Major Cooke » Sun Feb 09, 2020 1:22 pm

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
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: ViewAngle offsets

Postby Major Cooke » Thu Aug 27, 2020 11:09 am

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.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007


Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 0 guests