unlike vanilla, quakespasm should allow -subdivide up to 1984ish.
fte+dp go up to 4080ish.

such sizes can hinder lightmap atlasing, so its probably best to keep them somewhat sane in size.
this is especially true for weird shaped surfaces where much of the block isn't actually used - more divisions doesn't always mean more lightmap data. that said, if you've a lot of 256*256 texel surfaces and you're targetting at least qs then bump the subdivision size by a little, to avoid those 256*256 surfaces getting split into 4 separate surfaces. 

Maybe some or all of these questions are laughably basic, but I don't know the answers and I'd like to.

--> Is it important always to stay on-grid in Quake? (I don't mean as a rule of thumb or as a general guideline for newbies, but really always.)
--> If so, why exactly/ If not, then when is it important?
--> And does it apply to modern compilers and engines, or is it something that is (partly?) related to the limits of the original compilers and engine?
--> And does it apply to e.g. detail brushes as well as worldspawn?
--> What is the practical difference between on- and off-grid brushes when compiling and when playing?
--> And finally, what does staying on-grid actually mean? Is it that each brush has to have all vertices on-grid, or is it enough if e.g. four out eight vertices are on-grid? Is it relevant whether brush faces pass through points of the grid? 

early exporters always rounded coords to the nearest unit. modern stuff doesn't really require that, but legacy and all that... probably your map editor has an option in its export settings. note that rounding could uglify various maps...
the vanilla qbsp truncates on load, rounding towards 0 instead of to nearest.

rounding verticies to the grid also means you can avoid floating point precision problems that result in micro-cracks and associated leaks that prevent the map from being vised, in such a way that can be horrible to track down.
this also goes for axial surfaces too, of course.

rounding verticies is one way to avoid excess texinfo entries in the final bsp. note that this is really more of a size thing than any real performance issue. note that this is only really an issue with 'valve' map files. quake's vanilla texture alignment stuff sucks enough that they'll all get merged regardless.

note that constantly converting from/to verticies and planes will accumulate inprecision. rounding avoids that.

the engine itself doesn't really care if something was on or off grid - it can bug out regardless. 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.

so yeah, the only real issues are
1) accumulation of inprecision.
2) cracks (which have many other causes, so why care?). csg carve sucks anyway.
3) old editor/qbsp compat.

or something. I'm really just making this stuff up as I go. Here, have a pinch of salt. 

From a purely design viewpoint: Its good practice to stay on grid. I'd say a majority of us build on grid but there are some out there who dont. MFX's ad_swampy has a lot of off grid arches. 

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.
The weirdest glitch I saw due to off-grid was in ad_swampy and due to this.
An item_health was dropped to the floor (which happened to have an off-grid Z height), then going through the 1/8th precision network moved the mdl into the floor. The mdl rendered black as a result, because the traceline to sample the lightmap started underneath the floor. 

I've been mapping for around a month now and I just remembered what levels are supposed to look like when you noclip out of bounds. they should look like this https://i.imgur.com/g9YjNCm.png but mine looks like this https://i.imgur.com/I1mNEwW.png
I honestly have no idea what that's called (if it has a name) or if it's even important yet but I'd like to know how to do it. 

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.