Ability to tweak overlay bobbing
Moderator: GZDoom Developers
- Marisa the Magician
- Posts: 3886
- Joined: Fri Feb 08, 2008 9:15 am
- Preferred Pronouns: She/Her
- Operating System Version (Optional): (btw I use) Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Vigo, Galicia
- Contact:
Ability to tweak overlay bobbing
I was wondering if it's possible to add something to set overlays in weapons to bob in a different way than the main layer. Take for example the first person hands in Duke Nukem 3D when shrunk, where each hand bobs at a different phase when walking, that's the kind of behaviour I'm looking for.
Re: Ability to tweak overlay bobbing
You can already add as many overlays as you want. This is already possible (although it is DIY)
- Marisa the Magician
- Posts: 3886
- Joined: Fri Feb 08, 2008 9:15 am
- Preferred Pronouns: She/Her
- Operating System Version (Optional): (btw I use) Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Vigo, Galicia
- Contact:
Re: Ability to tweak overlay bobbing
Yeah but I'm talking about bobbing, not offsets.
Re: Ability to tweak overlay bobbing
Nash means "you can make any bobbing you can imagine, if you add >9000 ofsets, each part of which be a part of custom bobbing animations".
I hope I wrote that right and understandable.
I hope I wrote that right and understandable.
Re: Ability to tweak overlay bobbing
Yeah that's what I meant... make your own overlays and you can do any kind of bobbing patterns by yourself. "Bobbing" is technically speaking just (mathematically and with phase) offsetting, anyway o_O.Apeirogon wrote:Nash means "you can make any bobbing you can imagine, if you add >9000 ofsets, each part of which be a part of custom bobbing animations".
I hope I wrote that right and understandable.
The sprinting hand in my videos is pretty much bobbing except it's more obvious in Y than in X, so it doesn't have a "U" pattern.
- Marisa the Magician
- Posts: 3886
- Joined: Fri Feb 08, 2008 9:15 am
- Preferred Pronouns: She/Her
- Operating System Version (Optional): (btw I use) Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Vigo, Galicia
- Contact:
Re: Ability to tweak overlay bobbing
Yeah but I DON'T want to do it like that. I want to take advantage of the already existing bobbing mechanic. Why should I implement my own bobbing in the weapon states themselves when I only want this to work exactly like the already existing bobbing except with, say, giving some overlay a different bobbing phase than the main weapon so they bob at a different time within the ready state sequence without me having to handcraft some convoluted custom bobbing system in the zscript side?
Re: Ability to tweak overlay bobbing
I feel like we shouldn't need to remind longtime forum regulars about the old "don't suggest convoluted workarounds" rule at this point. C'mon.
Re: Ability to tweak overlay bobbing
No, I wasn't suggesting a workaround; rather I did not fully understand what the OP wanted.
It literally stated "hands like Duke Nukem being shrunk" so I offered a solution that the engine already allows. Because I know if I SPECIFICALLY wanted "hands like Duke Nukem with inversed bobbing phase" it would get No'd for being too specific, or rather [DIY]
It literally stated "hands like Duke Nukem being shrunk" so I offered a solution that the engine already allows. Because I know if I SPECIFICALLY wanted "hands like Duke Nukem with inversed bobbing phase" it would get No'd for being too specific, or rather [DIY]
Re: Ability to tweak overlay bobbing
Sorry, no -- you definitely were. The OP was quite clear about wishing to use the existing bobbing mechanics -- scripting it via offsets is a workaround, full stop.Nash wrote:No, I wasn't suggesting a workaround
I'd normally understand the "whoops! I misread" angle, 'cause that happens, but you're doubling down on your mistake here.
Re: Ability to tweak overlay bobbing
No man, I really did not understand what MK wanted at first. When I posted my reply, I really thought it was one of those "you can already do that".
- Marisa the Magician
- Posts: 3886
- Joined: Fri Feb 08, 2008 9:15 am
- Preferred Pronouns: She/Her
- Operating System Version (Optional): (btw I use) Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Vigo, Galicia
- Contact:
Re: Ability to tweak overlay bobbing
I'm not the best at explaining myself.
Re: Ability to tweak overlay bobbing
I suppose we'd best chalk it down to a minor "oopsie" and move on. I'm getting too confuzzled about this.
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: Ability to tweak overlay bobbing
What I'd like to know is how bobbing works at all... there seem to be like 9000 different components in it, some apparently exposed to ZS and some not, and it's not at all clear how they interact to ultimately get the head bobbing and weapon bobbing we see on the screen.
Re: Ability to tweak overlay bobbing
View bobbing and weapon bobbing are technically two separate things. I don't know much about the former, but the latter is controlled in P_BobWeapon, which is called by the renderers when drawing HUD sprites. The function checks if the player is carrying a weapon that's in a bobbable state (i.e. has just called A_WeaponReady without WRF_NOBOB set), inspects the player's current speed, and does some funky math to determine the bob position.
The bob properties on the Weapon class (BobStyle et.al) are things that influence the "funky math". BobStyle selects from a set of formulas (via an ugly switch statement; for shame, past-me!), and BobRange/BobSpeed are fed as "parameters" into the formula along with the player's speed and the current leveltime to figure out where the weapon should be drawn. That's about it.
It's all a bit rudimentary since the bob properties were uber-basic things I added ages ago, but there are essentially two big ways to extend this feature:
The bob properties on the Weapon class (BobStyle et.al) are things that influence the "funky math". BobStyle selects from a set of formulas (via an ugly switch statement; for shame, past-me!), and BobRange/BobSpeed are fed as "parameters" into the formula along with the player's speed and the current leveltime to figure out where the weapon should be drawn. That's about it.
It's all a bit rudimentary since the bob properties were uber-basic things I added ages ago, but there are essentially two big ways to extend this feature:
- Add bobbing properties to PSPrites (i.e. overlay layers), then add a function to set them a la A_OverlayFlags (this is what Marisa's asking for).
- Add a BobWeapon virtual function (UI scope). This would let users implement their own bobbing patterns freely.
- nazakomu
- Posts: 131
- Joined: Wed Nov 30, 2016 12:51 am
- Graphics Processor: nVidia with Vulkan support
Re: Ability to tweak overlay bobbing
This is an interesting topic for me, since recently, I've been working on PSprites and such. As far as I can tell, currently they're somewhat difficult to work with, and that can definitely be my fault for not being adept with ZScript.
The way I'm handling the bobbing and other PSprite work is in an override of Tick() in the PlayerPawn class I have, and it seemingly is the worst place to do it as there is an atrocious bug that comes out of doing it (i.e. when the player moves while entering their death state, the game crashes).
A code example is:
The reason the crashing seems to be happening is because of the way I'm accessing the PSprite (let psp = player.GetPSprite(PSP_WEAPON)). It has caused crashing before if just openly put in the Tick() override without any checks, too.
I alternatively, tried transitioning the bobbing itself into the weapon instead, to which didn't work out so well, again probably due to me not being so experienced with it..
Perhaps, I'm really just doing things wrong.
The way I'm handling the bobbing and other PSprite work is in an override of Tick() in the PlayerPawn class I have, and it seemingly is the worst place to do it as there is an atrocious bug that comes out of doing it (i.e. when the player moves while entering their death state, the game crashes).
A code example is:
Code: Select all
override void Tick()
{
if (!player || !player.mo || player.mo != self)
{
Super.Tick();
return;
}
// The CheckWeaponSelected function is written elsewhere, but is the exact same function from the status bars. It is used as a check to make sure I can do things with specific weapons, such as changing the speed and intensity.
if (CheckWeaponSelected("Pistol"))
{
let psp = player.GetPSprite(PSP_WEAPON); // I also tried player.FindPSprite, to which was no success.
if (player.onground)
{
// Bobbing gets done here.
}
}
}
I alternatively, tried transitioning the bobbing itself into the weapon instead, to which didn't work out so well, again probably due to me not being so experienced with it..
Perhaps, I'm really just doing things wrong.