You've got a leak in the level someplace and qbsp isn't doing its job properly. Basically, the 'play area' of your level isn't completely sealed by the geometry and you've got a gap someplace allowing the playable area to 'leak' to the outside void. This makes the compiler unable to tell what parts of the level should be cut away (normally brush faces facing the void are removed, leaving only the inward-facing ones that the player will see), and it'll cause vis to not work properly so the larger the map gets, the slower it will run.

Just looking at that screenshot, an immediate leak is right in the middle, where the double doors are (assuming you've already made them func_doors)- entities don't seal the map, only solid geometry, so until you build an enclosed area past that doorway, the map will leak. 

https://imgur.com/a/Rj5FQ 

Thanks, spike, ericw and mukor for your responses to my questions.

There's a lot in Spike's answer I didn't initially understand and I had to look up a few terms. I think I have a better grip on it now, but there are still a few technical terms I don't understand, despite searching around on the internet. In particular, the part that ericw also quoted,
The engine internally uses 1/8th precision for standard networked coords (though recent engines have [optional] support for full floats). either way, the server physics is always full floats.:

What is "1/8th precision"?

What are "standard networked coords"?

What does "server physics" refer to? (As I understand it, the client/server thing is central to how Quake works, but it's all completely mysterious to me at this point; I don't understand what clients and servers have to do with single player Quake.)

Embarrassingly, I'm not even clear on what "full floats" mean. As I understand it, integers are numbers like 1, 15 or 123, with no additional fractions, whereas floats are numbers like 1.05 or 1/4, etc. (not entirely sure if I understood that correctly, though. I tried reading up on floating point arithmetic, but it was like trying to read a foreign language).

If someone could shed some more light on the above, I'd be very grateful. 

1/8th precision means that the coords are multiplied by 8, rounded, and then networked (as shorts). This is what results in the 32767/8=4096 +/- maximum bounds.
This is often described as 13.3 fixed point precision - 13 bits above 1 (including the sign bit), and 3 bits for precision below 1.
or in other words, there is a precision of 1/8th quake unit over the vanilla network protocols. that's what's meant by 'standard network coords', because its the lowest common denominator.
note that vanilla rounds coords towards 0 (because integer rounding truncates). whereas a couple of engines round to the closest value instead, because its slightly more precise. yay differences.

server physics is stuff moving around serverside. all the logic in nq is serverside, so there's none of the 1/8th rounding stuff going on.

'full float' means that it just uses 32bit single-precision ieee floats without any annoying extra rounding.
[side note: many gpus support 16bit half-float types nowadays, because gpus are cheap]
note that floats concentrate their precision around 0, the further away your coord gets from 0, the less precise it gets. They're weird in that they're expressed as an exponent, with 1 raised to the power of 8 (signed) bits, then multiplied by 23 of the remaining bits, with the final bit being used for sign. Which is annoying, because it means floats have -0 as a separate value from +0. Of course, the actual logic behind them is typically irrelevant, just remember that any time the exponent changes then the precision that can be expressed also changes.
Whereas 13.3 fixed point has linear precision, and within the 16bit confines of the inner map, floats will still have more precision than can be displayed, so yeah, you won't notice any issues, but the qbsp might if things are non-axial. 

Floating point numbers are essentially numbers with decimal olaces. When people talk about precision, they're talking about how mamy decimal places are stored by the computer.

The more places you store, the more work memory required etc, especially with older computers this could really affect performance, so Quake and other performance focused applications would store as few places as possible to get by.

The side effect of this is that you lose data by reducing the number of decimal places you store. That means that movement is (very subtly) less precise and, in the case of level compilers, data could br thrown away compared to what was actually in the source file.

Hope that helped a bit, and wasn't too incorrect. 

and since no one directly commented on this "I don't understand what clients and servers have to do with single player Quake."

Quake single player is still played on a "server". My guess is this is because of coop. 

Spike, thank you for once again answering very extensively. I'm struggling to understand all of what you wrote, because it introduces several terms and concepts I'm not familiar with at all, but I've read it a few times now after reading (and trying to understand) Wikipedia entries on the respective terms and concepts, and it's slowly starting to make a little bit of sense. Unfortunately I have no background in programming or coding, which would make things easier to follow.

ＰＲＩＴＣＨＡＲＤ, thanks, that helped a lot.

mukor, thanks, I kind of figured that it's something like that, but it still doesn't really make sense to me. In what sense is the "server" a server, and what is the "client", when you're playing on your own and unconnected to any network?

server physics is stuff moving around serverside. all the logic in nq is serverside, so there's none of the 1/8th rounding stuff going on.
So where is the rounding happening, if everything is serverside? Sorry, I'm not sure if my questions make sense. I'm really having difficulty understanding all of this. 

There are certain parts of Quake that are managed by the "server", and so even when you're playing offline what is happening is that the game launches a server inside of itself to handle all of those components, and then the client "joins" its own server.

I'm not sure exactly what parts of Quake are and aren't server side, but movement definitely relies on the server, for instance. The client is basically in charge of rendering and not much else, actually.

I think the game is built in this way to reduce workload for the developers, as it saves having to duplicate work that was already done. It's harmless to run a server inside of the client - it even comes with benefits like "listen servers", where the client's internal server is opened up to the internet and other players can join without you needing to run a separate application.

I may have rambled a bit this time but hopefully I have rambled correctly... 

Server runs the main game.
Clients connect.
All games are ran with a "server" due to design for coop.
Server handles stuff like physics, positions, velocities, monster kills, etc.
Client handles rendering of monsters, particle effects, HUD, etc. Anything that shouldn't be sent over a network (mostly). 

Yeah, and most (probably all?) networked co-op games are built in a similar way. Like you say, there's no harm in building a game this way even if its singleplayer sessions use the same framework since latency is non-existent on a locally hosted game.

There's probably a nice flowchart out there somewhere from a Carmack or Abrash talk that breaks down exactly which parts are on the server and which are on the client in Quake engine games 

Thanks for the tip! I think I've found it.
Here is the text that goes with it:
Quake’s 3-D Engine: The Big Picture by Michael Abrash.

Going to have to read that very carefully; hopefully it'll clear several things up for me.

Thanks for your responses, ＰＲＩＴＣＨＡＲＤ, Qmaster and Blitz. 

New Monitor, New Colors

Posted by SavageX [92.201.47.51] on 2017/11/30 19:49:12

Hi there,

I got a new monitor - nothing fancy, just a more "professional" (nicely adjustable pivot/height/angle) 24" Dell office thingie with an IPS panel, switching from an old 19" monitor with a TN-panel.

The colors happen to be much more vibrant/deep (not surprising - it's an IPS panel) - however, Quake looks much darker overall compared to what I'm used to. That's nothing that can't be "fixed" with an adjusted gamma setting (and I may end buying a colorimeter to properly adjust the monitor), which can give me nice, vibrant colors and a dark/light contrast I consider proper.

For me, this raises following questions, though, which are not strictly tied to my particular setup:

- As a player, are there any rules of thumb as to how Quake is *supposed* to look like? Is there any point beyond "just adjust it to your liking"?

- As a mapper, how can I make sure the lighting in my maps are okay for a wide range of recipients? My current strategy would be "adjust the display settings until the base game looks good. If my own maps look good with these settings as well, then everything should be fine".

How do you guys deal with such issues? 

On the second point, I think if you're confident of your colour accuracy, you should adjust your settings to make sure the base game looks good and then base your lighting on that. That doesn't hold true if you're using a bad monitor, as you might end up making maps that are too dark because you cranked the brightness. 

I always have the brightness all the way down or one tick higher than lowest. On occassion I'll have to raise brightness for a particular custom map, but most of the time I enjoy the gloominess.

I may be biased since bright lights hurt my eyes anyway. 

r_gamma 4
r_intensity 2
r_overbrightbits 100
r_vertexlight 1
r_picmip 100 

r_gamma 4
r_intensity 2
r_overbrightbits 100
r_vertexlight 1
r_picmip 100 

Relatively sure they were talking about Quake 1, not 3. I've wondered a similar thing myself and haven't been able to find a good answer; personally I left everything at default except gamma which is at 0.9 (no idea what the default here is, assuming 1 but that's nearly dark enough you have to squint on my monitor) but sometimes raise it up because every map is a bit different. Any lower (brighter) and most maps including id1 become a lot lighter than they probably should be, although I'll admit I haven't fiddled with the contrast cvar introduced with Quakespasm 0.93. 

Is it possible to turn a light on and then off again (without custom progs)? 

Or rather, how does one do it? Because I just remembered that at least one of the maps in this pack does exactly that. 

You mean just toggling it on and off? Give it a targetname and trigger it with a button/relay/trigger_once/whatever, works the same as a door or anything else you can activate. 

Oh, that seems fairly simple. It didn't seem to work the first time I tried, but I probably made some silly mistake somewhere in my setup. Thanks! :) 

Forgot to add, it'll only work if it's a standard light ('always on' light style): in vanilla Quake, a switchable light is its own 'style', so you can't turn on/off a light that uses anything but 'always on' (style 0), i.e. strobe, flicker, or candle.