Give commands suggestion:
The mod should be able to define the give commands in the quake.rc file or default.cfg.
Something like:
set give "1", 2048
set give "2", 4096
set give "3", 1024
set give "0", 16384
set give "n", 256
set give "s", 512
Etc. Etc.

This would also add ability for any char to give specific mod ITems. Well, except for .items2 or .moditems that is.

I'm okay with having builtin give overrides for the mispacks, but any more and it gets ridiculous adding in a bunch of mod specific checks. At least this might provide support for these cheats to future mods or allows enterprising Quakers to make their own mod quake.rc updates and share them for different mods. 

ericw and DabbingSquidward, thanks for your help. I was wondering why one of the executables was called quakespasm-sdl12.exe instead of *-sdl2.exe. I read the changelog yesterday but I guess I somehow missed that part. That explains why I wasn't having issues in 0.92.1 - I was using SDL 2.

I've been swearing off Windows 10 for years but I finally decided to give it a shot, and of course it's the root of many of my problems, not just with Quakespasm. Go figure. Anyway, I tried the standard .exe with 0.93.0 (SDL 2) and it's working perfectly. Thanks for your help. 

The mod should be able to define the give commands

In that case, aliased impulses would work better, because they're compatible with any engine.

The "give" command is for end users, not for mod authors.

A middle ground would be to make the "give" command accept raw bitflag values. Accepting raw bitflags only would make the code even cleaner. 

Speaking of which, what are all the items that the 'give' command is able to grant? The ones I know of are:

3-SSG
4-NG
5-SNG
6-GL
7-RL
8-LG
H-Health
A-Armor (Fitz, Spasm & Mark V)
S-Shells
N-Nails
R-Rockets
C-Cells
L-Lava Nails
M-Multi Rockets
P-Plasma

Is there anything I missed? To add to the suggestion, it would be nice if the command accepted whole words or classnames, like in GoldSrc or every engine beginning with id Tech 2. Such as "give weapon_supershotgun", "give ammo_shells_large" or "give item_artifact_super_damage". 

That's pretty much complete, aside from some Hipnotic weirdness in the weapon give commands (0 = hammer, 6a = proximity gun, 9 = laser cannon). 

The "give" command is for end users, not for mod authors.

I'd go one further and say that the "give" command is a cheat, so it shouldn't be expected to be 100% robust.

it would be nice if the command accepted whole words or classnames, like in GoldSrc or every engine beginning with id Tech 2

On the surface this seems a reasonable and sensible proposition.

However, Quake 2 fully moved the "give" command into the game DLL, meaning that mod authors were responsible for writing up it's behaviour.

Would Q1 mod authors be willing to accept something similar?

This is a more general issue with proposals of the "Q2/HL did it so why can't Q1?" nature; making such changes can involve architectural changes which may break compatibility. Of course Q2 and HL didn't need to be compatible with Q1. 

Yes, something like that in the Q1 architecture would be a massive hack. And imo, hacky features are the main responsible for feature creepiness in such projects, dragging the projects to a slow death.

The less silly code to maintain, the better. 

give muh-bits 

Just use [krimzon_]SV_ParseClientCommand.
Then the mod can provide whatever it wants without needing the user to do weird stuff etc, and without the engine changing quite so many random fields and breaking stuff by doing so... 

mh: In your specific case, the original IT_ARMOR1 define has a value of 8192; in the Rogue mod that's actually RIT_LAVA_SUPER_NAILGUN, so hence the behaviour you see.

Haha, just when you think there are no more quirks.

Also falling scrags in demo1.dem seem to not interpolate their fall.

Haha. mh and Spike explored/explained that one years ago --- it is a horror story of vast cruelty related to monsters and lifts.

Basically --- it cannot realistically be fixed.

Which I think that means mh might have tried in DirectQ, haha ;-) 

I tried, I failed, I crashed, I burned.

The problem is movement (*NOT* animation) interpolation is done differently for the two different classes of entity, resulting in minor differences and oscillations in positions.

I don't think there's a 100% robust one-size-fits-all solution for this. 

On lifts? Dead bodies could use MOVETYPE_FOLLOW.

On demo1.dem, where a dead scrag falls in the GK water pool? I'm not sure. It seems to be more of a general problem with far away entity movement being not interpolated correctly, since in some engines it also happens with the living fiends walking at the bottom of the water pit in the beginning of E2M2. 

Is there a way to scale up lower resolutions similar to Mark V WinQuake in order to get the classic chunky pixel look? Mark V WinQuake allows you to play at modern resolutions but scale up from 320x280 or 640x480 and it looks pretty true to the original even when playing at something like 1080p. It also preserves the original HUD scale.

