Weapon bobbing based on actual movement speed

[Sarah]

Great Nightflame. Let me know when you're done. Fixing this issue any way possible right now would be great.

[Ryan Cordell]

This is the gist of it. (Thanks goes to Apothem for helping with the Vertical weapon movement script.)

---

Code: Select all

/*
This lump documents some of the features used in the weapons.
*/

//=============================
//1 - Vertical weapon movement:
//=============================

//OFFSET = OFFSET (X,Y)
//X = Horizontal graphic shift.
//Y = Vertical graphic shift.

/*
EXPLANATION:
The basic principle is here. There are about two inventory items that need to be defined, 
for this to even work. In my case, I have given them the name of Action_JumpBob and Action_FallBob.
Self-explenatory, these are simple inventory items and only serve as mere things for the various 
actors and scripts to check for.
First up is the player who should do the checking for the two items, and that's only to fancy him up 
a bit. Such an example:
*/

/*
   Spawn:
	PLAY A 0
	PLAY A 0 A_JumpIfInventory("Action_JumpBob",1,"Jump")
	PLAY A 0 A_JumpIfInventory("Action_FallBob",1,"Fall")
	PLAY A 0 Thing_ChangeTID(0,334)
      PLAY A 1 A_TakeInventory("Action_Bob",1)
      Loop
   Jump:
      PLAY B 4
      Goto Spawn
   Fall:
      PLAY D 4
      Goto Spawn
   See:
      PLAY ABCD 4 A_GiveInventory("Action_Bob",1)
      Goto Spawn
*/

/*
EXPLANATION:
Now, Spawn checks if the player contains the Action_JumpBob item or the Action_FallBob item.
If he does contain either of these items, the player actor is soon forced into the corresponding 
states, Jump for JumpBob, and Fall for FallBob.
You might notice that Spawn and See also reference another Action_Bob actor. This will be handled 
with the next subject - Horizontal weapon movement.

Second up, and about the most important if you're aiming for vertical bobbing like Blood has, is 
that you check for the two items within the Ready state of the weapon. The weapon is already OFFSET 
so there will be no empty gaps between the weapon and the screen, as it sometimes has happened. Even 
to me.

Note how the OFFSET parameter and the A_WeaponReady action function are seperate. It seems that the 
two don't seem to work together, so they have to be defined seperately. However, we also want the 
player to be able to fire at whatever height his weapon is at, so we force in a 'slave' frame, 
basically, a zero duration frame that latches onto the OFFSETed frame like a parasite, which now 
allows the weapon to bob horizontally (Via Doom's original horizontal bobbing) and do other things, 
such as deselect, select, fire, reload, etc.
Down below is the vertical bobbing already defined. Some tweaks may need to be made for every weapon 
seperately, but it serves it's purpose well, and serves to keep you away from the heartache I had to 
go through. :P

You will soon notice that Falling has two stages to it, and a check to see Action_FallBob is absent 
in the state too, which might seem odd, but listen..
The script which will be shown soon takes away the item when the player is standing. The Falling state 
checks if the item is gone when the player is falling or standing, and when he's standing, it jumps 
towards the second stage, which basically simulates the recoil the player has from landing on the ground.
Adding additional frames seems to make it loop between the two while falling, however, something I haven't 
been able to fix yet.
*/

