And in some cases it works great.

It some cases, if you rapidly press pause and then unpause ... you see the most foobared looking thing imaginable.

I'm talking view weapons here. 

It's a little more complex than that.

First of all it's only done with the view model. The check is actually run inside of R_DrawViewModel so that's absolutely guaranteed: "if (!mod->delerped) {Mod_DelerpVertexes (mod); mod->delerped = true;}" or something like that. The viewmodel also runs a slightly different code-path, so even if somebody did decide to use zombie.mdl as a viewmodel (those wacky modders!) it's also guaranteed to not happen with regular zombies too.

Secondly, it only checks vertexes that move between frames 0 and 1 of the model (if the model has only 1 frame - and there are some - it doesn't bother). So no matter how much a vertex may move in any other frame doesn't matter and doesn't affect the result; it's only "if it was in this position in frame 0 and in that postion in frame 1" that counts.

Thirdly, it's only movement in the back-to-front direction that is measured. So apply aliashdr_t::scale and aliashdr_t::scale_origin to the positions in each trivertx_t, then check the difference between element[0] of each - over 10 indicates a positive result - this vertex was way at the back of the model in frame 0, in frame 1 it's way out at the front, so we don't want to interpolate it.

The result from this comparison carries through to other frames, and so far it's proven to be valid with all ID1, Rogue, Hipnotic, Zerstorer, Quoth, etc weapon models (it even worked perfectly with Hellsmash) - it successfully removes interpolation from the muzzleflash verts, and only from the muzzleflash verts.

I have an idea that a nicer implementation might be to weigh the blend factor depending on the distance between the current and previous verts for any pair of frames; that could be run on the GPU in a vertex shader, wouldn't need any special case handling, and it's something I may experiment with some day. 

oh ok, i didn't know if was only for view models.
sounds like you've got all the bases covered i guess; i've never looked at the engine code much, so i don't really get the specifics of it all. 

So that's why the lightning effect on the RMQ Cauteriser interpolates, even though that's not intended.

So with the proposed solution it'd just be a case of moving the lightning part of the mesh very far back in the 'miss' frames. 

Yup; just move it as far back as possible in frame 0.

I tried the vertex shader idea, and it works fairly well. Things are occasionally jerky during dying animations, but it's a reasonable enough general solution. I think I might save it up as a fallback if my current method ever breaks. 

Is it anyhow possible to smooth the movement of the lightning gun bolt (when you fire and sweep around with that weapon)? 

that is a different problem from the view model interpolation issue.

i got around this problem in ne_ruins by changing the lightning code to update the beam position every frame. this gives an extremely smooth smooth sweep. you also need some code to maintain the old 30 damage per 0.1 seconds as well as a way to keep track of missed damage (if the player gets less than 10 fps) but that's not a big deal. 

...is also framerate-dependent. If you're running at 20fps it looks different to if you're running at 1000fps, because the engine assigns each bolt segment a random angle each frame. 

yeah, that bugged me a lot. i've been building custom beams out of entities lately. more control that way too. 

Literally now. Ever since installing the latest Nvidia driver (I believe), FQ doesn't work in fullscreen anymore. The screen is just black and there are no sounds. I can't alt-tab or reach the task manager to close it. Apparently Windows is still active in the background, at least ctrl+alt+del and random key mashing seems to do something - i often hear the Windows logout sound - but it's impossible to bring it back, so only a reset helps. No problem in -window mode, and QS can be run in fullscreen fine.

I had somewhat similar problems with DirectQ every now and then. However, there the monitor would at least show an "out of range" message.

Any idea what I could do to fix it - or get more information on what's going on? 

have you tried forcing the screen res with -width and -height? 

Mind you, I find that unless I am setting it to the monitor's native resolution, changing the res via the command line will cause a black screen, but the app hasn't locked up - I can alt-tab back to it and it fixes itself. 

Also try changing the video settings stored in the config files to what you want if the command line force doesn't work. Might be worth a shot. 

I'd double-check what you're setting for refresh rate and bpp too, as it definitely seems like you're trying to select a mode that hardware acceleration isn't available in but that is nonetheless being reported by the engine (perhaps one of the low res modes?) 

is it possible to scan the 'wad' key in the worldspawn to get the texture wads used, and then, when loading external textures, also look in folders named the same as the wad files?

map is mymap.bsp
so my worldspawn has:
'wad' 'gfx/common.wad;gfx/quake.wad;gfx/hipnotic.wad'

so fitzquake would look in:
/textures
/textures/mymap
/textures/common
/textures/quake
/textures/hipnotic

this would make keeping external textures folders organized a simpler task, especially if you have a map pack with more than one map referencing the same texture without having to resort to mixing all the packs together into /textures. 

crap...
'wad' 'gfx/common.wad; gfx/quake.wad; gfx/hipnotic.wad'
but all together, without spaces (like normal). 

I personally think it's a more elegant approach than using the map name, but it has the disadvantage that when multiple wads are used it must attempt an extra file search for each extra wad. Depending on how many textures you have, how many of those are already cached, and how many image formats you support, it could measurably slow down map loading.

There's also the fact that using the mapname is standardized in so many texture packs.

I suppose you could do both and cache a qboolean for whether or not the search path exists after the first attempt. 

Depending on how many textures you have, how many of those are already cached, and how many image formats you support, it could measurably slow down map loading.

From, say, 0.5 seconds to a full 1.0? :) 

You always say that like optimization wouldn't matter and was pointless if it doesn't have an highly noticable effect. But look at DP, for example. It gradually went up from a couple of extra 0.5s to 'let's compute everything from scratch', and now loading even a simple map takes 30 seconds. 

Oh, I agree. and I'm really sort of half trolling here.

But if an engine takes 30 seconds to load a Quake level, there's something fundamentally wrong with that engine ... IMO. If I can get a Gears of War level into my editor faster than that, the Quake engine is doing something REALLY wrong. :) 

I mean, what you're describing is the sort of "death by a thousand cuts" syndrome that makes things very hard to optimize into a better state because there aren't any large wins. There are tons of wins in there but they're all small and taken on their own aren't significant ... so, yeah, maybe improving this one little thing would be useful. I dunno! 

All it takes is a handful of millisecond or sub-millisecond optimizations to get a Quake engine running (or loading) twice as fast (or skimp on them and you're running twice as slow).

That's not a big deal for id1 content - 600 vs 1200 fps? Getouttahere.

For non-id1 content it's critical. It means bigger maps, more enemies, more game logic, more visual effects (particles, lights) and still being able to maintain good performance.

In the specific case of texture loading, a useful cutoff point seems to be something like: "if it takes longer to establish that an external texture doesn't exist than it takes to just load the native texture, then it's worth doing". 

http://forums.inside3d.com/viewtopic.php?f=2&t=4716

This thread has 2 interesting thoughts and semi-obscure thoughts on weaknesses in movement interpolation in Fitz 666 protocol (which is far better than old QER tutorial).

One by MH on lerp movement (and I bet lerp anim!) should reset if entity is frustum culled, and one that I inadvertently came up with thinking about a chase camera improvement that ultimately coughed up an oversight or potential obvious movement interpolation improvement.

Storing this here with the rest of the FitzQuake buried future ideas/unearthings. 

If view weapon goes off screen ??? 

thanks for the tip, Baker. I did know about the enemies riding lifts problem, but hadn't noticed the frustum culling problem.

Btw, a clarification: fitzquake model interpolation is completely independent thing from the fitzquake protocol -- you can have either one without the other. The one small overlap is the protocol contains a timing hint for lerping, but that hint could be used by other interpolation systems, plus the fitzquake system still works if you set "sv_protocol" to 15.