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

Re: ViewPos

Postby Rachael » Sat Dec 04, 2021 8:12 pm

Make sure when you use the "new" keyword that you are initializing the struct. (Zeroing and nulling out things before you use them)

It's a lot easier if you convert it to a class (might not be required? I don't know. they aren't much different though) and create a function such as FViewPosition::FViewPosition() that does this for you. Naming a function after its class name means that the function will run when a new instance is instantiated (such as with the "new" keyword).

You can also put the initializers in the struct directly, as far as I know this should work. It is a shortcut to the above.

i.e.
Code: Select allExpand view
struct SomeStruct
{
   int someVar = 0;
   float someFloat = 0.0;
   // .. etc
}


It's extremely important you use initializers. A lot of bugs in GZDoom are caused by forgetting to initialize variables like this before they are used. And that is quadruply important when you use pointers, as forgetting to initialize those causes untold hours of chaos and frustration for programmers and users alike.
User avatar
Rachael
^ walking stack of unfinished projects ^
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: ViewPos

Postby Major Cooke » Sat Dec 04, 2021 11:53 pm

@Caligari87 & @Cherno: Leaning corners, or having really big actors with head locations elsewhere, all while still having PSprites that are visible and keeping the body invisible only to the player.

Of course, this doesn't apply if third person mode is enabled.

@Rachael: Thanks for the tip. I'm going with a struct.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: ViewPos

Postby Major Cooke » Sun Dec 05, 2021 4:27 am

Also, if anyone has any ideas on how to handle portals (for disabling the original player's sprite) in particular, let me know. Currently I'm working on a inverted trace (there's two - first one sets the camera position, and the second one will be performed inverted to find the player) where, if it hits the player in the direction it originally came from, it'll disable the sprite. Specifically, it'll let the other sprites continue to show the player.

Not sure if it'll work but it's the only theoretical solution I've got so far.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: ViewPos

Postby Cherno » Sun Dec 05, 2021 6:12 am

Major Cooke wrote:@Caligari87 & @Cherno: Leaning corners, or having really big actors with head locations elsewhere, all while still having PSprites that are visible and keeping the body invisible only to the player.


Praise be to ye :wub:

To specify: What I would like to see is that the playerpawn actor itself keeps it's position (behind a corner), so enemies can't see it, but the camera/viewpoint is offset so the player can look around the corner and spot the enemies. Bonus points for keeping PSprites. Not sure how weapon attack origins would be handled, though.
Last edited by Cherno on Sun Dec 05, 2021 9:58 am, edited 1 time in total.
User avatar
Cherno
 
Joined: 06 Dec 2016

Re: ViewPos

Postby Major Cooke » Sun Dec 05, 2021 9:04 am

That's the idea! ;)
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: ViewPos

Postby Caligari87 » Sun Dec 05, 2021 1:08 pm

Cherno wrote:Not sure how weapon attack origins would be handled, though.

Basically you'll have to manage this manually, if you're designing a mod that has such a feature. I'm not entirely sure on this point, but assuming the ViewPos is synched to the multiplayer gamesim and not clientside-only/renderer-only, the simplest way would be to have your weapons check the owner's view position offset when they fire. If for some reason it ends up not being synched, you could do it the opposite way and have a custom player/weapon system that specifies an offset for firing when leaning, and then sync the ViewPos to that. Either way, it's perfectly doable.

Personally for my application, I'm going to try and use it only for visual effects such as custom view bobbing and recoil, and thus hopefully avoid issues with hijacking the player's aiming or movement controls, which is a major reason people complain about these effects. Also makes adding a camera effects scaling slider a lot easier, when otherwise such a thing could have gameplay effects for something that's supposed to be visual-only.

For example, this is what I've done for movement bobbing so far using ViewAngle/ViewPitch/ViewRoll. Notice how the player's "reticle" (which is projected into the world as an actor) remains pointed at the same spot even with (admittedly extreme) camera movement. ViewPos would be even better since I wouldn't have to "turn" the camera nearly as much to achieve similar effects.


8-)
User avatar
Caligari87
User Accounts Assistant
 
Joined: 26 Feb 2004
Discord: Caligari87#3089
Github ID: caligari87

Re: ViewPos

Postby Major Cooke » Sun Dec 05, 2021 10:01 pm

Well, here we go. Still a draft because I want to finalize and get portals working.

Right now, TraceBack isn't behaving how I want it to. What I'm trying to do is in this order.

  • Trace to the new location of where the camera will end up
  • Set the camera out there, wherever it may be
  • Perform TraceBack() - specifically, a Trace that goes from the camera directly in the opposite direction it came from
  • Hitting the player through that line will indicate to the engine the sprite should disappear

But the trace isn't hitting the actor. I'm uploading two files for testing purposes.
You do not have the required permissions to view the files attached to this post.
Last edited by Major Cooke on Mon Dec 06, 2021 3:03 am, edited 1 time in total.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: ViewPos

Postby Major Cooke » Mon Dec 06, 2021 3:03 am

I've opened the submission for review, and the PR's merged with QZDoom. The next update will be out soon for testing.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: ViewPos

Postby Caligari87 » Tue Dec 07, 2021 4:09 pm

Did some basic testing in QZDoom and so far it seems really solid at least for my use case (camera bobbing). I'll post a video a bit later when I've had a chance to fine-tune the effect.

Doing a nullcheck for struct ViewPos struct is a new paradigm for me, but a welcome one if it means more performant code under-the-hood. I also had to code-dive to find the ViewPos.Offset member, but that's more a future documentation issue than anything.

Overall quite straightforward from the scripting perspective and no unexpected issues in my limited testing. Will report back if I find anything else but I'm really excited to see this merged.

8-)
User avatar
Caligari87
User Accounts Assistant
 