/*
   Ready:
	SPRITE FRAME 0 A_JumpIfInventory("Action_JumpBob",1,"Jumping")
	SPRITE FRAME 0 A_JumpIfInventory("Action_FallBob",1,"Falling")
      SPRITE FRAME 2 A_WeaponReady
	SPRITE FRAME 0 OFFSET (0,32)
      Loop
   Jumping:
      SPRITE FRAME 1 OFFSET (0,35)
	SPRITE FRAME 0 A_WeaponReady
      SPRITE FRAME 1 OFFSET (0,32)
	SPRITE FRAME 0 A_WeaponReady
      SPRITE FRAME 2 OFFSET (0,30)
	SPRITE FRAME 0 A_WeaponReady
      SPRITE FRAME 2 OFFSET (0,27)
	SPRITE FRAME 0 A_WeaponReady
      SPRITE FRAME 2 OFFSET (0,22)
	SPRITE FRAME 0 A_WeaponReady
      SPRITE FRAME 2 OFFSET (0,18)
	SPRITE FRAME 0 A_WeaponReady
      SPRITE FRAME 2 OFFSET (0,22)
	SPRITE FRAME 0 A_WeaponReady
      SPRITE FRAME 2 OFFSET (0,27)
	SPRITE FRAME 0 A_WeaponReady
      SPRITE FRAME 2 OFFSET (0,30)
	SPRITE FRAME 0 A_WeaponReady
      SPRITE FRAME 2 OFFSET (0,32)
	SPRITE FRAME 0 A_WeaponReady
      SPRITE FRAME 2 OFFSET (0,38)
	SPRITE FRAME 0 A_WeaponReady
      Goto Ready
   Falling:
	SPRITE FRAME 0 A_JumpIfInventory("Action_FallBob",0,5)
      SPRITE FRAME 3 OFFSET (0,42)
	SPRITE FRAME 0 A_WeaponReady
      SPRITE FRAME 3 OFFSET (0,45)
	SPRITE FRAME 0 A_WeaponReady
      Goto Falling+3
      SPRITE FRAME 3 A_WeaponReady
	SPRITE FRAME 0 OFFSET (0,45)
      Goto Ready
*/

/*
EXPLANATION:
These are the two Vertical movement items. Action_JumpBob and Action_FallBob.
Action_FallBob inherits the necessary parameters from Action_JumpBob solely to conserve 
the size of the lump.
*/

/*
ACTOR Action_JumpBob : Inventory
{
    Inventory.MaxAmount 1
      +INVENTORY.UNDROPPABLE
      - INVBAR
}

ACTOR Action_FallBob : Action_JumpBob
{}
*/

/*
EXPLANATION:
This is the script which does the math for the jumping, standing and falling. It's there to 
check if the player is jumping, falling or standing. Dependening on what "Z axis" state it is 
in, the script gives and takes away the bobbing items fittingly. If he's jumping, there'll be 
no Falling item. If he's falling, there'll be no Jumping item. If he's standing, there'll be 
no Jumping or Falling item.
The PRINT messages there are solely for debugging purposes to see if the script works in the 
first place.

You will spot that the Z distance algorithm is stored inside the ZCHECK_VAR1, a shortened 
version of "Z axis checking variable no. 1", basically. The only reason it's stored in an 
int, instead of being defined every time in the While and If clauses, is solely to spare the 
size of the lump.
This is the most important part of the vertical weapon movement. You WILL need this script in 
order for the feature to even work.
*/

/*
SCRIPT 253 ENTER
{
/*
The basic premise of this script is that in works in several ways:
If the player is on the ground and jumps, it adds the jumping item to his inventory.
If the player is in the air and jumps, it should do nothing.
If the player is falling, it adds the falling item to his inventory.
*/

   int zcheck_var1 = (GetActorZ(0) == GetActorFloorZ(0));
   int zcheck_var3;

   while(zcheck_var1 == zcheck_var3)
   {
      TakeInventory("Action_JumpBob",1);
      TakeInventory("Action_FallBob",1);
//      print(s:"You are standing. Arr!");

      zcheck_var3 = GetActorZ(0);

      if(zcheck_var1 < zcheck_var3) //Jumping.
      {
         TakeInventory("Action_FallBob",1);
         GiveInventory("Action_JumpBob",1);
//         print(s:"You are jumping. Woot.");
      }
      if(zcheck_var1 > zcheck_var3) //Falling.
      {
         TakeInventory("Action_JumpBob",1);
         GiveInventory("Action_FallBob",1);
//         print(s:"You are falling. Wee.");
      }
      zcheck_var1 = zcheck_var3;
      delay(1);
   }
}
*/

