Which of these chainsaw animations is the correct one?

[DemonicSavage]

I made two videos demonstrating the differences in chainsaw animation between GZDoom and PrBoom+.

 

 

Which one is the "correct" one? PrBoom+'s look choppy so I assume it's the one that's wrong.

Is there a way to fix the one that's "wrong"?

[Firebert]

From my very uninformed knowledge, the choppy animation you see in PrBoom+ has something to do with the weapon states and changing it would mess up demo compatability.

[DemonicSavage]

Thanks for the reply.

 

I ended up installing Crispy Doom and the behavior is identical to PrBoom+ in that regard.

So it seems that GZDoom is "wrong" here.

 

Now that I think about it, I should've just compared to Crispy or Chocolate instead of opening this thread.

[fabian]

As a side effect, if you enable reduced bobbing or weapon sprite centering during attacks in Crispy Doom, the chainsaw idle animation will get smoothed as well. 

[LexiMax]

The problem comes from the fact that the chainsaw animation contains frames of animation that are greater than 1 frame.  For some reason, the sway update is not independent of the animation update, so if the weapon animation takes 4 frames, the sway animation takes 4 frames as well.  The reason demo compat relies on it is because the position of the weapon when you want to switch determines how fast you can put away and take out a new weapon.

 

However, there are ways that ports can fix this without screwing up demo compatibility.

 

1. You could run an emulation of the original sway logic in the background for demo compatibility while visually swaying the weapon however you want it.  This has the upside of being able to do other things, like lessening or turning off visible sway.
2. If you have spare frames, you can do a slightly less invasive thing by walking weapons frames of animation and inserting "dummy" frames that do nothing but allow the sway logic to be run.

Edited April 11, 2021 by AlexMax

[OpenRift]

Just to drive the point home for anyone else reading. The PrBoom+ animation is correct because it emulates vanilla behavior.

[Scuba Steve]

It might, code wise, be correct vanilla behavior, but I don't recall vanilla animating this way. I think it's pretty obvious that many advanced ports corrected this behavior quirk (caused by some other change like resolution, fps...) by altering the code to correctly animate the chainsaw's idle frames. The Doom Unity port can probably be considered canon vanilla at this point and it doesn't behave this way.

Edited April 11, 2021 by Scuba Steve

[DemonicSavage]

4 hours ago, Scuba Steve said:

It might, code wise, be correct vanilla behavior, but I don't recall vanilla animating this way. I think it's pretty obvious that many advanced ports corrected this behavior quirk (caused by some other change like resolution, fps...) by altering the code to correctly animate the chainsaw's idle frames. The Doom Unity port can probably be considered canon vanilla at this point and it doesn't behave this way.

 

I did some testing on DOSBOX and the original DOOM2.EXE, it's also choppy there.

[Trar]

On 4/11/2021 at 4:04 PM, AlexMax said:

The problem comes from the fact that the chainsaw animation contains frames of animation that are greater than 1 frame.  For some reason, the sway update is not independent of the animation update, so if the weapon animation takes 4 frames, the sway animation takes 4 frames as well.  The reason demo compat relies on it is because the position of the weapon when you want to switch determines how fast you can put away and take out a new weapon.

 

However, there are ways that ports can fix this without screwing up demo compatibility.

 

1. You could run an emulation of the original sway logic in the background for demo compatibility while visually swaying the weapon however you want it.  This has the upside of being able to do other things, like lessening or turning off visible sway.
2. If you have spare frames, you can do a slightly less invasive thing by walking weapons frames of animation and inserting "dummy" frames that do nothing but allow the sway logic to be run.

How would one actually do this, though? It's minor, but it's the only thing that irritates me about Prboom. Otherwise it's an excellent sourceport.

Edited April 5, 2022 by Trar

[Shepardus]

Recent versions of dsda-doom have made the weapon and view bobbing a purely visual effect, so they can be turned on/off without affecting demo compatibility (the game logic behaves as if it's turned on, like what #1 in AlexMax's post says). It stands to reason that smoothing the chainsaw bobbing could be done similarly.

[Trar]

Okay, we just have to hope the PrBoom+ developers agree to add it in. I may make a post in its thread about it.

Edited April 18, 2022 by Trar

[Graf Zahl]

On 4/11/2021 at 10:37 PM, OpenRift said:

Just to drive the point home for anyone else reading. The PrBoom+ animation is correct because it emulates vanilla behavior.

 

PrBoom does not 'emulate' anything here - it just preserves the original code.

ZDoom long ago decoupled the animation from the frequency of A_WeaponReady calls because this was causing problems with custom weapons where their makers did not know these intricacies. The chainsaw just profited from this as well.

 

[Gregor]

On 4/18/2022 at 7:49 AM, Trar said:

Okay, we just have to hope the PrBoom+ developers agree to add it in. I may make a post in its thread about it.

PrBoom+um isn't actively developed any longer.; just maintained. They most likely won't add any more major new features. Better just switch to DSDA. It's just as much PrBoom+. Just the more modern version. What you're calling PrBoom+ is most likely really PrBoom+um, which is a fork of the old "real" PrBoom+, while DSDA is in turn a fork of PrBoom+um. The only reason people don't switch to DSDA like they switched from PrBoom+ to Prboom+um is because of the unfortunate decision by the DSDA devs to drop the "prboom" moniker from its name. That makes everybody think these two ports should be seen as separate rather than as one superseding the other. In reality though the family tree goes like this: Boom--Prboom--Prboom+--Prboom+um--DSDA. So i would recommend just updating to the newest version of Prboom+ aka DSDA.

