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. 

@Poorchop:
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.
This should make QS render to a half-sized framebuffer (for r_scale 2) and scale it up with nearest interpolation, so each original pixel becomes a 2x2 square. There shouldn't be blurring in the upscaling. If it is actually blurring the pixels together, mind posting your system info / screenshot?

It's not difficult to do, just that it absolutely needs fragment shaders, which might be a step too far for some.
QS 0.93's world faces and alias models go through fragment shaders, so just water, sprites, particles, sky, and anything else I'm forgetting use fixed-function at the moment.

I do want to implement this at some point! (I tried a quick hack a year or so ago, that postprocesses the final 32-bit rendered frame. What I did was make a lookup table from rgb565 to the nearest Quake palette color, then just feed in a 32-bit pixel, decimate it to 16-bit (565), then lookup the nearest Quake color and output that). As Kinn was saying, palletizing a 32-bit rendered image that has fog already baked in tends to look like mud, so this needs to go into the fragment shader before fog is added.

The faster / more natural / software faithful way of doing it is to ignore colored lighting and use the colormap.lmp just like software, having the fragment shader read the textures as 8-bit. Another option is to support colored lighting by blending with the lightmap in 32-bit, the using the rgb565 lookup table to convert that to paletted. 

Oops you actually mentioned r_scale!

Hmm I haven't had any blurriness issues with that, assuming the necessary setting of gl_texturemode. 

Maybe saying that it looks blurry was the wrong choice of words because it does appear to be doing exactly what you mentioned. It just doesn't look like upscaled WinQuake, which is what I was kind of hoping. I guess I went with blurry because when moving around, it kind of looks like what you would see if you were playing in biting cold wind and your eyes were watering.

Here is r_scale 1:
https://i.imgur.com/jJBlmWr.jpg

and here is r_scale 5 (went with a much higher value to better demonstrate what I'm talking about):
https://i.imgur.com/UUCZLV0.png

The few rows of pixels going across the screen around where the shotgun model ends exemplifies what I mean when I say it looks blurry. This is especially true when moving.

The only pertinent visual setting that I'm using is gl_texturemode GL_NEAREST_MIPMAP_LINEAR but I think that I also tried this with gl_texturemode 1 with pretty similar results. This is on Windows 10.

Also interesting stuff Kinn. I haven't really put my finger on what exactly it is that captures the original look but it probably has more to do with what you said rather than just chunky pixels. I haven't tried FTE yet but I'll give it a look to get an idea of what you're talking about. Granted newer maps that take advantage of the fog and colored lighting still manage to look really beautiful in Quakespasm - trying to preserve the original look probably would be more of a detriment in this case. I'll have to look at FTE to get an idea of how the fusion of new and old holds up. To be fair, I'm not too hung up on retaining all of the old visuals because I do like the frame interpolation with animations in modern engines and I like the feel of modern engines especially with regard to the more comfortable mouse look. 

The few rows of pixels going across the screen around where the shotgun model ends exemplifies what I mean when I say it looks blurry.

That is a problem with the way that GPUs choose mipmaps. WinQuake uses the nearest vertex distance to determine which mipmap should be displayed on the polygon, but GPUs uses the farthest vertex distance, therefore choosing lower-res mipmaps.

I recall someone explaining this in another thread here, and that there's no solution because there's no API to finetune this behavior on GPUs. The only way to minimize the problem is through anisotropic filtering, but afaik it only works in GL_LINEAR_MIPMAP_LINEAR.