I have been testing my map with the mark V engine and for some reason all my models (map objects, items, weapons and monsters) randomly go black and monsters do it while patrolling.

I have checked the area the monsters patrol and my weapon does not go black. It is not a subtle change either, they are normal (full bright) one minute and then solid black the next.

Is there a special reason for this? (I know this is a counter productive thing to say but it does not happen in Fitz85) Is there a command line parameter I need to stop this? 

do they stay black with r_fullbright 1?

If yes, may be a texture problem.... if no, may be a lighting problem. (not a problem with your level, i mean a problem with the engine) 

I loaded the map, typed in r_fullbright 1 and I could see everything, no blackness. It looks like r_fullbright removes the light map from everything. It is very strange the blackness on certain objects, I thought it was specific locations where I have spawned stuff but it happens to wandering monsters.

I checked the original Q1 maps (played episode 1) and could not see any problems. I am using the latest compiler tools, hitting a couple of max limits but the engine still copes with it. 

It could be because I made the light check test against world submodels (plats, lifts).

I have a new revision to this with new features essentially done. I'll put a cvar in disable shadows/lighting from world submodels to see if that is the origin of the issue.

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).

The new version should be be available in 6-7 hours. 

The code that obtains shadow surfaces in Quake is actually very imperfect and can fail to "hit" a downtrace for lighting. Prior to the trace, I may have it reset the result color to black (full darkness).

Either way this shouldn't be hard to solve. 

Awesome, thanks :D I will download it and test my map once you got a new link ready.

Another bug:
When I start the engine (windowed mode) the +mlook does not work (even if I have the window selected) The old Fitz engine when it started windowed would never give up the mlook but at least I could test my maps without have to go full screen all the time. (I usually have to exit Fitz to use another application because the mouse cursor is not available to any other windows apps).

Is this a windows issue? a problem with active window focus? Or is the application (mark V) not able to control the mouse look when windowed? 

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.