//===============================
//1 - Horizontal weapon movement:
//===============================

//OFFSET = OFFSET (X,Y)
//X = Horizontal graphic shift.
//Y = Vertical graphic shift.

/*
EXPLANATION:
This is similar to the Vertical weapon movement feature, however, less complicated since it does 
not need to check for Z axis differences from the player and the ground and plot out things accordingly.
Instead, it only checks whether an item, in this case, Action_HorizontalBob, is in the player's moving 
state, defined as See, and if it is, it does nothing for the player actor. However..
Ofcourse, the Spawn state is defined as the player standing STILL, so it's only logical that it takes 
away the Action_HorizontalBob item to prevent the weapon from moving.
However, this particular feature requires that the weapons are all put on a flag that dictates it to 
not use the Doom engine's standard bobbing.
*/

/*
   Spawn:
	PLAY A 0
	PLAY A 0 A_JumpIfInventory("Action_JumpBob",1,"Jump")
	PLAY A 0 A_JumpIfInventory("Action_FallBob",1,"Fall")
	PLAY A 0 Thing_ChangeTID(0,334)
      PLAY A 1 A_TakeInventory("Action_HorizontalBob",1)
      Loop
   Jump:
      PLAY B 4
      Goto Spawn
   Fall:
      PLAY D 4
      Goto Spawn
   See:
      PLAY ABCD 4 -> A_GiveInventory("Action_Bob",1) <-
      Goto Spawn
*/

/*
EXPLANATION:
This section defines the Action_HorizontalBob item, but it is, however, inheriting it's properties
from it's 'mother' actor, that being Check_Base. It has all the necessary parameters for Action_Bob
to successfully work.
*/

/*
ACTOR Check_Base : Inventory
{
    Inventory.Amount 1
    Inventory.MaxAmount 1
      +INVENTORY.UNDROPPABLE
}

ACTOR Action_HorizontalBob : Check_Base
{}
*/

/*
EXPLANATION:
Just like the Vertical weapon movement chapter, all you have to do is define the horizontal movement of 
the weapon via the OFFSET parameter and remember, that you should attach the A_WeaponReady action function 
to it via a zero duration frame, otherwise it won't work.
Ofcourse, you have to take into account how the weapon works if you want the bobbing to work right, as is 
the case with the Chainsaw's particular timing for it's idle nature.
*/

/*
   Ready.Bob:

	SAWG C 0 A_WeaponReady
	SAWG C 0 A_PlaySoundEx("weapons/sawidle","Weapon",0)

      SAWG D 4 OFFSET (25,50)
	SAWG D 0 A_WeaponReady

      SAWG C 4 OFFSET (30,55)
	SAWG C 0 A_WeaponReady
	SAWG C 0 A_PlaySoundEx("weapons/sawidle","Weapon",0)

      SAWG D 4 OFFSET (35,50)
	SAWG D 0 A_WeaponReady

      SAWG C 4 OFFSET (40,45)
	SAWG C 0 A_WeaponReady
	SAWG C 0 A_PlaySoundEx("weapons/sawidle","Weapon",0)

      SAWG D 4 OFFSET (45,35)
	SAWG D 0 A_WeaponReady

      SAWG C 4 OFFSET (40,45)
	SAWG C 0 A_WeaponReady
	SAWG C 0 A_PlaySoundEx("weapons/sawidle","Weapon",0)

      SAWG D 4 OFFSET (35,50)
	SAWG D 0 A_WeaponReady

      SAWG C 4 OFFSET (30,55)
	SAWG C 0 A_WeaponReady
	SAWG C 0 A_PlaySoundEx("weapons/sawidle","Weapon",0)

      SAWG D 4 OFFSET (25,50)
	SAWG D 0 A_WeaponReady

      SAWG C 4 OFFSET (25,0)
	SAWG C 0 A_WeaponReady
	SAWG C 0 A_PlaySoundEx("weapons/sawidle","Weapon",0)
      Goto Ready
*/

[Nash]

