how doom handles animations

I was wondering, what with the advent of projects like smooth doom and older projects like brutal doom and perkristians smooth weapons, and most importantly, the recent explanation for doom64s lack of shotgun animations.

Why didn't doom implement a special code pointer that inherits the properties used for weapon bobbing, and weapon up, weapon down, and weapon ready motions for use with "high animation" things? particularly for things directly on screen like weapons that animate smoothly without requiring the sprite graphics to be cropped or offset by the wad file.

I mean, why not a special system or interface where values could be punched in for certain fields, such as two sets of x and y coordinates, or maybe even an algebraic expression instead of two coordinates, so you could get an optional curvature (i forget what the term is, I haven't done any graphing in a long time) and a duration, (where the smallest value is instant and the largest is slowest) and when the code pointer is called, the graphic glides across the line "on rails," as in offset by the game, in real time, instead of the jerky frames of animation that doom currently uses.

This could highly improve many of dooms things in an efficient and more visually stimulating way, like make shotguns animate smoother, the plasma gun recoil animation wouldn't look even a third as jarring, strong weapons like rocket launchers and bfgs could get a cool kickback motion, faster flying fists could get reduced to probably 2 frames of animation, a punching state and ready state, berserk punches could have gotten added values for a faster stronger punch with no added art assets, and many more.

Even many of dooms original ideas could have been implemented, like bullet case ejections (I'm imagining layered animating images, like the muzzle flashes) reloading weapons, or even stuff like flying gibs, fireball shrapnel, or metal parts from barrel explosions without the need of having to generate additional actors. And Doom64s weapon animations could have been rescued.

A lot of this seems to make perfect sense to me and it seems silly that even modern source ports haven't adopted a similar system, as I've seen many weapons mods will duplicate a sprite graphic many times in the wad file, with slightly adjusted offsets to simulate a smooth animation without including new art assets, which is a criminal misuse of space in my opinion. On par with using MP3 music instead of midis, or importing an entire texture resource wad into your map instead of just the textures you use (imo -- I know theyre not perfectly analagous)

So why wouldn't Doom use a similar system? Does dooms source code not formatted in a way that it could easily be implemented? Was there not enough time to program something like that? Did they simply not think of it??

Probably because it was running on a 386. Managing texture rotation and composition in realtime during gameplay would have been quite a feat, and would've probably required performance compromises to be made elsewhere in the engine.

40oz said:

the plasma gun recoil animation wouldn't look even a third as jarring

I don't think it's jarring.

If anything, I think that the commonly used smooth weapons pack looks jarring, because the movements that are supposed to be sharp now resemble some sort of dance*. Also, when people produce smooth animations by cloning the same graphics with different offsets, it looks like Flash. And everything else (you can't smooth everything with this method) looks even more jerky in comparison**.

* Which looks more like an implementation problem, admittedly.

** Probably answers your question at least partially.

By the way, I'm not sure I understand how Doom 64 would benefit from such a feature.

Da Werecat said:

it looks like Flash.

This. The movement and transformations in 2D would look really smooth (unnaturally smooth, even) and anything that would require animating the depth dimension would look awful and jarring.

esselfortium said:

Probably because it was running on a 386. Managing texture rotation and composition in realtime during gameplay would have been quite a feat, and would've probably required performance compromises to be made elsewhere in the engine.

They could've messed about with sprite alignment in real-time without much of a performance hitch. The Marathon series does this, and it was designed to run on 68k derived CPUs.

I think they just rushed through making the game. Once they got bobbing working a bit, they just moved on to the next task. And, once the game started taking shape, Romero was too busy deathmatching to do any more work :) It's actually pretty amazing how fast they made Doom. Hindsight is one thing, but they blazed through the development of a game that had multiple innovations, new to id, and the general public, at least.

Sodaholic said:

They could've messed about with sprite alignment in real-time without much of a performance hitch. The Marathon series does this, and it was designed to run on 68k derived CPUs.

sorry if I wasn't making myself clear, I believe what is described here best matches what I'm suggesting. I didn't mean to imply that the sprite images would be rotated, distorted or warped in anyway to match perspective, just panned around the screen to accent the frames of animation with a more fluid motion.

now that I think of it, unless corrected it would look like the buggy chainsaw bobbing.

The chainsaw's problem is that its screen position is updated every 4 tics instead of every tic, because its A_WeaponReady states are 4 tics long. It's not a bug, just the way bobbing works.

Such problems could be worked around if it was really necessary.

40oz said:

it seems silly that even modern source ports haven't adopted a similar system

While it doesn't accept a mathematical formula. Raven software added offsets to Hexen and any source port that supports Hexen has it.

Oddly enough, the misc1 and misc2 values for states were meant to be used for offsetting, and weren't used. MBF used them to make some parameterized codepointers for Dehacked.

Da Werecat said:

The chainsaw's problem is that its screen position is updated every 4 tics instead of every tic, because its A_WeaponReady states are 4 tics long.

likewise, so does the chain gun, rocket launcher, punches, and shotguns attack sequences. If it were corrected, then nevermind, but if the solution wasn't very simple and required time to repair, it could explain why they chose to freeze the weapons while firing and offset the images in the wad file instead of giving them real time offsets

I don't see a problem with updating bobbing outside of action functions. They probably shoved the relevant code in WeaponReady simply because it seemed like the safest solution.

Animations, on the other hand, should be handled in the state table. I don't see any other elegant way. So you just need a bigger state table for smoother animations (with real-time offsets or not).

40oz said:

and offset the images in the wad file instead of giving them real time offsets

Actually, I don't remember any sprites in the Doom IWADs that are completely identical save for their offsets. Maybe aside from a few lazy SSG sprites.

I added some movement to the guns with deh and the misc parameters. Without any new gfx, the animations looked much better, though needed a few more frames. And I also had them getting centered when firing.

And the source port is?..

40oz said:

likewise, so does the chain gun, rocket launcher, punches, and shotguns attack sequences. If it were corrected, then nevermind, but if the solution wasn't very simple and required time to repair, it could explain why they chose to freeze the weapons while firing and offset the images in the wad file instead of giving them real time offsets

No, that's just because A_WeaponReady (the codepointer that does the bobbing) jumps directly to the attack frame if the fire button is held down, without actually displaying the ready frame and hence without updating the offsets. (Not that it ever gets a chance to, since as I recall no firing sequence actually calls A_WeaponReady anyway, instead going through A_ReFire first.)

You'd have to call WeaponReady every tic anyway mo make bobbing look good.

I debate that it would look odd if half the firing animation was 'smooth' (I.e the pull back to fire the shotgun) and half wasn't (i.e the reloading animation of the shotgun).