WinQuake is great for closely approximating the look of the original game while still playing on modern monitors but I can't get the music to work and a bunch of new maps/mods utilize Quakespasm features. I feel like at least part of the original look could be recreated with upscaling. I tried setting r_scale to a higher number but that just makes everything look really blurry instead of crispy and chunky, and I can't find any other scaling settings apart from scaling the HUD. 

gltexturemode gl_nearest_mipmap_linear helps Quakespasm look a bit more WinQuakey. 

I'm assuming you have your music in ogg-format. Mark V (infamously) doesn't support it (or at least I think it still doesn't). MP3 works at least. 

Mark V has native Mac and iPhone ports. Apple API does not do OGGs.

Apple API decodes mp3 via hardware acceleration and stop and start music at the drop of a pin including on Windows. Other engines cannot do this and have to do things like restart the map and such.

Mark V also does not need any DLLs to do what it does.

Also mp3 decoding via hardware uses almost no CPU, especially important on a portable device like an iPhone due to battery.

mp3 > ogg simply because all Intel and ARM chips have MPEG accelerated decoding built into the chip.

This is why your DVDs play fast. This is how music on your iPhone or Android phone plays.

Try playing an ogg on an Android phone and watch what it does (hint --- it says "converting to MP3"). 

Disabling texture filtering certainly helps but it still looks quite far from WinQuake without being able to scale up while preserving the aspect ratio. Also thanks for the advice regarding the music. I'll try the mp3 files instead so that I can have some music alongside the chunkiness of WinQuake when playing through vanilla stuff. 

I also like to play the id1 episodes on Mark V Winquake. :) Same goes for the early custom maps that don't have lits and stuff.

Interesting stuff, Baker. I didn't know how well MP3s are supported all the way down to the hardware level. I'm starting to see, why you're defending it over ogg so vehemently. c: 

Yeah, most people don't know (nor care) about the implications of music play on all platforms. I did some engine modding a Playstation Portable Quake. It had a hardware mp3 decoder and also a software decoder libmad. The hardware decoder ran like lightning. Libmad software decoding ran like total foobar with 19 fps.

I try to study the proper way to do things and know exactly why I am doing them.

I have literally watched Quake engines crash and burn that did not know why they were doing what they were doing.

And what's funny is common factor tended to be doing "what most people want" (at the time!) against long-term "health" without understanding "what most people want" is fickle and subject to change at a moment's notice. 

Poorchop, big crunky piskels is one thing, and I'm somewhat of a fan of that, but for me by far the #1 thing that gets the "WinQuake look" is if the lightmapped textures are drawn via the quake colormap, to get the proper 8-bit palette colours.

Now, FTE does this accurately with its r_softwarebanding option. I don't know of any other GL engine that does it properly, but FTE does. Of course, software engines all do it, but I also quite like having double digit framerates in modern maps, so a GL engine is the only option for me.

With r_softwarebanding on, just firing up start.bsp and looking up at those wooden boarded ceilings, letting myself melt into those rich chocolatey shadows, is enough to give me a proper Quake boner.

A lot of people instinctively dismiss the idea of Quake pallettisation in the modern age of coloured lighting and fog, and indeed if you just did the pallettisation as a post-process effect, then yes, it looks like total arse because of that...

However, FTE neatly avoids this by just doing it on the Quakey bits, and then the coloured lighting and fog just tints the colours "on top of" all that, and it just works and looks absolutely great. Best of both worlds.

(All well as a reply to Poorchop, this post is also a thinly-disguised plea to ericw to do FTE-style r_softwarebanding in QS, but I think I've been fairly subtle about it, mwahahah). 

It's not difficult to do, just that it absolutely needs fragment shaders, which might be a step too far for some. 

I used to prefer WinQuake's distorted colors too, until playing enough maps with custom textures to realize that it looks like ass in way too many cases.

It's only aesthetically safe to use in vanilla Quake textures, because they were carefully designed for it.

Try playing maps such as SEWAGE.bsp, nar_cat.bsp or dwmtf.bsp in a standard software renderer. Instant vomit. 

Yeah, custom textures that rely too heavily on the terrible grey line will look like toss in software mode.

But I think it really makes well-designed textures come alive. The default GL-style lighting makes it all look a bit flat and sterile in comparison. 

Yeah when designing textures for quake's software renderer, there needs to be a a lot of noise and roughness, grimy/crusty materials looks best. Wide areas of a single color look really bandy and bad (but are fine in opengl) -- so you have a generation of custom textures made for glquake where people never even looked at it in software mode.

Also the voodoo cards which everyone had in 1997/8 to play GLQuake had its own dithering/grittiness/muddiness that actually enhanced the look of Quake. 

To come back to the pixel-scaling thing for a sec, in Quakespasm you can try different values for r_scale. I don't remember off the top of my head if this is also reflected in one of the GUI menus.