Thank you Gunter, but unfortunately your server is not meant to connect from my country (Russia), ping is almost 150. The idea of implementing RPG elements in Quake is quite interesting though. 

ad_sepulcher needs a bit more than just the standard "big map" support.

It's also the case that there are a handful of big static arrays scattered about the engine for which, by the time you move to supporting ad_sepulcher sized maps, you really need to move to dynamic allocation.

Finally, ad_sepulcher is going to run like shit in the GL version of MarkV because it still uses glBegin/glEnd code. It will run fine, but still far more poorly than it should, in the D3D9 version because it's transferring a lot of vertexes that don't even change to the GPU each frame. The particle system may however kill it with draw call counts; IIRC there's some very sub-optimal state change stuff hanging over from the original GLQuake still in the sprite code, and that's going to prevent the D3D wrapper from being able to batch things up. 

Man, I would have killed for a 150 ping 15 years ago when I was still using dialup and playing lots of Quake, and still kicking butt in deathmatch :D

But these days people think a 150 ping is unplayable, even in coop! ;) 

ad_sepulcher doesn't run reliably in QS either. It crashed from time to time while I played, which forced me to quicksave often.

Making an engine that runs it reliably seems to be one of the ultimate challenges in Quake engine coding. 

That's interesting; I would have thought that QS was the target engine when the map was being built, and would have received the most testing through all iterations of the build. 

 

Well, my laptop has an Intel HD Graphics 3000 GPU and 6 GB of RAM, running Windows 7 64-bit. And the crashes happens after exploring the map for a while. First the engine starts stuttering and the hard drive starts making noise like crazy, and then the engine crashes. 

...the hard drive starts making noise like crazy...

Sounds like something else wrong with your machine that's only manifesting when it's under a particular load. There's absolutely no way that any Q1 map should be thrashing the HD under normal play - everything is in memory. 

Baker I'm 99% done adding ogg/mp3 to Qrack using fmod.
It's *way* simplier than you might think. Only thing i have to do is add a cvar to init/uninit the fmod instead of using a command-line parm.
I can shoot you a copy of my fmod.c file. There are other entry points where it plays cd tracks but they all points to functions contained in that one fmod.c file.

It's so simple i was kicking myself for not adding it sooner; not until i read here people yelling "OGG SUPPORT!" did i even pursue it. Know you use fmod, i thought i'd pass it along. 

I'm not sure if there is anything special about ad_sepulcher that makes it difficult to run - it has careful visblocking and with the fixes to func_detail in qbsp I made, the PVS is good quality. I'd expect it to have similar fps to other large maps in AD (and it does in my experience).

(The exception is if the engine supports the fancy particle extensions, i.e. QSS. Particle effects for all torches in the map render every frame without regards to the pvs. Also, various particle effects cause tracelines to run. This applies to all of AD, though it probably has the biggest hit on sepulcher due to probably having the most torches.)

Sorry to hear it crashed for you mankrip. The only thing I know that could cause disk thrashing is Quakespasm uses the original Cache_* code, which, if the cache is too small, will cause it to read MDL's off disk every frame. This is something I want to fix and I know of mh's tutorial on insideqc about it. Do you remember if you used an explicit size with the -cache command-line argument? 

There's absolutely no way that any Q1 map should be thrashing the HD under normal play - everything is in memory.

Windows automatically stores RAM contents in the swap file, you know. And it also happened without anything else running, right after I had to reboot because the whole OS got unresponsive.

I might run it again later and take a look at the RAM/CPU/etc usage in the task manager. 

Do you remember if you used an explicit size with the -cache command-line argument?

IIRC I've only used the parameters recommended in the readme file. I may look into it after going back home. 

There's absolutely no way that any Q1 map should be thrashing the HD under normal play - everything is in memory.

If the quake cache is too small, quake will keep unloading models to make room for new models. A bigger heapsize solves this I think. (in engines with standard quake caching/memory logic.) 

Yeah, the caching system is really the only thing, other than some kind of hardware failure, that could cause this.

It's worth observing that if one is using a replacement/"improved" MDL pack, they're going to consume more cache space and therefore have a higher likelihood of triggering this kind of behaviour. 

This seems to have gotten lost in the noise.

From the description it seems that MarkV doesn't have the robust SV_TouchLinks fix. Some discussion: http://forums.insideqc.com/viewtopic.php?f=3&t=1431 

Just had a look at the MarkV SV_TouchLinks fix. It's, umm... unusual...

My recollection is that QSS has a sensible fix that's absolutely trivial to lift over to any engine, so that should be the way to go. 

An interesting observation about MDL caching.

It's possible for 2 or more MDL files to only differ in terms of the skins they use; otherwise they have identical geometry (vertices, frames, triangles, stverts).

You'd think this would be a theoretical possibility at best, but it actually happens in ID1: progs/spike.mdl and progs/s_spike.mdl are identical aside from skins.

Load up ad_sepulcher and there are about 30 MDLs where this happens.

So to save memory with MDL caching, and also potentially save memory with VBOs if you use them, this is something you could check for, without being too disruptive to the rest of your code. 

I don't know if the SV_TouchLinks thing is similar to the old engine-crashing teleporters without proper destinations bug, but a QuakeC fix is mentioned here: https://www.quake-info-pool.net/q1/qcwa.htm#trigger_teleport 

I don't think that is related to SV_TouchLinks.

Here is Quakespasm's SV_TouchLinks fix which I adapted from Spike's in QSS:
https://github.com/ericwa/Quakespasm/blob/master/quakespasm/Quake/world.c#L325 

Is there a particular reason why Mark V (1081) wouldn't copy over screen resolution settings from id1 folder when running mods from custom dirs? 

 

I am used to Mark V taking all settings from config.cfg located in the id1 folder... 

Here's my QuakeSpasm parameters for AD. They're from the readme:
-game ad_v1_50final -heapsize 256000 -zone 4096

The ad_sepulcher readme says to use these:
-game ad +map ad_chapters

I'm not sure if something else could be causing system overload. Maybe the Intel HD Graphics 3000 drivers emulating stuff in software? 

I've implemented a SV_TouchLinks "fix" in my code, and it broke the end-of-level teleporter in the map Citadel of Doom. That map is good for testing. 

Spike's more robust SV_TouchLinks fix works fine in that map.

The Intel HD 3000 should not be emulating anything in software; it's right at the start of the "Intel graphics are no longer crap" era and IIRC will even run Doom 3.