[Closed] [needs randi]Overlays for Actors

Moderator: GZDoom Developers

Re: Overlays for Actors

Postby Rachael » Sat Jul 09, 2016 11:25 am

I guess technically the issue with putting it on players is it would inevitably be overridden by the player's weapon - if not immediately, very soon anyway.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: Overlays for Actors

Postby Major Cooke » Sat Jul 09, 2016 1:30 pm

Bit of a long post, sorry if I'm rambling or missing something. Sleepy headed...

Weapons can override player called overlays just like player called overlays can override weapons. The difference between the two is, those created by weapons are destroyed when switching to another weapon.

Inventory ones, same deal. If the calling item vanishes, the overlays are gone too.

However, the player body can only create overlays belonging to it. I.e. If a weapon were to try making an overlay based on a state belonging to the player and not the weapon itself, it wouldn't work.

Also, the only shared piece between weapons and players for overlays is whether a layer number is occupied or not. So if you have an already active layer on 2000 set by the weapon, the player can still perform if (A_Overlay("Null",2000,true)) to see if that spot's taken or not without actually invoking a new overlay.

As long as you don't use the internal hardcoded layers [-1, 1] and 1000 (flash state) (unless you know what you're doing and proceed with great care), you'll be fine.

Easiest way to avoid overriding any is to make a constant enum starting at 2.
Code: Select allExpand view
enum
{
    Overlay_ChaingunBarrel = 2, //Will be free from accidental overriding.
    Overlay_ChaingunCounter, //Auto increments by one every time. So 3
    Overlay_ChaingunFire, // 4
};

Because actors themselves don't have overlays currently, there's no internally defined hard coded layers to worry about (should this get in) because they were never meant to have weapons and stuff. :P
User avatar
Major Cooke
Do unto others as you would have unto you. Judge yourself first.
 
Joined: 28 Jan 2007

Re: Overlays for Actors

Postby ZzZombo » Sun Jul 10, 2016 9:06 am

Do these overlays tick down 1) w/o being shown to a player at all, 2) after being shown, but the thing is no longer used as a camera? I mean, does the moment the animation starts depend on when the actor is used as a camera, and whether it restarts each time it is used as such, or it's not dependent on player spying through it at all?
ZzZombo
 
Joined: 16 Jul 2012

Re: Overlays for Actors

Postby Major Cooke » Sun Jul 10, 2016 9:08 am

#1 indeed. They act on their own regardless of the player viewing through them or not.
User avatar
Major Cooke
Do unto others as you would have unto you. Judge yourself first.
 
Joined: 28 Jan 2007

Re: Overlays for Actors

Postby NeuralStunner » Sun Jul 10, 2016 9:24 am

Major Cooke wrote:#1 indeed. They act on their own regardless of the player viewing through them or not.
So as with a player overlay, they can run concurrent code. That has some awesome potential, even for overlays that will never be viewed by a player. (It also has potential to raise some "waiting for Doomscript" eyebrows, so I'm going to be careful. :P )
User avatar
NeuralStunner
An Exercise in Self-Indulgence
 
 
 
Joined: 21 Jul 2009
Location: Indiana, USA
Discord: NeuralStunner#1293
Operating System: Windows Vista/7 64-bit

Re: Overlays for Actors

Postby Major Cooke » Sun Jul 10, 2016 9:30 am

To be perfectly honest, Leonard2's overlay submission enabled player actors to do so. I see no reason why actors cannot. It would eliminate a majority of code for me to require external actors for modifying the base actor, since it would all be done internally. Less actors around, less decrease in performance.

For example, timers. Some timers must be managed the entire time such as cooldowns. Let those be handled in an overlay instead of having to make a timer to decrease timers based on what the hell they're doing. I don't expect everyone to understand that but whenever an actor changes states such as going from See to Missile, they may have been idly counting down a user_cooldown variable for example. If they switch to a missile state that doesn't have a cooldown they'd also have to currently perform more cooldown adjustments to maintain accuracy.

Overlays can offload all that crap with a simple thing such as this:

Code: Select allExpand view
Overlay.Cooldown:
TNT1 A 5
{
    if (user_cooldown > 0)
    { A_SetUserVar(user_cooldown, user_cooldown - 1); }
}
Loop
User avatar
Major Cooke
Do unto others as you would have unto you. Judge yourself first.
 
Joined: 28 Jan 2007

Re: Overlays for Actors

Postby Major Cooke » Sun Jul 10, 2016 1:52 pm

Ironically, overlays have also allowed me to get rid of a ton of ACS hacks. Thank god...
User avatar
Major Cooke
Do unto others as you would have unto you. Judge yourself first.
 
Joined: 28 Jan 2007

Re: Overlays for Actors

Postby Major Cooke » Sat Jul 16, 2016 7:44 am

Leonard's done some overhauling on the overlays for actors, which I approve of. Leonard?
User avatar
Major Cooke
Do unto others as you would have unto you. Judge yourself first.
 
Joined: 28 Jan 2007

Re: Overlays for Actors

Postby Leonard2 » Sat Jul 16, 2016 8:08 am

I did this in a much more general way.
This should end up being better than just having a boolean that changes the behavior for players and having duplicate methods for both the player struct and aactor class.
It also avoids some issues that I've spotted with MC's current pull request.

Here is a link to the changes.
No pull request yet because there are still some issues left regarding psprites right now that are unrelated to this and that I think would better be fixed before this can be merged (the interpolation stuff is just an example).
I will make a pull request once those issues are solved (soon, I already know how to fix the rest).

I of course tested this as much as I could (the old weapons, mods, savegame compatibility, etc...)
User avatar
Leonard2
 
Joined: 14 Aug 2012

Re: Overlays for Actors

Postby Major Cooke » Sat Jul 16, 2016 9:38 am

Only curious but what problems were present?
User avatar
Major Cooke
Do unto others as you would have unto you. Judge yourself first.
 
Joined: 28 Jan 2007

Re: Overlays for Actors

Postby Graf Zahl » Thu Jul 28, 2016 1:50 am

Just a note:

I will not add this without input from Randi.

And the comments from Leonard are not clear: Are you planning to supersede this with a better approach? In which case I might outright close this thread.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Overlays for Actors

Postby Leonard2 » Thu Jul 28, 2016 4:33 pm

To answer you Graf, the goal stays the same: grant access to overlays for non-player actors.
Here's a pull request to the changes that I rebased to the current head.
User avatar
Leonard2
 
Joined: 14 Aug 2012

Re: [needs randi]Overlays for Actors

Postby Major Cooke » Sat Nov 12, 2016 9:44 pm

With the way ZScript is going, perhaps some form of detecting and/or accessing overlays could be implemented?

This also makes me wonder what happens if someone were to perform target.A_Overlay(yadda yadda)... Sounds like it might need addressing perhaps?
User avatar
Major Cooke
Do unto others as you would have unto you. Judge yourself first.
 
Joined: 28 Jan 2007

Previous

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: Bashe, Bing [Bot] and 2 guests