@onetruepurple

r_lerpmodels is already on 2, and the nolerp list is already empty. 

The buzzsaw doesn't actually move in the normal way. What it looks like (only from looking at the QC) is you make a func_train or something that the player can't see. Then you target the train with the buzzsaw. Every 0.1 seconds, the QC sets the origin of the buzzsaw to the targetted train. This is why it doesn't interpolate, because it's not supposed to-- the QC call is setorigin. 

I think because if it was one big buzz-saw which moved as part of its animation then the bounding box would be this massive impassable thing. 

So, no way of making it smooth? 

The problem lies with QC. The engine is working as intended. Here is a patch:
http://mobile.sheridanc.on.ca/~jonescor/temp/RogueBuzzsawPatch.zip

Just unzip pak1.pak into your .../quake/rogue directory. (next to the pak0.pak file) 

Works like a charm, thanks! 

there is a bug in fitzquake where monsters riding lifts don't interpolate motion correctly. I wonder if this is related to that.

AFAIK, the client-side interpolation doesn't care what method is used to update the entity origin, and it should work correctly, but obviously there are some holes in this based on the buzzsaw problem and the enemies on lifts problem.

So i'm not ruling out that this is an engine bug. 

where certain textures look like absolute shit. Namely carch03, the red circle stain glass window seen in E1M5. Looks fine in DirectQ though. I have a feeling it's something to do with resolution of the texture. 

Fitz V

You're going to have to elaborate on that. 

AFAIK, the client-side interpolation doesn't care what method is used to update the entity origin, and it should work correctly, but obviously there are some holes in this based on the buzzsaw problem and the enemies on lifts problem.

There must be limits to this though, like when monsters/players teleport? It would look weird if that was interpolated. Is it based on a maximum distance/threshold? 

It may be due to the solid and movetype settings:
self.solid = SOLID_TRIGGER;
self.movetype = MOVETYPE_FLY;

I believe I've had problems with interpolation when using SOLID before.

The code uses the stock path_corner functionality that monsters use, but instead of using a movetogoal (that would not work for vertical differences) there's a single think function that does:

dir = self.goalentity.origin - self.origin;
dir = normalize (dir);
dir = dir * self.speed;
setorigin (self, self.origin + dir);
self.angles_x = self.angles_x - 60;
self.avelocity_x = 60;


Note also that the frames are not actually use and that the model is rotated via code so interpolation for rotation shouldn't be a problem. 

This is what I mean.

DirectQ -
https://www.dropbox.com/s/l03v8gop65zp17k/dq.png

Fitz V -
https://www.dropbox.com/s/jvpqijeux9wdeyh/fitzv.png

Fitz is garbled. I think it's trying to stretch the texture somehow so both sides are the same length/width. There are lots of examples of this, pretty much all the door textures, the slipgate textures, a lot textures I used in q-deck.

People tend to revere Fitz but, as good as it is, it's still far from perfect. It's a shame Baker no longer works on it really. 

That looks like the effect in stock glquake of resizing textures to be power-of-2 dimensions. Which is odd as fitzquake was one of the first engines I can remember addressing this problem, by padding the textures rather than scaling them. Unless I've misremembered and that was only performed on models and not on wall textures - or could it be that when you apply nearest neighbour render mode the fix gets reversed out somehow? 

it does look effed up, in both FQ085 and QS 0.85.9 

needs support for GL_ARB_texture_non_power_of_two.
basically find the rounding code and bypass it if that's supported. no more uglyness.
directq, dp, fte should all support this, no idea about rmqe.

@Preach, the fitzquake padding hack thing only works on non-tiling surfaces, which means 'not on world'. 

fitzquake is using bilinear interpolation to upscale the texture, i think directq uses hardware support for non-power-of-2 textures. That support would be a good thing to add to a fitzquake branch. (See Spike's comment) 

yes, there is a distance limit that disables interpolation for one frame to catch teleports. From the code, it looks like 100 unit delta on any one axis will be considered a teleport. 

There is also a transparency problem in the latest QuakeSpasm. The screenshots below are taken with r_wateralpha 0.5, the map is E1M1. As you can see, the water is transparent only when you get really close to the waterline:

http://postimg.org/gallery/4jagxy5q/ 

Wow. I didn't know Fitz can't handle NPOT wall textures. This is kinda disappointing.

I've also noticed that it has some minor problems with UV coordinates. This can screw up pixel-precise detailing on model skins a bit. 

This is not an engine issue, the original id maps do not have transparency visibility calculations, so the engine reads the map file and sees that there is nothing behind the water when you are on the other side of it. You will need to find the patch that either recompiles the maps with transparency, comes with maps already compiled or has .vis files (i think it's .vis?) that has new visibility calculations (fitzquake engines do not support that afaik, so this isn't an option if you want to use this engine, you will need replacement maps). 

What necros said, plus: if you want to fix this in a hacky way, set r_novis to 1. This will make your framerate worse on large maps, but will fix the visual issue. 

Are these UV problems different when compared to other engines? Does GLQuake do it wrong too? 

r_novis 1 works, but the moving brushes are not visible through the water. They show up only when you enter the water. Secret door in E1M2:

http://s29.postimg.org/agce9rf07/spasm0000.jpg 

Looks like GLQuake has the same problem. I made a few shots to illustrate.

WinQuake:
http://i.imgur.com/TqDpxj0.png

Quakespasm:
http://i.imgur.com/NRFNIGg.png

GLQuake (Bengt Jardrup's build, but it was the same in vanilla):
http://i.imgur.com/6A0d4bx.png

DirectQ:
http://i.imgur.com/fbLkr1O.png

Look at the weapon's clip. WinQuake and DirectQ shots represent the way it's supposed to look. 

Mark V supports .vis files