Joined: 26 Feb 2004
Discord: Caligari87#3089
Github ID: caligari87

Re: ViewPos

Postby Major Cooke » Tue Dec 07, 2021 4:49 pm

Heh, I know. Weird right?

But if this indeed does optimize things, then I'm all the more for it. But at the same time I can't help wonder if there's a better way to do this. I would've gone with a struct, but that would mean having to write a new serializer specifically for it and that's not something I know how to do. Looks complex as hell.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: ViewPos

Postby Caligari87 » Tue Dec 07, 2021 5:33 pm

Slightly off-topic, but could these optimizations be backported to other members of AActor? Having the data structures not "exist" until called for?

I imagine for existing stuff that's used without checking nullpointers, it would require some kind of special handling to intercept a request and initialize the structure on-the-fly. Alternatively, maybe gate the optimiztaions behind a new ZS version if possible? So anything using <=v4.7 (for example) initializes the whole actor but anything newer doesn't initialize the members until called for.

(Sorry in advance I'm not a programmer and I know I'm probably not using the right "language" to describe this but I trust y'all are smart enough to get what I'm saying :P )

8-)
User avatar
Caligari87
User Accounts Assistant
 
Joined: 26 Feb 2004
Discord: Caligari87#3089
Github ID: caligari87

Re: ViewPos

Postby Major Cooke » Tue Dec 07, 2021 7:29 pm

If Graf invents a way to make it so accessing a variable belonging to a specific subclass/struct where it auto-creates those as needed, then I'd definitely say that's in the future. It'd be needed for backwards compatibility at the very least. Unless we finally say "fuck it" and just can the compatibility for GZDoom v5. [1]

This could optimize a lot of things, cutting out a lot of actor checks in the code itself by simply checking for specific 'packages' if you will and simply not operating if it's not there - including states! If you have an actor but can program everything within the tick function and don't need it rendered, I imagine you could make do without the States package (but in that case you'd basically be using a Thinker class, but with a position, etc).

But I am just theorizing on a way this could go, including having dependency packages. That would allow it to be much more optimal on RAM and saving, but I don't expect the optimizations to be all that more significant beyond that.

Also I don't even know if this is what Graf meant in particular, but if it is, it certainly took me a lot of effort to make this stuff. So, this route definitely needs a streamlined system if there's a better way to go about it. I have my doubts I did this perfectly and there's likely other things I could have done such as the struct route (less overhead, but requires a serializer to be written for it), but I'm not advanced enough to know that. Hopefully Rachael chimes in too and confirms whether I nailed the idea down properly or not.

[1] - DECORATE made actors would by nature include all classes needed as usual but ZScript would not. Modders would pick and choose what they need there.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Previous

Return to Code Submissions

Who is online

Users browsing this forum: No registered users and 0 guests