Welcome to the ZDoom Forums!

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.

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 )

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.

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.

I've opened the submission for review, and the PR's merged with QZDoom. The next update will be out soon for testing.

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.

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.

That's the idea!

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

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.

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.

@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.

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. 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.

It could certainly be used for that application yes, among others.

I assume this allows for proper leaning mechanics for stealth-focused games? If so, I hope this gets added soon.

Hell, if that's the easiest way to do it then I'm all for it - but if that requires GC, then I'm not entirely certain what to do with it so for now, I'll go with what you posted. Thanks!