Some More FQ Mk V Features Maybe?
#685 posted by NightFright on 2014/02/05 23:19:51
Comparing Quakespasm to latest Fitzquake Mk V, here's what I am still missing:
- Sndspeed saved permanently in config.cfg
- .VIS support (saves a lot of disk space)
- HUD weapon rendering like in FQ Mk V
- Non-transparent teleporters on VISed maps
Another idea might be to be able to switch between "gl_nearest_mipmap_linear" and "gl_linear_mipmap_linear" filtering modes on-the-fly via a menu option for convenient on-demand switching.
Other than that, looking forward to the next release! :)
Two Mission Pack Related Problems
#686 posted by ToMaHaKeR on 2014/03/08 16:43:25
1. Statusbar shows wrong icons/values for the new Hipnotic/Rogue weapons
2. Buzzsaw traps in one of the mission packs are not interpolated
I use the the latest x64 QuakeSpasm (version 0.85.9)
#687 posted by Spirit on 2014/03/08 19:54:12
1. Did you use the -hipnotic / -rogue switch?
#688 posted by ToMaHaKeR on 2014/03/08 20:31:56
I settled it, only the problem #2 remains.
Which mission pack / episode is this in ?
#690 posted by ToMaHaKeR on 2014/03/08 22:56:46
DoE (Rogue) mission pack. Map name is "Blood Sacrifice". There are three buzzsaws in a corridor, which go back and forth. They are the only thing that's not interpolated.
I Havent Played That In Ages.
R2M6
#692 posted by ToMaHaKeR on 2014/03/09 12:32:45
Yes, and any other map where such buzzsaws are present. If they managed to lerp weapons and all the models in general, I believe they can do the same for the buzzsaws.
#693 posted by dwere on 2014/03/09 13:43:06
The animation is probably interopolated. It's hard to tell with all the twitchings. Not that it would be of much use - said animation is not very lerp-friendly.
The movement _should_ be interpolated too, but it isn't. My guess is that the problem lies in the implementation of the buzzsaws, the way they function, but I could be wrong.
Bad Guess
But try r_lerpmodels 2 in case the buzzsaws are on the nolerp list?
#695 posted by ToMaHaKeR on 2014/03/09 14:14:12
Correct, the buzzsaws themselves are interpolated - their movement isn't. When I said "buzzsaws are not interpolated" I actually referred to their movement.
Buzzsaws move on their exact designated routes (lines), they are not like enemies who can roam wherever they want. This is just my guess, as I don't know much about engines and editing.
#696 posted by ToMaHaKeR on 2014/03/09 14:15:11
@onetruepurple
r_lerpmodels is already on 2, and the nolerp list is already empty.
#697 posted by necros on 2014/03/09 15:04:08
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.
That Would Make Sense
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.
#699 posted by ToMaHaKeR on 2014/03/09 15:48:43
So, no way of making it smooth?
#700 posted by necros on 2014/03/09 17:47:47
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)
#701 posted by ToMaHaKeR on 2014/03/09 18:26:30
Works like a charm, thanks!
Hmm...
#702 posted by metlslime on 2014/03/09 22:14:55
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.
There's Also A Bug In Fitzquake
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.
Interp Question
#705 posted by Preach on 2014/03/09 23:36:48
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?
#706 posted by necros on 2014/03/10 00:00:32
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.
FYI
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.
Texture Scaling
#708 posted by Preach on 2014/03/10 00:45:13
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?
Confirmed Re: Texture
#709 posted by necros on 2014/03/10 01:04:40
it does look effed up, in both FQ085 and QS 0.85.9
|