Software Quake MDL Frame Interpolation

[mh]

In case anyone missed it.



This is a code-dump of an r_alias.c that does frame interpolation, together with a few implementation notes on changes required elsewhere to support it. I was going to do a tutorial, but the changes throughout the code are quite extensive, and most of them are just one or two lines, so it's easier for all of us to just give the full code and let you attack it with your favourite diff tool.

You should be pretty much able to just "drop-n-go" this into a standard ID software Quake codebase.

It doesn't do anything fancy like attempting to fix up muzzleflashes, and doesn't cover movement/orientation interpolation; the old interpolation tutorial can be used for that quite effectively (just move the changes from R_RotateForEntity to CL_RelinkEntities).

[Baker]

[mh]

Oh, I've had lightstyle interpolation for years!

It's really easy, just a small change in R_AnimateLight.

The old QER interpolation tutorial was saved here: http://www.quakewiki.net/archives/qer/tutorial4.html

[Baker]

Works like a charm!

Your documentation in the .zip is perfect, no good reason to do a tutorial of it or anything ... although I'm going to attempt to use this with a cvar.

[mh]

Good to hear!

I should mention that I changed the names of some entity_t members; from pose1 and pose2 to lastpose and currpose. I never was happy with the names that the QER tutorial used; not descriptive enough!

It shouldn't be that big a deal as I wouldn't imagine that too many people have done interpolation in software Quake, but you'll need to know it if you're ever planning on integrating the two.

[Spike]

[offtopic]tbh, I'm not that keen on lightstyle interpolation. makes flickering lights look ugly, and the lightmap uploads/regeneration every single frame gives a biiig slowdown.[/offtopic]

I thought NQ had fully functional movement/angles interpolation already...
All but for stepping monsters, which have an explicit flag set that stops them from being interpolated so they don't slide and judder, but merely judder. Just ignore that flag if frame interpolation is active.

[Baker]

[mh]

The movement/angles interpolation in NQ just determines the time between two intervals that messages arrive at, and isn't active when connected to a local server, so it's quite limited really.

I reckon the thing with interpolation is that it's all a matter of personal taste. Me, I hate the absence of frame interpolation, but could live without movement/angles easily enough (not saying that I prefer to switch it off - I don't, but it doesn't bother me so much if it's not available). Doesn't mean that I'm right and you're wrong, or vice-versa; just personal taste.

[Baker]

[Spike]

Yup, that's the flag that I was thinking of, anyway.
mh has a point though - it depends upon your packet rate.

[offtopic]And you might as well implement lightstyle smoothing, if disabled, its only one cvar check per frame, just maybe not default it to enabled. Some people prefer it, but yeah, flickering torches. Or if you like hacks, you could interpolate based on difference between the styles, if its too different, no interpolation. The expense is in the lightmaps, not the actual lightstyle values themselves.[/offtopic]

[mh]

[Baker]

http://www.quake-1.com/docs/rendering/r_alias.c

Managed to turn it into a cvar. My software renderer code is about 98% the same as stock WinQuake and while this file alone isn't the complete implementation (a couple of small adjustments to 3 or 4 other files, 1 or 2 liners).

It gives a good illustration for a third party (i.e., not either of you two obviously, hahaha) of how I turned it into a cvar and how I can optionally simply not even compile it into the engine.

I added cl_gameplayhack_monster_lerp 1 (as default value) and sv_gameplayfix_monster_lerp 1 (as default value) into my engine [GL builds too, of course].

Combined with MH interpolation, those deliver a much better single player experience in software and at any of the 3 or 4 NQ online coop servers (killing U_NOLERP ... sigh, what a difference).

That is really some wonderful code, MH.

[leileilol]

[Baker]

It sounds light it would screw up the intended look and feel anyway.

MH Interpolation Performance Results

timedemo demo1

No animation interpolation @ 320x200 fullscreen my machine: 285 FPS
With animation interpolation @ 320x200 fullscreen my machine: 281 FPS

So despite the lack of assembly and the pure C nature of the interpolation code, scarcely makes an FPS dent.

And even though the changes in r_alias.c are a bit moderate, it is still a rather light modification and --- well --- it isn't scary from a point of view of stability or compatibility.

[mh]