ViewPos

Like feature suggestions, but you've actually written code to make it happen. More likely to make it into the game than some random request in feature suggestions.

Moderator: GZDoom Developers

Forum rules
Please see Code submission guidelines

GZDoom Status:
Image

Legacy Status:
Image Image

QZDoom Status:
Image

ViewPos

Postby Major Cooke » Fri Sep 04, 2020 7:59 am

Pull Request

Adds Vector3 ViewPos to actors. Changing this will offset the view of the camera. This takes into account pitch and roll by default when offsetting, and is operating via the actor's primary angles, NOT view angles - those are applied after.

X: +Forward | -Back
Y: +Left | -Right
X: +Up | -Down

ViewPos can be manipulated by the following flags:
  • VIEWPOSNOANGLES: Does not take yaw/pitch/roll into account for offsetting and simply adds onto the position, leaving the rotating to the modder.
  • ABSVIEWPOS: Overrides the above flag. ViewPos becomes absolute position for the camera. Interpolation for portals is disabled in this mode, so it'll be down to the modder to use the interpolation functions (Vec#Offset(Z)) to get proper portal displacements.
Notes:
  • Do not perform portal handling for anything other than when the ABSVIEWPOS flag is present. Portal handling is already done for everything else.
  • Portal handling is done via a trace and keeps the camera in map geometry, for those who want to disable the angle relativity.
  • You cannot see your body as you are technically still in first person view. This is intentional. The idea behind this is to prevent the body from rendering without work-arounds.
  • ViewPos is not taken into account in chase mode.
Known Issues:
  • The view point can see the player's body when passing through a line portal.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: ViewPos

Postby Major Cooke » Fri Dec 03, 2021 2:31 pm

Caligari87 wrote:Sorry for the bump. I'm curious if there's any progress on this pull request? I've started work on a project that makes significant use of the related ViewAngles feature and it's been extraordinarily useful thus far. I'd love to be able to go further with it.


So there's two ways this can be handled, that I can think of.

The first is the Actor way (chosen for the PR).
  • + Much easier to maintain
  • + Every actor has its own set of positions so book keeping requirements is far less.
  • - Adds onto every actor, increasing ram usage and save size.

The second is the Playerinfo way (which the first attempt was made with).
  • + Doesn't expand upon actor, meaning minimal increase in save size and RAM usage.
  • - Book keeping required for everything. External cameras, actors, views, you have to set up extra code in the event you want to use.

Additionally, there's one bug I haven't been able to squash out yet: seeing the body of the player through a view portal. I need help on this one.

-----

Ultimately what I need are opinions on how to handle this in the best way possible. Generally speaking, how would everyone else handle it? My first PR had it handled with PlayerThink() but that turned into a maintenance nightmare. I'm not even sure if I handled this part correctly in my very first attempt for dealing with offsets, or if it should've been done there at all.

So what I'd like to hear from fellow developers is how they would handle it - including when the camera isn't actually part of the player. (Help fixing the portal issue would also be massively appreciated but it's a cosmetic issue.) Input would be greatly appreciated.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: ViewPos

Postby Caligari87 » Fri Dec 03, 2021 2:52 pm

My own opinion on some of these is probably null since I'm not well versed in engine development. That said:

From what I can tell, the former ViewAngles was implemented as a part of Actor. In my opinion, for consistency it'd make most sense for this to follow that same paradigm. It's just weird to think about needing to mix the two like
Code: Select allExpand view
A_SetViewAngle(viewangle * 0.9, SPF_INTERPOLATE);
player.SetViewPos(player.viewpos * 0.9, SPF_INTERPOLATE); // or however it ends up working
I understand the concerns about increased memory usage, but when does that imply basically freezing the core actor code to new features entirely? Are we past that point? Is there anything on the horizon that could ever reduce that footprint?

As for portals, if I recall correctly the same problem happens with the quaking code, does it not? Sure it's annoying but at worst it's just a visual edge case / quirk that modders need to be aware of, and there's plenty of those.

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: ViewPos

Postby Major Cooke » Fri Dec 03, 2021 3:09 pm

Now I remember what the main concern is here.

As someone whose very much inferior on coding skills compared to Graf, I do not possess the vision of how he imagines it would be like - at least not entirely. I'd need to see more in-depth on how he would handle it so I can follow suit.

That's what this is primarily waiting on.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: ViewPos

Postby Rachael » Fri Dec 03, 2021 3:19 pm

What you can do is create an actor flag that explains if this is even needed, or not. If it isn't, then nothing is created. Remember to use a renderflag for this.

Actually, a flag really isn't needed if you just go for nullptr checks.

If it is, then you need to allocate new memory to a structure and create a pointer. Yes, you will have to use a class or struct for this. This allocation should be dynamic in order to reduce the effect that it has on the renderer.

All properties of this would go to this structure.

Remember also to check the actor destruction, that it checks this pointer and marks the newly allocated structure and deletes it if need be, when the actor will otherwise be destroyed.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: ViewPos

Postby Major Cooke » Fri Dec 03, 2021 5:05 pm

I actually think a flag would be necessary so you can shut it off without needing to destroy it, so the data can be preserved for instances where the player is still alive and intact. I'll give it a try.

I'm assuming it'll need to be done both on ZScript and engine side too. But I'm curious... In ZScript, why is it that some structs you can check for nulls on, but others you cannot?
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: ViewPos

Postby Rachael » Fri Dec 03, 2021 5:11 pm

That I don't know - but - it is really important to be able to check for nulls on this one.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: ViewPos

Postby Major Cooke » Fri Dec 03, 2021 5:47 pm

Spoke with phantom, got answers about that. And more. Quoted with permission.
PhantomBeta wrote:Structs are only nullable if they're passed by pointer
Only structs marked as native can be passes by pointer/reference, and they're always passed like that
And you can't instantiate them from ZScript AFAIK, it has to be done in the C++ code
I don't think dynamic creation would be feasible either, as ZScript doesn't have properties, and you can't make setting a flag or variable do anything other than setting it directly
Last edited by Major Cooke on Fri Dec 03, 2021 5:53 pm, edited 2 times in total.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: ViewPos

Postby Rachael » Fri Dec 03, 2021 5:52 pm

No you would definitely do the memory management on the C++ side.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: ViewPos

Postby Major Cooke » Fri Dec 03, 2021 5:54 pm

That was my plan to begin with as well, so I'll give it a shot.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007


Return to Code Submissions

Who is online

Users browsing this forum: No registered users and 0 guests