Look at all the manual offsetting... it'll never be as smooth as the in-game code's interpolated bobbing...

[Ryan Cordell]

You know who to blame.

[HotWax]

If it's something the community wants, it will be put in.

See, that's where you assume wrong. You could find a load of feature suggestions that haven't made it in despite demand from the community. In almost every case, you'll find that the request was overly-ambitious, and usually the thread is bloated out of control by somebody wanting to over-complicate an otherwise simple suggestion. Every time you post in this thread, you reduce any chance of the feature making it in the foreseeable future.

When it comes to feature suggestions, KEEP IT SIMPLE, STUPID!

[XutaWoo]

KEEP IT SIMPLE, STUPID!

This could also be applied to Blade's custom bobbing. Sheesh.

[Snarboo]

I don't see how having some way to customize weapon bobbing is too much to ask. I would like to see some way to set it either by player class or by the weapon itself. I mean, there's even a DONTBOB flag that disables it entirely, and it can be done on a per weapon basis.

On an unrelated note, EDGE allows for custom bobbing per weapon, but I'm not sure how vastly EDGE differs from ZDoom, or even how Doom handles it to begin with.

[XutaWoo]

Doom handles it to begin with.

I'm pretty sure if the weapon is calling A_WeaponReady and the player is moving, is just draws the weapons sprite somewhere else.

[skadoomer]

Assuming that bobbing all works on arcs (sin cos?), why not just make a few custom properties of weapons to define how big an arc is, how high its radius is (this could also be used to make upwards and downwards bobbing depending if the value is positive or negative) and a time variable to say how far the object moves along the curve when the player is in motion. A multiplier can be used to determine how much faster the weapon moves on the arc whether running or walking is enabled / disabled. I know 4 extra args in a weapon isn't exactly the simplest method, but it would at least allow for maximum customization in this area.

Likewise, we already have a console based movebob value that can be used for those that need to turn down all weapon bobbing. In case of obnoxious weapon mods, the user can just turn off the movement or teak it to their liking.

[MDenham]

On an unrelated note, EDGE allows for custom bobbing per weapon, but I'm not sure how vastly EDGE differs from ZDoom

A lot.

[bagheadspidey]

The basic premise of this script is that it works in several ways

I lol'd

[Sarah]

If it's something the community wants, it will be put in.

See, that's where you assume wrong. You could find a load of feature suggestions that haven't made it in despite demand from the community. In almost every case, you'll find that the request was overly-ambitious, and usually the thread is bloated out of control by somebody wanting to over-complicate an otherwise simple suggestion. Every time you post in this thread, you reduce any chance of the feature making it in the foreseeable future.

When it comes to feature suggestions, KEEP IT SIMPLE, STUPID!

You know, instead of getting pissy with me, you could just tell me to shut up.

On a lighter note, yeah the code seems a bit extreme but it would work for now. And this may sound unrelated, but has anybody played Foreverhood? They way it is set up is that GZDoom is packaged with the game so that the config file that sets the player bob only effects that version of GZDoom. This means we can set the bob value to whatever we want and not effect players other games. This works. I've set my game up on this format and it works really well.

By the way, off topic completely, but what are source ports dependent on. I mean, what files in the IWAD are required for a mod to run?

[XutaWoo]

MAP01.

[Project Shadowcat]

If it's something the community wants, it will be put in.

See, that's where you assume wrong. You could find a load of feature suggestions that haven't made it in despite demand from the community. In almost every case, you'll find that the request was overly-ambitious, and usually the thread is bloated out of control by somebody wanting to over-complicate an otherwise simple suggestion. Every time you post in this thread, you reduce any chance of the feature making it in the foreseeable future.

When it comes to feature suggestions, KEEP IT SIMPLE, STUPID!

You know, instead of getting pissy with me, you could just tell me to shut up.

I was going to say that you weren't supposed to take this personally, but rather, everyone needs to listen.

[Sarah]

MAP01.

That doesn't make any sense. All of the mods I've ever played have had their own MAP01.