[Goober5000]

I just fixed a major bug in the animated texture code, which caused the animation speed to vary unpredictably and usually run way too fast.  Animations will now run at their proper speed, but the old, sped-up animations will need to be slowed down to match their original behavior.

The good news is that the bugfix means WYSIWYG, that is, the speed of the ani in ANIVIEW will be the speed of the ani in the game.  No more trial and error.

[Dark Hunter]

 

Clap clap clap for the Freespace god!

[Goober5000]

I'm always nervous when people say that, because I don't want this to happen to me.

[Zacam]

*chuckles* Yeah, that would kinda suck, wouldn't it?

Is it a major enough fix that we'll see it in RC5/3.6.9 Final, or cvs only for now?

And how many do you think are going to need fixing? I've been looking for something to do that fell within my already established skills (vs. stuff that I'm currently learning or re-learning)

[Flipside]

Poor Herod, survived an Angel attack, and a nasty fall, only to get mugged by passing worms....

Good stuff Goob

[Goober5000]

It'll be in 3.6.9.  And every animation that was fine-tuned using the game, as opposed to using ANIVIEW, will need to be redone.  Animated shockwaves, for example, now run too fast.

[taylor]

Animated shockwaves, for example, now run too fast.

That's only 3D shockwaves though, and those have to be given frame numbers to use from the shockwave code (since its play speed is based on the shockwave time).  I've got that fixed in my tree and will commit it with the rest of the stuff.

[Goober5000]

Wait, that's another code bug?  I thought it was a problem with the data included in the mediaVP?

[Col. Fishguts]

Is this including EFFs ? In other words, will the $FPS setting in the EFF file now work properly ?

[Colonol Dekker]

Animated shockwaves, for example, now run too fast.

That's only 3D shockwaves though, and those have to be given frame numbers to use from the shockwave code (since its play speed is based on the shockwave time).  I've got that fixed in my tree and will commit it with the rest of the stuff.

Surely the light would reach before the shockwave,, relativity and all that.. So in fact you just kept the effect true to RL physics 

[taylor]

Wait, that's another code bug?  I thought it was a problem with the data included in the mediaVP?

Only in your changes (that GLOWMAP_FRAME_OVERRIDE crap which you removed).  The problem is that the animation for a shockwave has to based on the speed and duration of the shockwave (ie, it will play faster or slower based on the shockwave itself).  So standard timing can't work for shockwaves since the animation either ends too soon, or gets cut-off before it's finished.  There was a big deal about this when the code was originally done and I had to add the shockwave_get_framenum() function to compensate for it.  2D shockwaves already account for this timing issue, the model code doesn't/can't though, at least not by itself.

I just cleaned it up and commented the special frame handling a bit better so that this is clearer.  I've got the commit ready with the fix, just haven't had the opportunity to actually get it in yet.

[Goober5000]

Ugh.  Okay, I thought it was a data bug.  Thread moved then.

Wouldn't it be easier/better/simpler to just change anim->total_time whenever a shockwave is created?

[taylor]

Wouldn't it be easier/better/simpler to just change anim->total_time whenever a shockwave is created?

It's already set/needed by the shockwave code though, and why bother computing current time twice for the same object?  Also, shockwave_get_framenum() will kill a shockwave once it's animation has played through, since shockwave animations shouldn't play more than once, so it needs to be excuted for every shockwave each frame regardless.  It's easier/better/simpler as it is (was).

[Goober5000]

Bah, okay.  I'm just not a fan of big stupid global override variables.

[taylor]

Bah, okay.  I'm just not a fan of big stupid global override variables.

I'm not actually using the global in the modified code.  All the global did was store the obj instance so that we know which shockwave to get the current frame for.  It's possible to figure that out with just the existing Interp_objnum global, which is what I'm using in the newer code instead of GLOWMAP_FRAME_OVERRIDE.  Didn't think it was worth yet another global just for something so simple.