Thanks for explanation!

I walked rigth up to the wall and fired the shotgun. In WinQuake the particles are small, but as soon as I start moving away (like ~64+ units away maybe?) they suddenly get bigger, like x4 in size.

In GL/Fitz/etc it's the other way around. Really 'in your face' particles are big but moving away makes them smaller, almost like this behavior is inverted from DOS/Win :)

It's just that recently I played some classic map packs (Beyond Belief, etc) and both official mission packs in Mark V WinQuake to check out (more like to remember) the 256-color look, and then I go back to QS/vk/Fitz and the particles like blood and explosions are so puny and small... 

It's unfortunate that glquake and fitzquake and friends don't have particles that feel "correct", but the behavior of software quake is hard to call correct either, so probably the best solution (if one is needed) is to provide some cvars to let users get closer to the behavior they think is best. 

Assuming I am loading an external .ent file for start.bsp (start.ent) in the ID1 folder, would that mess up any other start.bsp loaded on top of it (e.g. from SoA or DoE)? 

QuakeSpasm has checks to ensure that external content files come from the same, or a higher priority, gamedir as the base .bsp - I think this might break if your .ent files are at a higher priority gamedir than both the .bsp and the mod (so "QuakeSpasm.exe -hipnotic -game mygame", where "mygame" contains your .ents), but I haven't personally tested that so take it with the appropriately-sized grain of salt. 

and considering any other content is loaded on top of it, I assume it should be ok if there is another start.bsp somewhere else. 

BTW, has anybody ever figured out how to fix the Spike Mine in HIPDM1 which explodes right after level start and prevents you from getting 100% kills?

The relevant ENT entries are these:

{
"spawnmulti" "1"
"classname" "func_spawn_small"
"origin" "-376 248 1256"
"spawnsilent" "1"
"spawnfunction" "trap_spike_mine"
"spawnclassname" "trap_spike_mine"
"targetname" "7777"
"target" "7778"
}
{
"model" "*27"
"sounds" "3"
"spawnflags" "2048"
"classname" "trigger_once"
"target" "7777"
}
{
"classname" "path_corner"
"origin" "-360 792 1224"
"targetname" "7778"
} 

There are actually more definitions involved.

Full list should be this:

{
"spawnmulti" "1"
"classname" "func_spawn_small"
"origin" "-376 248 1256"
"spawnsilent" "1"
"spawnfunction" "trap_spike_mine"
"spawnclassname" "trap_spike_mine"
"targetname" "7777"
"target" "7778"
}
{
"model" "*27"
"sounds" "3"
"spawnflags" "2048"
"classname" "trigger_once"
"target" "7777"
}
{
"model" "*28"
"sounds" "3"
"spawnflags" "2048"
"target" "7777"
"classname" "trigger_once"
}
{
"model" "*29"
"target" "7777"
"classname" "trigger_once"
"spawnflags" "2304"
"sounds" "3"
}
{
"model" "*30"
"target" "7777"
"sounds" "3"
"spawnflags" "2048"
"classname" "trigger_once"
}
{
"model" "*31"
"target" "7777"
"classname" "trigger_once"
"spawnflags" "2304"
"sounds" "3"
}
{
"classname" "func_exploder"
"origin" "-384 216 1248"
"spawnflags" "1"
"targetname" "7777"
"dmg" "-1"
}
{
"classname" "path_corner"
"origin" "-360 792 1224"
"targetname" "7778"
} 

I am not sure if I get it right, but the way I see this, it was intended to work like this:

