I also changed the lighting depth check (because MH did) from 8192(Fitz 0.85) to 2048 (original Quake) because MH had a comment about performance (8192 is a long, long distance).

Note: the reason i extended this distance is because CZG had a really deep pit in one of his maps, and the scrags floating over that pit were black instead of taking the lighting from the floor. 

the light depth check could be tweaked via a command line parameter? Something to set before the engine fully loads? 

How much the increased depth check costs to make. Is it really worth reducing back to stock quake for a little extra performance? 

The lighting depth check should be cvar-ized. Having to restart the engine to change something like this is stupid.

2048 is probably a little too low, especially with the "run the test for static entities once only at startup" trick (which was where the main performance impact came from in tests - and mind you this was quite an extreme case too). It also fails to light models properly in Zerstorer when this low.

It's probably worth finding the max top-to-bottom extent of the world and using that value as well - that'll be guaranteed to catch anything. 

end[2] = start[2] - (cl.worldmodel->maxs[2] - cl.worldmodel->mins[2]);

Why make the player do it when you can do you yourself? 

@Necros: The lighting check is one of those super slow recursive world checks. I'll do as MH suggests and default it to the Fitz 0.85 --- I wasn't looking to make an changes in how Fitz 0.85 operates (I lacked the imagination of a situation where 8192 could actually be needed, like the CZG map metslime said that induced him to raise the distance check).

[I'll add in MH's idea of a world bounding box check .. and if set to 0 will check lighting from unlimited depth. These things are going to push the update version to tomorrow it seems. But getting things absolutely right is something worth taking the time to do.]

@Sock: Any chance you could zip your map plus save the game exactly at the point the view model (weapon) lighting is wrong? It would help me avoid investigating things that aren't actually the source of the problem. 

if you use the max level extents of the world, does that still save any performance? I assumed the cost of a traceline is related to the number of nodes it has to cross, and once the line is >= level extents, it's already the worst case, right? 

Or just end[2] = cl.worldmodel->mins[2] - better yet. 

Another bug: When I start the engine (windowed mode) the +mlook does not work (even if I have the window selected)

I didn't change any mouse operation, but I'll investigate and see that this gets resolved. 

The big advantage of basing it on the world extents is not so much in terms of performance but in terms of correctness. Using cl.worldmodel->mins[2] (I'd actually subtract another 10 or so just so that the end point is ouside the map, then check that start[2] actually is bigger than end[2] to cover for noclipping) means that you're always going to hit something during the downtrace - it's guaranteed because nothing in the world can be outside of that point.

The other method - pick a number and hope it's big enough - fails because eventually a map is going to appear for which it isn't big enough. True, 8192 matches protocol 15's default +/- 4096, bounds but it breaks on extended protocols that may increase those bounds.

Ultimately it comes down to a choice between a simple method that is guaranteed to always work versus just picking a number. 

Any chance you could zip your map

You certainly make it hard to be contacted, I tried the MarkV readme file, your account here and got no joy. Any chance you can drop me an email address? (my account here has my details) 

check your mail ;). 

Download: http://quake-1.com/docs/utils/fitzquake_mark_v.zip

Readme: http://quake-1.com/docs/utils/fitzquake_mark_v.txt

Some features:

Game command supports -hipnotic, etc. Like type: game warpspasm -quoth

ALT-ENTER switches between fullscreen and windowed mode, "folder" command now opens the folder and highlights most recent file made (like a screenshot or demo).

Many bug-fixes, speed increases and Sock's lighting bug should be gone.

[Issue wasn't related to shadow downtrace for lighting, but I made that "infinite" now. r_lightpoint_depth 0 = infinite. You could set to 8192 or 2048 ... but I think I'll remove the cvar eventually. "infinite" is a Z endpoint of cl.worldmodel->mins[2] ... few objects.]

There are also major capture demo improvements to make things easy. See readme. If interested in demo capture, I recommend trying Google WebM (known as vp80) available at http://www.optimasc.com/products/vp8vfw/index.html

WebM is the video codec Google wants to use as the HTML5 video standard, so it compresses video fast and the file size is small.

This engine revision will automatically detect that this codec is installed and use it.

