Is there any option for a fog starting distance?

Also is there any option for a max fog density? Currently density is only based on a distance from the player view origin and anything at vast 999 protocol distances is put at max density. I would like to be able to set the max density to something like 0.2, have a density of 0 for like 1024 units or so, then gradually transition fog in from 1024 out to 8192.

Yeesh Qmaster whats next!?! a defined multiple fitted density curve??? http://scidavis.sourceforge.net/manual/pics/fit-multipeak-2.png 

Mark V has a "fogex command" with start and end.

fogex <fade>
fogex <start> <end>
fogex <red> <green> <blue>
fogex <fade> <red> <green> <blue>
fogex <start> <end> <red> <green> <blue>
fogex <start> <end> <red> <green> <blue>

Sock want to play with such a thing, so that's why the feature is there.

http://celephais.net/board/view_thread.php?id=60831&start=224

Sock toyed with it once a few years back, and I think even Sock couldn't find a compelling use for it.

So you do have an outlet to at least satisfy your curiosity. 

You can't mix distance with density in fixed pipeline fog; it's either one or the other but not both.

https://www.opengl.org/sdk/docs/man2/xhtml/glFog.xml

If GL_FOG_MODE is GL_LINEAR the start and end parameters (only) are used. Otherwise the density parameter (only) is used.

If you just implement everything in shaders you can supply your own fog equation which does this, but then of course you're raising the minimum hardware requirements.

This is similar to some of the discussions that went on during RMQ work: maximizing hardware coverage and desired features are often contradictory requirements, and you often can't have both. 

"Application Error"

"The application was unable to start correctly (0xc000007b). Click OK to close the application."

regular Quakespasm works. What am I missing? 

People do not use Voodoo graphic cards anymore 

I have to use a 32-bit install of Quakespasm, not the 64-bit. 

Pretty irrelevant, but if you try to start 2 sessions of Quakespasm-spike.exe, you get a "Unable to bind to 0.0.0.0:26000 (already in use)
".

Too tired right now to satisfy my curiosity and see how/when the sockets are bounds for single player for a non-listen server.

/Total non-issue anyway, but unspiked Quakespasm doesn't do it. 

Is there an way of enabling no filtering (i.e. crunchy pixels) on the particle textures? If not, can this be added? (Oh god please say yes) 

surely it obeys gl_texturemode, right? 

 

surely it obeys gl_texturemode, right?

Nope. 

Nope.
it's probably a 1 line of code change to add that, so no biggie.

I have to use a 32-bit install of Quakespasm, not the 64-bit.
The only issues I've had with the 64-bit QS were conflicting dll's, IIRC you can't have 32 and 64 bit QS installed in the same directory. 

its all part of spike's evil plan to stop people from using nearest-filtering!...
*cough*
that or I was just trying to get DP's effects to match, as well as fte's existing particle configs too. high-res stuff (unlike vailla quake) imho looks better with linear.
mix-n-match stuff stops it from being a 1-line change.
probably I'll add some 'nearesttexture' command for it in the particle configs.
side note: the classic particles don't respect gl_texturemode either.

and yeah, the build that I provided is a win32 build, so you'll need the 32bit dependancies.
I could provide both binaries, but for me its easier to focus on a single arch (yes, I'm that lazy).

I have fixes for sock's issues, but I got distracted by the huge deltas... and I now have to fix a load of code, and finish writing a load more. :s 

true, but you can make classic particles square using another cvar, which i think is good enough.

Good point on the high-res content, but then, I'm not sure which is the best way to mix low-res quake textures with high-res effect images, there is an inherent clash of styles there. But if someone wants to make a quakey-looking low-res raindrop, they should be able to make that nearest-filtered. 

Which cvar is that for making the standard particles square? 

r_particles 2 

In file included from progs.h:27:0,
from quakedef.h:226,
from gl_refrag.c:24:
progdefs.h:25:23: fatal error: progdefs.q1: No such file or directory 

The code from quakespasm-spike-r2.zip, that is. 

Grab the progsdef.q1 from:

https://sourceforge.net/p/quakespasm/code/HEAD/tree/trunk/quakespasm/Quake/

To solve your immediate problem. 

type map i_dont_have_this_map

Quakespasm 0.92: Console: couldn't spawn server maps/i_dont_have_this_map.bsp
Quakespasm Spiked: Fatal error dialog: "Quake Error: SV_ModelIndex model progs/player.mdl not precached

Maybe some sort of missing model support similar to DarkPlaces and presumably FTE.

But not having the map will kick you out of Quakespasm as it is a "Quake error" that terminates Quake. 

Host_Error: Mod_LoadLeafs: 121741 leafs exceeds limit of 70000.

So..why is there this concept of a limit anyway. Why can't we just keep allocating more memory as needed and just use more RAM until we run out.

On a related note, why not just precache the entirety of the progs and sound folder at start and forget about precache warnings. Just use more RAM. 

Is the map sealed?
If it's leaking, seal it and the number of leafs should go down by half or more.

No hard limit on leafs is a thing on my wishlist.

Just precaching everything: I guess it would make loading slower, cause issues on old/slow computers, and content depending on that feature would not work in other engines. 

cl_precache_progs 1
cl_precache_sound 1
cl_precache_all 1

Or maybe something like heapsize would be better:
-precache 3 (1 = folder only, 2 = sound, 3 = all)

That way there would still be compatibility with old hardware such as only 1GB ram. 

Quoth has a method to automatically precache custom sounds and models in entities in a map. AD very likely has this too.

Might tell the people in the mapping help what you are trying to do. The solution via QuakeC probably already exists. 

small note: fteqcc's new #merge feature allows 'merging' new code into an existing progs. Combined with the __wrap keyword, you can change existing functions and stuff rather than just adding.
it would be worthwhile even if it was only ever used to add something like misc_model into every mod.
The feature is still a little raw and a little wasteful, and maybe a little too permissive as well, but should otherwise work without needing to decompile anything (and without all the resulting breakages of decompiling).