That tube at the top of the level (which can blow you down if you try to jump into it) was supposed to work as some kind of "mine launcher". There are 5 spots on the map that would trigger a spike mine, launched from the tunnel (with an explosion that wasn't supposed to damage the mines, apparently).

Not sure why it doesn't work, though. Maybe func_exploder and the mine spawner shouldn't have the same targetname (7777)? Or maybe there is something in the trajectory of path_corner? 

Looks like the code itself was OK, but - as so often - spawning coordinates were flawed. In func_spawn_small, setting "origin" to "-376 268 1256" (+20 on the y axis) is all it takes, and that HIPDM1 Spike Mine launcher suddenly works as intended.

In the meantime, we found out that the lavamen in DoE's R2M3 dropping to the lower floor in QSS can be fixed if you change their z origin values, too. However, it shouldn't be necessary since other ports don't have that problem. 

Do you have more entity fixes maybe? Not only SOA, but DOE and/or ID1? 

I actually fixed all id1/hip/rog maps now. Many could be taken from Maddes' Quake Info Pool, but I added a few on my own. They will be part of a vanilla fix pack I intend to release soon. It's stuff like Orion's mdl fixes, better id1 sounds from QTest, Romero's full E2M6, progs.dat and map fixes for Quake and both mission packs. I even corrected the music not playing in the first SoA demo. 

The other day I was thinking of a fix-pack like this.

Speaking of E2M6, did you (or anyone) check that there was no other changes to it, apart cutting the swamp cave entrance? Are you going to use the actual file from the "Beta 3" pre-release (converted to BSP v29) or newly created from E2M6+E2M10 map sources?

Sorry for continuing this offtopic, but on Quaddicted you posted on this subject:

> The ending of E2M5 finally makes a lot more sense since it ends in a cave which is logically continued here.

But I don't get it. E2M5 ends in some blue corridors and rooms... not in a cave. 

It's not the same map any more one way or tge other since I applied entity fixes. But whether it's merged or original, nobody could tell the difference, anyway.

But yeah, we should stop with the off-topic chatter here. 

QS 0.93.2 is already two years old, QSS and vkQ are way ahead of it by now. Any chance it gets an updated build soon? Or does anybody have at least a compiled version of latest sourcecode? 

https://sourceforge.net/p/quakespasm/quakespasm/ci/master/tree/

But I don't see a plan for any upcoming releases. 

A lot of these seem to be running in tandem with, or even coming from vkQuake which was exactly what I had hoped would happen. It may not be possible for ID to open source the Kex engine, but vkQuake is a great platform to give the new stuff to the community. 

I guess vkQuake would also be more likely to receive realtime lighting/shadows as a feature than any of the sister ports, for this will be needed to get the full visual experience in DOTM. Tried it in FTE already and it looks great. 

i love realtime lighting/shadows, i wish it became a feature in all ports (i know some people don't like it, but like any other feature it can be turned off) 

I really like how it looks in the Quake Ex. I think it shows some restraint since it's not every where. 

Kex Quake uses a mixture of static lightmaps (with lightstyle animations done on the GPU) and clustered for it's dynamic lights and shadows. It's by no means a fully realtime engine, and maybe 90% of the lighting is just good old-fashioned static lightmaps. The lightmap resolution is the same, so it's one-sixteenth the texture resolution, but the GPU animation method gives it more bits of precision.

The maps were relit with bounce lighting and coloured lighting. The coloured lighting seems to have been done properly rather than using my hacky tool, which is very nice to see. It's still using LIT files though, for BSP 29 compatibility.

I personally find the mixture of low-resolution lightmaps and high-resolution shadows to be quite jarring, but I guess different people are different. 

Version 0.94.0 of QuakeSpasm is released.

Downloads:
https://sourceforge.net/projects/quakespasm/files/
http://quakespasm.sourceforge.net/download.htm

Changes since the previous version:
https://sf.net/p/quakespasm/news/2021/09/quakespasm-0940/

- Initial support for playing the 'Quake 2021 re-release' content
(thanks to Andrei Drexler for bulk of the work, Guillaume Plourde
for Q64 bsp format support.)
- Fix rendering bug when cl_bobcycle was set to zero (sf.net bug/41)
- Fixed buffer overflow with large char skybox names (sf.net bug/38)
- Fixed a missing MAXALIASFRAMES bounds check (sf.net bug/37)
- OpenGL: workaround Intel UHD 600 driver bug (sf.net bug/39)
- OpenGL: merged surface mark & cull optimizations from vkQuake.
- Compensate viewmodel distortion at fov > 90 (based on code from
Qrack, thanks to Andrei Drexler for the patch.)
- Raised MAX_GLTEXTURES limit from 2048 to 4096 for now.
- Changed 'model has a skin taller than 480' error into a warning
- Reject lit files if they're the wrong size (eg hipnotic/start.bsp
vs id1/start.lit or just a bsp that no longer has any coloured
lits, etc)
- External ent files are now versioned using 4 digit crc of the
original map's ents, like e1m1@c49d.ent, which is much safer. The
old method (e.g. e1m1.ent) still works but isn't recommended.
- Support for external vis files.
- Save: remove CR/LFs from level name to avoids broken saves, e.g.
with autumn_sp map.
- Music: improvements to mp3 tag detection / skipping.
- Music: umx loader fix for malformed / crafted files.
- New console command music_jump: Jump to given order in music, like
Unreal's music change - only for module (tracker) music.
- Updated third-party libraries (music codecs, SDL, etc.) Other minor
fixes, tidy-ups and protability tweaks.
- Source repository moved to git. 

I just noticed that we could use a custom console background with QS. How can I add a custom picture background? What custom background are there for the console? 

Console background is 320x200 and taken from conback.lmp in id1\gfx directory. In case of the standard game, it sits in pak0.pak file. Quakespasm has it in quakespasm.pak file 

So we can't use our own background? 

What do you mean? If you don't like Quakespasm's console background, you can just either delete conback.lmp from quakespasm.pak file or remove the whole quakespasm.pak file, it only has default.cfg, conback.lmp and six .ent file to fix a couple of entities on maps.

If mod has it's own conback.lmp, then it takes priority over Quakespasm's background, just check Arcane Dimensions or Alkaline for example.