[Video capture is simple in this engine.

Type capturedemo demo1 in console. Best to be in windowed mode so you can see demo progress. That's it.

You can also bind "capturevideo toggle" to a key] 

Another old Fitz bug, by the way:

Set host_maxfps to something stupidly high (10,000 or so) (I suggest adopting host_maxfps 0 = unbounded - Q3A did that and I had one player who was expecting the same behaviour from Quake).

Set scr_showfps to 1.

Look at the fps counter. Funny, isn't it? The tileclear isn't being refreshed every frame (which is a bad enough idea to begin with...) so the area where the counter lives just gets new figures drawn over it each time. 

I'll need to absorb your timing fixes first (plus add the server-side lerp movement for "monsters") and afterwards I'll make host_maxfps 0 function like as above. 

Please do not release updates using the same filename. Use the date as suffix or a version number. 

First release (R0): http://quake-1.com/docs/utils/fitzquake_mark_v_r0.zip
Revision 1 (R1): http://quake-1.com/docs/utils/fitzquake_mark_v_r1.zip
Revision 2 (R2): http://quake-1.com/docs/utils/fitzquake_mark_v_r2.zip
Revision 5 (R5): http://quake-1.com/docs/utils/fitzquake_mark_v_r5.zip

This meets my need of making someone doesn't download an old one for no reason, and should satisfy your desire to make sure no source codes/binaries get lost. 

 

I forgot to mention the latest version has support for "title demos".

A "Title Demo" is a demo that plays with no HUD, no crosshair, fov 90, viewsize 120 (No status bar).

Usage: cl_titledemos_list "demo1.dem,demo2.dem,demo3.dem"

This allows usage of "startdemos demo1 demo2 demo3" to essentially play as a movie or an intro. This could be gameplay action or you could record of demo of you touring the map with no clip and no target (hopefully with a QuakeC progs that uses a null view model).

I more or less got this idea from how Warsow starts up showing game play action or how the original Unreal did a cool moving view of the castle. 

Kurok used a "title demo" as the start screen. It was a demo of a small map that was 70-90 seconds long (repeating) that showed a mountain and a block labelled "Kurok". For the longest time, I didn't realize the intro screen was a demo.

Demos, of course, are recordings of a map so they can have a soundtrack just like how a map can have a soundtrack key. 

Any chance to add widescreen Fov? Currently I have to put FOV 106 in the command line. 

That is a "no win" situation. Here is why ...

The field of view is the degrees of view showing. If I set to that to 90 degrees, I would hope that would be 90 degrees.

If I correct the FOV for widescreen to adjust to, say, a 4:3 aspect ratio (wide-screen correction) then it isn't really 90 degrees but some other number.

If I make it auto-correct, many people will not like it because it looks wrong because they are used to it looking a certain way in FitzQuake. So I would have to add a cvar to control it.

Which is one more setting for someone to mess with.

With how things are now, there is a setting to mess with (FOV) and everyone knows what it does. Versus add a new setting, which people would have to learn about. And other engines wouldn't save this new setting so it would get erased periodically. Not that FOV saves to config anyway.

Then there is the argument that 4:3 isn't the Quake aspect ratio to use for widescreen. That 8:5 is because original Quake loaded up to 320x200, not 640x480.

So ... I would add widescreen correction if a magic bullet answer exists. But I can't think of one.

The nicest thing about FitzQuake is that unlike some other engines that you can rely on it to be familiar versus some engines that do things that confuse you and you don't know how to change it or maybe it can't be changed. 

Agree with baker re:fov, but I would add that even in 320x200 mode, quake is intended to fill a 4:3 display, which means non-square pixels, but that is how monitors displayed that mode AFAIK.

(I sometimes look at the menu art and wonder if the letters are intentionally stretched to look correct in this mode.) 

Hey, when do you plan to release the version with mlook + windowed fixes? 

Boring engine technicality: MH explained a superior way of handling mouse input in the last day or two that is streamlined and efficient and very reliable and easy to manage.

So at the moment, I'm on a side quest since I don't want to put out two separate revisions that change the input code heavily back to back. Giving me something extra to do before I get this newest revision out and slowing me down a bit at the moment.