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. 

I have to respectfully disagree with the rationale just given for not fixing up FOV. The reality is that hardware has moved on since 1996, and widescreen is now the norm. My own experience is that fixed-up FOV is a basic player expectation and not a fancy engine feature that's only of technical interest - I have a fairly large amount of positive feedback from people who specifically mention fixed-up FOV as a feature that they welcome.

Fixed-up FOV can be implemented without changing the defaults or other behaviour of the FOV cvar. FOV 90 will still give you the correct horizontal and vertical FOV for your chosen resolution and aspect, so everything can still work as expected.

320x200 resolution was not an aesthetic choice, it was a technical one. 320x200 was the old standard VGA mode 13h, meaning that it was the one display mode that was just guaranteed to work on everything. If that mode had been any other resolution, then that hypothetical other resolution would have been Quake's default. 

If widescreen really is the norm, just set FOV to default to 105 instead of 90. This gives correct behavior on a clean install, and doesn't override existing users configs that already have ~105 in their config.cfg or autoexec.cfg 

note that this probably means putting in a hack to ignore the default.cfg value for FOV, if there is one. But messiness under the hood may be worth it if the user experience is your highest goal. 

Why not just add a cvar to toggle between using absolute and aspect corrected fov, having absolute set as the default. 

the question is whether new users will have to change their configs, or whether existing users will have to change their configs. Any cvar like that would require one set of people to change their configs. 

A large percentage of players aren't even aware that the FOV setting exists, or - even if they are - that it can be used to correct for widescreen (the same applies to +mlook). Those that are aware of it can always re-adjust. I suggest doing some research around the usual suspects such as the Steam forums, etc, for info on the specific problems that people have with Quake; these make great targets for fixing in any engine that aims at being accessible to players. Find what prevents people from getting into the game, fix it, and problems go away. This is the same philosophy behind removing the necessity for (but not the existence of) command-line options. Identify the barriers to entry, remove them, otherwise you're just developing for a captive audience who already know everything inside-out and are therefore not bothered by this stuff (and nor are they appropriate people to pass comment on how these things should be handled).

Regarding configs, the obvious solution is engine-specific configs. The old QuakeDev forums raised this as a point that was widely addressed in Q2 ports but all but ignored in Q1. It enables more peaceful engine cohabitation by ensuring that settings specific to one engine don't wreck another.

Again, it depends on who you're developing for. The same old group of people who will always use your engine no matter what, or are you trying to reach out to new players? 

engine-specific configs
oh my god, yes! or use /documents/mygames/engineName/modName/config.cfg