In the end we ended up playing with ericw's patch for vanilla QS. No issues there.
All in all, that patch was a gateway drug! :P The code is easier to read than I first thought it'd be, so now I'm adding 6DOF. If I'm not mistaken this is something that can't be implemented at a qc level, right? I have but a passing familiarity with quakec, so maybe this could be less client-dependent and I'm not realizing it.
Either way, having much fun with this, keep up the good work. 

Any hope for incorporating some of the additions to the Arcane version of Quakespasm/QSS? Like the mod menu. 

So is pampa the anon mystery guy that wrote the 6DOF version of FitzQuake several years ago and then Spike added the modification to FTE? 

Huh, seems someone stole my idea and went back in time, right? :P
I wasn't aware such a thing had been done before, but will def. check up on it. 

https://www.youtube.com/watch?v=w8aUI9flEvc

https://www.youtube.com/watch?v=djb-KVxcih4

The source code was on the dead Google repo, but as I understand it there is often some way to find it using the URL and some ingenuity.

Dead source link: https://sites.google.com/site/quakeconfig/6dof-quake 

Trippy, but man that guy plays slowly. 

So I just switched my quake dev folder over to my new laptop and it has apparently decided it doesn't want to run :( I am using v0.93 on Windows 10 Home 64 bit btw. Here is some info about the error I got from event viewer


Faulting application name: quakespasm.exe, version: 0.0.0.0, time stamp: 0x5a1299a0
Faulting module name: ig9icd64.dll, version: 23.20.16.4973, time stamp: 0x5a96b1e5
Exception code: 0xc0000005
Fault offset: 0x0000000000196be5
Faulting process id: 0x2c2c

Neither the normal or SDL version work. Is there a newer version I can try? This will be somewhat of a hindrance when it comes to testing my maps in the future if I can't run them in the first place... 

And here is a stdout console dump from the SDL version, there doesn't seem to be anything wrong with it but maybe you can find something?

Found SDL version 1.2.15
Detected 2 CPUs.
Quake 1.09 (c) id Software
GLQuake 1.00 (c) id Software
FitzQuake 0.85 (c) John Fitzgibbons
FitzQuake SDL port (c) SleepwalkR, Baker
QuakeSpasm 0.93.0 (c) Ozkan Sezer, Eric Wasylishen & others
Host_Init
Playing registered version.
Console initialized.
UDP Initialized
WIPX_OpenSocket: Address family not supported by protocol family
WIPX_Init: Unable to open control socket, IPX disabled
Server using protocol 666 (FitzQuake)
Exe: 11:56:35 Nov 20 2017
256.0 megabyte heap
Video mode 640x480x32 60Hz (24-bit z-buffer, 0x FSAA) initialized
GL_VENDOR: Intel
GL_RENDERER: Intel(R) UHD Graphics 600
GL_VERSION: 4.5.0 - Build 23.20.16.4973
FOUND: ARB_vertex_buffer_object
FOUND: ARB_multitexture
GL_MAX_TEXTURE_UNITS: 8
FOUND: ARB_texture_env_combine
FOUND: ARB_texture_env_add
FOUND: SDL_GL_SWAP_CONTROL
FOUND: EXT_texture_filter_anisotropic
FOUND: ARB_texture_non_power_of_two
FOUND: GLSL
Intel Display Adapter detected, enabling gl_clear

Sound Initialization
SDL audio spec : 44100 Hz, 1024 samples, 2 channels
SDL audio driver: dsound, 65536 bytes buffer
Audio: 16 bit, stereo, 44100 Hz
SDL detected 1 CD-ROM drive
CDAudio initialized (SDL, using E:\)
CDAudio_Init: No CD in drive

========= Quake Initialized =========

execing quake.rc
execing default.cfg
execing config.cfg
couldn't exec autoexec.cfg
3 demo(s) in loop

FITZQUAKE 0.85 SERVER (51103 CRC)


Introduction
Using protocol 666
Couldn't find a cdrip for track 4
jl entered the game 

This came up in google when I searched for that dll: https://communities.intel.com/thread/125368

Try updating your intel graphics driver.

