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. 

I've been doing some more investigation of this one and have traced the cause - it's hinted at by the header comment of SV_Physics_Step:

"Monsters freefall when they don't have a ground entity, otherwise all movement is done with discrete steps."

Some tests confirm it (basically just not sending an entity that meets the freefall conditions in SV_Physics_Step) - a monster on a lift isn't MOVETYPE_STEPping, it's in freefall. 

sorry to interrupt but: groundentity is exposed in qc, does it do anything there? ie: will it report a lift that the player/monster is standing on? 

Whatever you do, just don't break the suspended monsters trick like DP does. 

don't worry, this would be a cosmetic change only (purely client-side.)

BTW, darkplaces has a lot of cvars that control features that break compatibility, you might be able to un-break that trick too if you know the right cvar (i think they are all named sv_gameplay_fix_*) 

why does fitzquake (and quakespasm) put the qconsole.log file in /quake/qconsole.log instead of /quake/mod/qconsole.log?

is this the original functionality? just seems a little odd (and had me searching around for it!) 

Is there anyway to force fitz to start in a windows mode via the command line? I tried with config files and it just keeps going full screen and then back to windowed mode.