Edited April 21, 2022 by Gregor

[xX_Lol6_Xx]

5 hours ago, Gregor said:

PrBoom+um isn't actively developed any longer.; just maintained. They most likely won't add any more major new features. Better just switch to DSDA. It's just as much PrBoom+. Just the more modern version. What you're calling PrBoom+ is most likely really PrBoom+um, which is a fork of the old "real" PrBoom+, while DSDA is in turn a fork of PrBoom+um. The only reason people don't switch to DSDA like they switched from PrBoom+ to Prboom+um is because of the unfortunate decision by the DSDA devs to drop the "prboom" moniker from its name. That makes everybody think these two ports should be seen as separate rather than as one superseding the other. In reality though the family tree goes like this: Boom--Prboom--Prboom+--Prboom+um--DSDA. So i would recommend just updating to the newest version of Prboom+ aka DSDA.

Apparently, it's not a fork anymore

[ReaperAA]

On 4/18/2022 at 10:49 AM, Trar said:

Okay, we just have to hope the PrBoom+ developers agree to add it in. I may make a post in its thread about it.

 

Like Gregor mentioned, you are better of switching to DSDA-Doom. It has pretty much all the features that PrBoom+ has and a lot more that PrBoom+ doesn't (features such as rewind, MBF21 modding features, Heretic/Hexen support, improved software renderer performance and mouse handling etc.)

[Graf Zahl]

Maybe it's time to move the DSDA-Doom port thread out of the speed-demos forum?

 

That gives a very false impression what it's really about and may steer users toward other ports because they think it's for demo recording/playback only.

 

 

[HavoX]

That's not a bad idea, but I think we should let the staff decide. What say you, @Doomkid/any other staff member?

Edited April 22, 2022 by HavoX

[i_like_cheeese]

what the choppy animations these guys are seeing is the original animations for the chainsaw. dos doom had a frame rate limit that wouldn't allow smooth animations for weapons and id software didn't put that many animation frames for most of the weapons to save space

[Graf Zahl]

That's not the cause here - all other weapons have the same limitation. But the chainsaw had a setup that would only let it alter its position every fourth frame.

The reason for this is that it is the only weapon with an animated ready state and the bobbing setup never accounted for this.

[Doomkid]

I’m used to the choppy animation, and that is exactly how it animates in Doom.exe / Doom2.exe. If someone asks how the chainsaw looks in vanilla Doom, this is the correct answer. Not really commenting on demo compat or whatever else, just stating the indisputable fact that the choppy animation is the “true”/“regular”/(whatever word we want to use) way that the chainsaw appears in-game.

 

As for moving the DSDA-Doom thread, I will leave that entirely up to the devs. If they want me to move it, I’ll do so happily. I also hope to get the Doom Speed Demos section moved out from under the “special interest” category entirely soon, since it absolutely doesn’t belong there for any reason. Regardless of where the thread ends up, that should hopefully help to reduce confusion.

[HavoX]

6 hours ago, Doomkid said:

As for moving the DSDA-Doom thread, I will leave that entirely up to the devs. If they want me to move it, I’ll do so happily. I also hope to get the Doom Speed Demos section moved out from under the “special interest” category entirely soon, since it absolutely doesn’t belong there for any reason. Regardless of where the thread ends up, that should hopefully help to reduce confusion.

Well, that seems reasonable enough.

[Trar]

So the solution here is "switch to DSDA-Doom" then. Since it's effectively the latest version of PrBoom I guess I don't have much problem with this. I just wish the legendary PrBoom+ itself had the option to smooth the chainsaw animation since it's literally my only problem with it.

Edited April 29, 2022 by Trar

[liPillON]

dsda still has the vanilla chainsaw idle animation, though.. (at least in the official 0.24.3 windows build)

 

it has been suggested to you because, being a port in active development, it's more likely to get new features than prboom+ (which is in maintenance mode)

 

 

have you considered woof?

 

 

[Trar]

No, I don't think I have considered Woof. Maybe I'll give it a shot.

[Trar]

On 4/21/2022 at 7:27 PM, Gregor said:

PrBoom+um isn't actively developed any longer.; just maintained. They most likely won't add any more major new features. Better just switch to DSDA. It's just as much PrBoom+. Just the more modern version. What you're calling PrBoom+ is most likely really PrBoom+um, which is a fork of the old "real" PrBoom+, while DSDA is in turn a fork of PrBoom+um. The only reason people don't switch to DSDA like they switched from PrBoom+ to Prboom+um is because of the unfortunate decision by the DSDA devs to drop the "prboom" moniker from its name. That makes everybody think these two ports should be seen as separate rather than as one superseding the other. In reality though the family tree goes like this: Boom--Prboom--Prboom+--Prboom+um--DSDA. So i would recommend just updating to the newest version of Prboom+ aka DSDA.

 

Thank you for clarifying this by the way, I had no idea. I'm a bit rusty when it comes to the latest sourceports.