Also 0.93.0 is not the latest version of QS (it still shouldn't crash, but might as well update to 0.93.1) 

Hm, I had an Intel graphics driver update the other day and installed it, or at least it supposedly installed... maybe it is a crappy HP custom one, I'll try to find the latest generic version for the hd 600 and try again 

I just ran the update for the latest intel hd 600 update on August 9 (https://downloadcenter.intel.com/download/27894/Intel-Graphics-Driver-for-Windows-10?product=126787) and it still won't run :( I mean I know my laptop is pretty low spec but don't tell me it won't run a game from over 20 years ago... GZDoom will run but QS won't, great. I guess I'll have to use FTE or something for the time being, unless QSS is still being updated? 

So I might have discovered part of the problem on accident. I was trying to compile what I had done on my underwater jam map (which I wasn't able to complete by the deadline unfortunately) and I somehow managed to give the wrong wad path so qbsp wasn't able to texture my map and to my surprise, my untextured map loaded :O BUT when I tried to go to another map it crashed. So it is something to do with the textures, I'm not sure if the gou doesn't have enough vram (that would be my first guess though honestly I would be surprised if that's the case given how old quake is and the low res textures typically involved) or the way they are rendered or what, but it definitely has something to do with that 

unless QSS is still being updated?
Yes it is. Latest version (r10) is following the changes made to QS 0.93.1. But if your laptop is too old your framerate will be loooooow: I installed both engines on a Dell Inspiron 9400 (Core2Duo T5500, 2Gb RAM, ATI Mobility Radeon X1400) and QSS is pretty much a slideshow while QS runs fine. 

Couple more debugging ideas:
- could you check the QS console output again to confirm the GL_VERSION, just want to confirm it's the 24.20 driver that is still crashing.
- Launch with -noglsl to switch back to the GL1 rendering code. By default it will use OpenGL 2 if available.

QSS will probably behave the same because the renderer is mostly identical to Quakespasm. ( @Mugwump if QSS is slower it's probably because a mod like AD is using the hd particles. ) 

Yes, the framerate drop is quite drastic in AD, but I also noticed a lesser difference in non-AD maps. 

But now the mouse pops up on the screen after a couple of seconds in fullscreen mode which is *really* annoying because it causes the window to minimize :/ I'll try QSS to see if that helps but I'm not holding out any hopes.

Also the laptop isn't old per se but rather new and cheap so it has some less than stellar specs, but the gpu does have opengl 4.5, DX12, and vulkan 1.0 support so I don't get why QS would be crashing with GLSL enabled since it should be supported? Also Mark V works without any console fiddling if that helps 

Spiked gave same result, only works with -noglsl but in -noglsl the mouse stays above the window and clicks out of it. I wish I could tell you what exactly is going wrong with the GLSL rendering that is causing the crash but I'm not sure how to get that information particularly. 

FTE and Mark V both work with OpenGL though, trying to use vulkan in FTE caused it to have a freaking seizure which is more or less what I expected would happen if I tried to run a game with vulkan on here LOL, it just isn't good enough for that even if it has it. I also apparently get over 400FPS in FTE with the vanilla/"spasm" graphics settings which is always good. So maybe I'll switch to FTE for the time being until QS gets its crap together with the GL renderer. 

until QS gets its crap together with the GL renderer

You might consider that ericw does what he does for free and that engine development is hard and involves many combinations of operating systems, graphics cards and equipment.

@ericw - I have Mark V log the command line in the log. That way if someone posts the log, you don't have to ask what command line they are using. 

well, ok, what I meant by that was "until ericw can find the problem and it gets fixed". Like I said if I could figure out what the problem was exactly I would give more helpful info but he is probably in a much better position to do that than I am since he is the one developing it. I guess the best advice I could give is buy a cheap crappy $300 or under laptop like the one I have with intel HD 600 or similar GPU and profile it and see what part of the renderer is causing it to get angry, the one I have in particular is this one

https://support.hp.com/us-en/document/c05987723 

Translation:

"I'm having an issue running a 20+ year old game on my laptop! Go spend hundreds of dollars tracking down an esoteric issue I can solve by using other software."

This makes zero sense to me. It's good to ask for help, but to suggest that Eric spend hundreds of dollars to help you out is pretty wacky! 

As engine developer, if my engine didn't run on a popular computer running a popular operating system using a popular graphics card I'd be irritated. But "we cannot safely draw that conclusion yet".

All that is seen so far is someone appearing to have an issue exclusive in the universe to their computer (but it might not be -- re:poorchop + Mark V).

Whether or not the suggestions by individual having a problem are feasible, there is still a problem.

And so goes engine coding. Which is why engine coding is hard. Engine coding is being the frontline for unwanted situations/knowledge. And you are always better to know about them! 

I have a laptop with Intel graphics. Actually I have 2. They both run Mark V and QS fine. The only issue is that the 4k laptop is a bit choppy. 

I see, what model of intel hd is it? And is it "HD" or "UHD", mine is a "UHD" 600. Also maybe you should try lowering the resolution of the game to increase the FPS, playing quake in 4K doesn't really make much sense especially on a weak gpu, my max res for quake would be 1080p personally 

I've one with an Intel UHD 620.

It easily hits over 1000 fps in ID1 timedemos.

It plays Doom 3 at over 60 fps.

It runs QS and other engines flawlessly.

So I guess you need to give more info about what you're doing to cause QS to have a meltdown. You mentioned something about a map you're making - is your problem confined to that map only? Can you run other content? Can you share the map (or a minimal example that reproduces the problem)? Single-stepping the texture loader in a debugger seems a good place to start, based on other info you've provided. This is going to be something like a 0-sized texture causing a code path to trip over itself.