http://celephais.net/board/view_thread.php?id=60277&start=93&end=97 

Ok its a known issue, I missed that! 

Fixed in quakespasm since version 0.85.4. See here for the fix, which is actually from quakeforge:
http://quakespasm.svn.sourceforge.net/viewvc/quakespasm?view=revision&revision=359 

FitzQuake 0.85 on Windows: Shambler's lightning attack animation not smoothed, even with r_lerpmodels and r_lerpmove enabled and r_nolerp_list cleared. Not a big deal, but still. 

That's intentional; Fitz doesn't interpolate when an entity goes into a muzzleflash frame. 

i think it might be something else (or the muzzle flash no lerping is linked to .owner in some way?) because checking the 106 progs, the muzzleflash is played on the shambler, not the lightning entity. 

Just a quick brainfart, thought I would post it to see if anyone else found it interesting. No idea if its even possible or easy to implement! :)

A worldspawn key for map specific colour grading / tinting.

Something like _colourmod R G B that will tint the screen image to the mappers preference. So if you have a slime/green themed map you could accentuate the greens/yellows slightly to give a customized final look. Together with fog some interesting visuals could be achieved.

/2 pence 

uhhhh what? you mean tinting the screen like a v_cshift command but automatically? 

I've never heard of this command :) I just tried it but im unsure what values it wants to do anything ;)

A suppose a simple explanation of what im on about would be that you could enter a theoretical "_colourmod" with values of .5 .5 .5 which would desaturate the entire image by removing half of every colour. 

mh is correct: the shambler attack has 7 frames in a row with EF_MUZZLEFLASH enabled. Fitzquake is set up to not lerp frames that have that effect, because usually it's accompanied by muzzle flare geo poking out of the front of a gun, which looks bad when lerped (i.e. on grunt, enforcer, and all player weapons.) Unfortunately it is an unnecessary feature for the shambler lighting attack.

If you don't like that feature, you can set r_lerpmodels to 2 instead of 1 and it should ignore those special exceptions. But, this will also disable the r_nolerp_list feature...

Ideally (note to RMQ team), there would be a way for quakec to tell the engine when lerping is acceptable (EF_NOLERP?), and even which frame to lerp to, and how long to spend lerping. This would only work with progs.dat written to provide that extra information, which is why all quake engines have to make various assumptions to try and make lerping look good. For example, Fitzquake uses .nextthink to guess how long to spend lerping, and EF_MUZZLEFLASH and r_nolerp_list to decide when it's a good idea to lerp. 

With DirectQ I decided that if a vertex moves 10 or more units from back to front between frames 0 and 1 then it's not interpolated. It works well with all current content, but of course something is going to break it at some point in time. That's something I accept for now. I didn't bother with enemy muzzleflashes.

For RMQ we're building new content and it can be made interpoaltion-friendly from the get-go. 

this is done per vertex?
like, if a zombie swings it's arm, the shoulder and upper arm are lerped, but the lower arm and hand (since they are moving fast) are not? 

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.