News | Forum | People | FAQ | Links | Search | Register | Log in
Quakespasm Engine
This engine needs its own thread.

Feedback: I like the OS X version, but I have to start it from the terminal for it to work and can't just double-click it like a traditional OS X app. I'm sure you guys already know this, either way great engine.

http://quakespasm.sourceforge.net/
First | Previous | Next | Last
 
I don't think .scale is a good idea for reasons outlined by Spike, with which I'm in full agreement.

It's important to remember that the RMQ engine was a tech demo. One of it's purposes was as a semi-experimental test-bed for new ideas, not all of which should be expected to work well. Another of it's purposes was to become obsolete as ideas that did get bedded-in and nailed-down were picked up by other engines. It's a natural consequence of those two purposes that sometimes the implementation might be a bit wonky, or might simplify to a special case, or whatever. The point is: RMQ engine's implementation of .scale might not be a great model to work from. 
Scales 
RMQe's behaviour is fine, and is consistent with DP_ENT_SCALE, so that's a good thing.

But yeah, the hull issues make automatic scaling unworkable, so scale without qc is generally a bad idea.

So imho RMQe's scale is fine, and more robust than hexen2's... 
@mk -- Actually No 
"Hmm, that would require a protocol change then. Or a modified model, or CSQC."

Nope. Neither.

1) Open up, say, QME and double the model size.
2) Change the .qc setting the box -- you might need to add a new monster. This would at least get the Ogre's feet touching the ground appropriately.

3) If you decided to make a monster too big for a Quake hull (Shambler size?) -- you better add some invisible func_walls to box the bastard in too hide the lack of proper collision.

You can do what you want to do today and it would work in any Quake engine including and be done in 30 minutes.

Just don't get forget the asterisks. ** Any proper map using a "too big" model like the QTest dragon (Once Upon Atrocity, for instance) needs to "no clip block him in" to his area and close the door behind the player so he can't be sticking his dragon wings through the walls.

The Kurok engine actually had a special brush type "monster_clip" for special clip brushes that instead of blocking the player would block only the monsters instead --- in the case of Kurok, it was a helicopter shooting missiles and the monster clip kept it in a defined box.

The Quake map "Source of Power" https://www.quakewiki.net/archives/underworld/quakerev030624.html ... had baby Shamblers in GLQuake -- and I can't remember the name but some map had a 2x sized fiend or Rogue gremlin or something like that. It was also a map that ran in WinQuake/GLQuake just fine.

The short version is that ".scale" is and always was ".completely_broken_scale" that sounded cool unless you knew how broke it was.

It doesn't solve any problems and creates false newbie-sauce visions of grandeur -- and you can manually create a double sized or half sized fiend that works in WinQuake/GLQuake.

/Someone should find the guy who came up with the idea for ".scale" and slap him with a wet fish. 
 
You can do what you want to do today and it would work in any Quake engine including and be done in 30 minutes.

My idea was to use .scale in an animated way, and with non-arbitrary sizes. There would be a maximum size, but the tarbaby would also have any size between the minimum and the maximum.

Using multiple models would kill the model interpolation and wouldn't provide non-arbitrary sizes.

The animated shadows in Fightoon were created using animated scaling. The higher in the air the player gets, the larger (and more transparent) the shadow gets. This would be absolutely impossible to create in a regular engine. 
 
And here's another example of animated scaling usage. This effect dynamically resizes the model to the intensity of its entity's lighting.

I just didn't try figuring out uses of .scale for solid objects before. But for purely visual effects, it's a clear improvement. 
 
Using multiple models would kill the model interpolation and wouldn't provide non-arbitrary sizes.

You could author a new animation of "growing" from size N to size N+1, in each model. Play in reverse to shrink. This means he can't do anything else while he grows/shrinks, though. 
 
Also, the vertex compression would still cause the transition from one model to another to be jittery.

Using multiple models would still be a hacky & inefficient method. But the bigger issue is that the physics would likely end up even more hacky.

A proper solution for the physics would probably be to use the Q2 BSP format, which uses raw brushes for collision. But this means that such gameplay ideas aren't suited for Q1 anyway. 
Malice Issues 
why does the minigun skin in malice get messed up in both quakespasm and glquake?

also the probe wont fly about in quakespasm either... 
Small Idea / Request Thing 
Would you consider a "devkill" command? (short for "developer kill")

It would function like "kill", in the sense that the map and entities are all reloaded. However, it would preserve:

player position
player view angle
the current state of god, notarget, noclip.

When doing a lot of very rapid iteration on part of the level design, I realise most of my time is spent noclipping over to the place in question to test out the changes :/

I could fudge this in QC but then I think it would better if the feature was available engine side so you can use it in all mods.

For world geometry changes only, I can fudge it by just using save/load, but that doesn't work for any entity changes.

Just an idea. Would anyone else find it useful? 
Sure 
 
Pretty Cool Idea Yeah. 
I'd use it. 
"devkill" 
Save the state of the player entity only, minus dynamically referenced fields like entity and model references, and overwrite the current player state with it.

This could be implemented as "saveplayerstate" and "loadplayerstate" commands, giving the advantage of retaining the player state between engine sessions. 
Mankrip 
I like the cut of your gib. Sounds like an elegant way of doing it :} 
@Kinn 
I would use this as well. +1 
@Kinn - Noclipping To A Place 
Quakespasm has an setpos command to teleport you to a specific spot in the map, if I recall.

Type viewpos to get an x y z or you could type r_pos.

Those commands happen to work in Mark V. In Mark V, type viewpos and then typing setpos without the x, y, z will teleport where viewpos was last typed.

Short version: I think you can do what you want to do in Quakespasm already. 
Yeah, I Started Out Looking At That Actually. 
Turns out it didn't help too much because it's not really a case of me needing to teleport to the same specific area a lot, it's more to preserve the player's current arbitrary location and view during reloads when doing very rapid design iterations, where my location is jumping around all over the place.

The time it takes me to type r_pos, then note the coordinates, then type setpos X Y Z, means it's something you only want to do occasionally, and probably bind it to a key, which only really makes sense if you're spending a lot of time in that same area. But I zip around rapidly working here there and everywhere like a nutter.

If I just wanted to set up shortcuts to a bunch of fixed locations, it would be better to create a testing hub with teleporters to ten or twenty key areas in the map I reckon.

Without someone looking over my shoulder watching exactly how I work, I'm not sure if I'm really selling this to be honest :{ 
Hold Your Biscuits! 
Sorry I didn't read the critical bit here:

Those commands happen to work in Mark V. In Mark V, type viewpos and then typing setpos without the x, y, z will teleport where viewpos was last typed.

Ok, that's actually pretty useful. 
Custom Gfx Images 
Does the engine support custom images for the player HUD? It's for a mod. 
 
Is the issue with the Probe in Malice and engine side issue? Or something that could be fixed with QC? The probe won't move when activated in quakespasm.

Also wondering about the skin misalignment on the minigun mentioned earlier. 
Sorry I Forgot / Lost Track 
Can you link the post?

Skin misalignment: Not sure if it's this, but there is a half-texel offset in mdl skins in GLQuake relative to winquake, we discussed changing it to match WQ a few years ago but the consensus was to keep it as-is because there's a lot of content designed for the buggy GLQuake standard.

-- here's the current status on bugs in TC's I'm aware of:

1. the Xmen start map has a meditating guy telelporter, the teleport trigger is tiny due to setmodel() using a size based on the mdl rather than a fixed size like winquake. This was a change metl made in Fitzquake that I think he said was inadvertent. Not fixed - my feeling is we should revert to Winquake's behaviour, but there is a risk of breaking mods that were built for FQ's behaviour, so it may need a gameplay fix cvar to get the FQ behaviour back, which are a pain.

2. Malice (I think it was) has blue checkerboards on gibs, this was meant to highlight the mod being buggy since the skin number was invalid, but we changed it back to winquake behaviour and added a developer warning. 
 
Sorry, I don't know how to link to the original post in this thread. I'm pretty new here. Here's the original text though:

"Malice Issues
#3280 posted by [86.131.50.80] on 2018/02/25 19:40:30
why does the minigun skin in malice get messed up in both quakespasm and glquake?

also the probe wont fly about in quakespasm either... "

I know the minigun thing is some sort of vsync/resolution issue. I tried playing with setting and it would eventually work. But would have to set vsync on/off each time I start.

The probe won't move at all when fire key is pressed. I did find something about MarkV engine fixing this or making a work around.

http://quakeone.com/forum/quake-help/quake-clients/5863-proquake-4-43/page8 
 
@kinn - I'm glad that helped, ericw is free to copy the implementation if wants, obv. During testing I often need to go to the same point in a map frequently to examine an area doing engine stuff, obv.

@legend - Malice should play essentially perfectly in Mark V. NightFright really liked Malice and clubbed me over the head with Malice. If I recall, it is bounding box issue that FitzQuake simply has different behavior than WinQuake and the solution is something like sv_gameplay fix original Quake bounding boxes (I can't remember cvar name off hand but it sv_ something.) 
How To Invert Look On Quakespasm. 
Please help. All I want to do is invert the y axis for my ps4 controller. everything else works fine. Where is this default.cfg? I do not see it anywhere in my quake folder. I see dosbox_quake and dosbox_quake_single in the root directory. Where do I put joy_invert? 
 
@pfraktal:
Default.cfg should be in the main folder. If not, try in your ID1 folder. Also, try changing settings inside your config.cfg in the ID1 folder or inside the folder of which ever mod/mapset you are trying to run. 
 
You can open the console with the `/~ key and type "joy_invert 1". This is an archived cvar so it will be saved to id1/config.cfg. 
Please 
Restore the vanilla Quake startdemos functionality. 
-fitz Commandline Argument 
You might already know this, but you can get the functionality by adding the commandline argument -fitz when starting QS. 
 
That does muck with a few other minor things tho. 
 
Yup, one of the more noticeable ones is by default QS's tab-menu status bar has kills, secrets, and skill level, while -fitz reverts it to kills, secrets, and time elapsed. 
What are the other effects, exactly? 
-fitz 
Ooh what other scary effects are there? 
-fitz 
Going off memory here, because the readme only includes "o To disable some changes, use "quakespasm -fitz" which is less than helpful for finding exact changes:

-QS by default drops the player straight to the console screen with a new grey background, -fitz enables the old id background and demo reel (vanilla Quake behavior)
-Status bar info changed (mentioned previously)
--fitz re-enables the 'Press Y to quit' prompt, while QS will otherwise let you immediately exit. Note it's just a plain 'QuakeSpasm 0.9.whatever by <author list>' message even with -fitz enabled, not a full credits list with 'press Y to quit' all the way at the bottom like WinQuake, or the various Doom-style insulting quit messages ("Are you gonna quit this game just like everything else?") of DOS Quake.
-Possibly changes updated entities, although this one I'm not sure of; Quakespasm's own .pak file still includes .ent files for five maps, but I don't know what they change offhand and it's not listed in the readme. QS does include an external_ents cvar for loading of external entity files, but it's set to 1 by default with and without -fitz. I also thought one of the changed entities was E1M1 to get rid of the obvious Z-fighting on the lift for the quad secret (by moving the lift down slightly, as original Quake always drew world brushes in front of brush entities so there was no Z-fighting there), but that's not included so maybe I imagined it?

Also of note is that the console background is in the .pak where it should be, but the HUD layout itself (the time/skill switch up) is apparently hard-coded. 
Wierd. 
Who is the QS curator anyways? I get the impression it's a community effort. 
 
Judging by the source code, -fitz prevents loading of the whole quakespasm.pak, which includes alternative default keybinds, conback picture and ent files.

Speaking of features, it would be cool to refactor the menu in such a fashion that menu controls could be anything else than arrows. But damn, this looks like a lot of manual labor. What are the chances of breaking something important in case of menu controls altering, I wonder. 
So When I Deleted My Quakespasm.pak... 
I basically always run in -fitz mode? 
#3307 
No, because there are hard-coded behaviours in the engine that don't depend on content. 
 
Going through the source code, the exact and only differences -fitz applies are:

- Don't load the custom quakespasm.pak
- Run the normal demo loop (QS otherwise goes straight to the menus at startup).
- Pop up the Quit prompt (QS otherwise just quits immediately).
- Revert some changes to the solo scoreboard layout.

If you delete the quakespasm.pak you'll get the first of these; you will not get the others so you will not be always running in -fitz mode just by doing this.

It's also the case that future revisions of QS may add more.

Don't let this become one of those stupid items of "Quake lore" where the entire Quake community becomes religiously convinced of something that's actually flat-out wrong. 
 
startdemos is called by quake.rc. If QS has its own .pak to overwrite settings, it can ignore startdemos by simply omitting it from quake.rc. Does QS actually ignore startdemos in the engine itself? 
@mankrip 
Hardcoded in the engine 
 
Does QS actually ignore startdemos in the engine itself?
Yeah, QS disables the "startdemos" command, unless -fitz is used.

MarkV's approach seems better to me; it has an archived host_startdemos cvar default to 1, if you want to disable startdemos for all mods you can add "host_startdemos 0" to your id1/autoexec.cfg or launch with +host_startdemos 0. 
QS/Quoth Bugs 
Not sure if this is solely related to QuakeSpasm, due to it being the only port I use, but there are some bugs when playing Quoth, such as the Trinity/Reflection flashblends not getting cleared after loading a quicksave or the view offsets and roll being misaligned when quickloading during an earthquake effect until either restarting the engine or letting the effect play out in its entirety. Also, is it intentional that monsters aren't interpolated when they are on a moving platform, or is this not implemented yet? Last thing of note is that the "give a(rmor) x" command is bugged in QS and Mark V when playing with Dissolution of Eternity. The amount entered is properly set, but the armor icon doesn't update and for some reason it makes you able to fire lava nails without having the SNG. 
Buggy Mouse Look In 0.93.0 
I just downloaded 0.93.0 after using 0.92.1 for a while without any issues and my mouse is skipping around a lot. I'll be looking straight ahead when suddenly I'll do an instant 180 and be looking behind me. Sometimes I end up looking at the floor or any other random direction, and it often leads to blowing myself up when using an explosive weapon.

Apparently I seem to be the only person experiencing this but after doing two fresh installs, I can't seem to get rid of the problem. The only resolution is to continue using 0.92.1, but any help or suggestions would be appreciated. 
@Poorchop 
Do you experience this on both the SDL 2 and the SDL 1.2 .exe? 
#3314 
A Windows 10 update broke that. The SDL2 version should still work though. 
#3314 #3316 
@Poorchop
Funnily enough, I get the same mouse problems with Doom 64 EX, which also uses SDL 1.2, but not with Quakespasm SDL 1.2.

@Kinn
Sorry for getting off-topic, but ironically, regarding Doom 64 EX, there is a Windows 10 fix for the mouse issues, but I have Windows 7 and mouse issues anyway. The fix doesn't work for me either. 
 
Also, is it intentional that monsters aren't interpolated when they are on a moving platform, or is this not implemented yet?

This bug existed in Fitzquake as well, I never could figure out why.

Also falling scrags in demo1.dem seem to not interpolate their fall. 
 
Last thing of note is that the "give a(rmor) x" command is bugged in QS and Mark V when playing with Dissolution of Eternity. The amount entered is properly set, but the armor icon doesn't update and for some reason it makes you able to fire lava nails without having the SNG.

This command doesn't exist in the original Quake engine and the bug is inherited from FitzQuake. The Rogue/DoE mission pack uses different defines for armour, and the original defines are instead used for some weapons.

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.

Engines implementing a "give a" command should test for "if (rogue)" and use RIT_ARMOR1, RIT_ARMOR2 and RIT_ARMOR3 instead of IT_ARMOR1, IT_ARMOR2 and IT_ARMOR3. 
 
@Poorchop, which .exe did you experience the bug with in 0.93.0?

The naming convention changed so quakespasm.exe is SDL2.0. This one should be mouse bug-free because it uses raw input, and the other one - quakespasm-sdl12.exe (and all SDL1.2 apps) have known broken mouse input since the Windows 10 Fall creators update. 
 
I know we had a brief Q&A about this upthread, but it really does seem like something needs to be done with that SDL 1.2 version. If not getting rid of it entirely, then isolating/renaming it so that people only use it if they really need it (i.e. are playing on Win95). 
 
something needs to be done with that SDL 1.2 version. If not getting rid of it entirely, then isolating/renaming it so that people only use it if they really need it (i.e. are playing on Win95).

The bad thing about SDL-1.2 on Windows is that no one has backported the bug fix for Fall Creators Update (Win10 v1709) SetCursorPos() bug to it yet: someone should -- I tried myself but got lost in the mess and gave up.. Other than that it still works OK, and it's still good for systems where SDL2 is not available. 
@mh 
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. 
I Don't Mind The Idea Of Direct Bit Value 
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; @metlslime 
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. 
Scaling Up 
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. 
Music In Mark V 
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. 
Mark V Winquake FTW! 
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: 
@esrael 
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. 
Palette Wank Incoming... 
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. 
#3344 
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. 
Wrong Word Choice 
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. 
 
I am pretty sure that in Quakespasm (or GL Mark V) the gl_texture_anisotropy setting does affect even gl_nearest_mipmap_linear texturing in some way. Don't have the details handy though. 
 
GPUs uses the farthest vertex distance

That's not true.

With a GPU, mipmap level selection is (1) per fragment, NOT per vertex or per polygon, and (2) based on the screen space derivatives of each fragment.

For fixed pipeline hardware selection is described in the GL spec, e.g for GL 1.4 on page 145: https://www.khronos.org/registry/OpenGL/specs/gl/glspec14.pdf 
 
By "per fragment" you mean trilinear filtering?

I'm on mobile, can't easily search for the specific post where I saw the info.

(2) based on the screen space derivatives of each fragment.

Which means that for polygons that aren't parallel to the camera plane, the texels farther away from the camera gets smaller, so the texel on the vertex farthest away will determine which mipmap to use. That's how I understood it.

What I'm talking about is a comment about the differences between trilinear filtering, anisotropic filtering and why the walls on hardware-accelerated engines gets blurry when seen from an angle. I don't remember the exactly thread, but the comment was somewhat recent. 
 
Okay, here's the exact quotes:

winquake's mipmapping was based purely upon the distance (and texinfo+screensize+d_mipcap). 

on the other hand, opengl decides which mipmap to use based upon the rate of change of the texcoords - or in other words surfaces that slope away from the view are considered more 'distant' and thus get significantly worse mipmaps. 

glquake and winquake have _very_ different mipmapping rules, and glquake just looks blury in about every way possible...

Also Worth Adding...
#3143 posted by mh [137.191.242.106] on 2017/11/22 18:29:07
...that in hardware accelerated versions of Quake, mipmap level selection is not normally something that the programmer has control over; this is done by fixed function components in the graphics hardware.
 
 
The first quote is the #3140 posted by Spike [86.151.115.97] on 2017/11/22 17:55:03. 
 
No, forget about vertexes, they're not relevant. Likewise distances: Not relevant.

Per fragment is not trilinear.

In OpenGL a "fragment" is a collection of values used to produce a final output; please read https://www.khronos.org/opengl/wiki/Fragment for more info.

Texture coords (NOT texture lookups) are linearly interpolated between the per-vertex and per-fragment stages. Those interpolated coords are then used for mipmap level selection and texture lookup, which may have linear or nearest filtering applied.

In shader speak,

in vec2 texcoords;

Vec2 ddx = dFdx (texcoords);
Vec2 ddy = dFdy (texcoords);

Vec4 color = textureGrad (texcoords, ddx, ddy);

And that will give you the same result as the GPU's automatic miplevel selection.

The important message however is that miplevel selection in hardware is NOT per-vertex or per-Surface, because the fragment shader stage just doesn't have access to that info. It's per-fragment; per-pixel if that's easier (even if not 100% correct) terminology.

This is all public information; it shouldn't need to be explained. 
 
mh: Yes, I didn't try to learn exactly how it works, but it was enough to give an answer that despite being not technically correct, points to the right place where the cause is: the GPU mipmap selection algorithm. This way Poorchop knows that it's not a fault of the texture mode or screen scaling algorithm used by QuakeSpasm.

I was just trying to help so the guy won't waste his time messing around with every cvar trying to fix it. In this sense, my answer should give the proper results.

And yes, I recognize I'm way more dumb than I should be when it comes to hardware rendering, but it's not my field. There's no future for me in it. I only learn what I need to know about it from an user perspective. 
Render Gun In Lienar Or Nearest 
Problem Solve ! 
Yet Another Controller Question! 
Is there a way to designate a specific controller in QS?

I just got a lovely Hori Fighting Controller that I use for old d-pad based games and emulation.

Problem is that it's plugged in whereas my analogue controller is wireless. It seems that QS only reads the first controller recognised by Windows or something.

When I boot up QS it only responds to my plugged in controller and I can't find a way to get QS to read what has now become my 'second' controller.

PS: Just a FYI that the Nightlies page has a 502. :) 
 
At the moment it's hardcoded to use the "first controller in the list" returned by SDL.. agree this would be a good / easy thing to improve.

I don't know what would be a good way to store it in a cvar - just the controller index would work I guess, as long as the OS returns them in a consistent order across reboots.

re: Nightlies, thanks.. rebooted. 
 
Do you think that sometime in the future you'll create a menu for controller options? Maybe if players can easily change things in a menu it wouldn't be such an issue if they did have to occasionally change the CVAR.

Of course, I've really no idea how much work it is to add menu stuff in Quake... Just curious. :) 
Potential Code Snippet Donation 
in_sdl.c -> IN_StartupJoystick ...

Replace "for (i = 0; i < SDL_NumJoysticks(); i++) { ... }" block with following.

{
qboolean do_second = COM_CheckParm ("-controller2")
qboolean found_first = false;
for (i = 0; i < SDL_NumJoysticks(); i++)
{
const char *joyname = SDL_JoystickNameForIndex(i);
if ( SDL_IsGameController(i) )
{
const char *controllername = SDL_GameControllerNameForIndex(i);
gamecontroller = SDL_GameControllerOpen(i);
if (gamecontroller)
{
if (do_second && !found_first) {
found_first = true;
continue; // skip to the next one
}
Con_Printf("detected controller: %sn", controllername != NULL ? controllername : "NULL");

joy_active_instaceid = SDL_JoystickInstanceID(SDL_GameControllerGetJoystick(gamecontroller));
joy_active_controller = gamecontroller;
break;
}
else
{
Con_Warning("failed to open controller: %sn", controllername != NULL ? controllername : "NULL");
}
}
else
{
Con_Warning("joystick missing controller mappings: %sn", joyname != NULL ? joyname : "NULL" );
}
}
}


Hipnotic Rogue could just add -controller2 to the command line. 
... 
Someone in the QuakeDroid thread asked for controller support for Android ...

Was about to implement controller support from a SDL2 development blog, then realized if it didn't use the same key names, behaviors and such as Quakespasm would be a missed opportunity.

Short version is that I spent some time researching the differences between the initialization in Quakespasm vs. what I read on the SDL2 development blog, and ended up reading this section of code several times. 
 
Cool, I hope the QS controller code is useful. I'm biased but I really like how it turned out (pretty clean integration with the engine, playable out of the box, defaults went though a lot of player testing - i.e. cubic easing, the deadzone implementation.)

Here is the initial commit that shows the changes outside of in_sdl.c: (mostly just adding K_ABUTTON and K_BBUTTON to the menu code.)
https://sourceforge.net/p/quakespasm/code/1293/

I made some further tweaks which I think were restricted to in_sdl.c. Let me know if anything is unclear.

(Thanks for the -controller2 code snippet, that seems like a good starting point for multi contorller support) 
 
Should you have use for it, @insideqc I posted something for "Quakespasm Ticket #27" (Unix path) that isn't rocket science but perhaps will save you 5-10 minutes.

Go to sv_main.c line 1432 (SV_SpawnServer) and applying that to the sv.model_precache[1 + i] (modifying it) *should* in theory solve the problem for models.

Might need to hit pr_cmds.c PF_precache_sound and pr_cmds.c PF_precache_model. And sv_main.c @SV_StartSound and sv_main.c @SV_ModelIndex

Rough blue print.

/If you decide that is worth addressing at all. The counter-argument is that this falls at the doorstep of the mapper -- the mapper fixes the map and re-releases the map. There are myriads of ways a mapper can foobar a map, perhaps the right answer is "Not going to protect mapper from self". 
Thanks 
Yeah, it's a grey area. If winquake.exe and QS on Windows accept it, that's a good argument for accepting the backslashes on Unix OSes, but it should be a developer warning on all platforms (realistically most maps are only tested on Windows before release). 
 
If winquake.exe and QS on Windows accept it,
that's a good argument for accepting the backslashes
on Unix OSes,


I disagree, we shouldn't have to fix mapper screw-ups.

Not going to protect mapper from self

This is how I see it. 
 
Plus what about mixed case filenames -- say some guy does a upper case file name that happens to match a lower case on in a pak on accident and Windows ignores it ... but Linux should do what?

Trying to protect mappers from their own choices ultimately leads to choices with unexpected consequences.

/Anyway, just throwing out a thought. 
 
fair point, I guess this kind of compatibility hack also indirectly forces other engines to apply the same patch. A developer warning would be good though. 
Ericw 
I do want to implement this at some point!

Zomg, sorry I seem to have missed this post, but that is great news :D

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

I'd happily live without coloured lighting just for the true software look, although it's worth having a gander at how FTE does it, which somehow does the proper 8-bit palette look, but then it can still get tinted by coloured lighting afterwards, which neatly avoids the colours getting mangled. 
@ericw 
The way Quakespasm's SDL2 controller support works totally doesn't work on Android (at least not as of SDL2 2.0.8 - March 1 2018).

That being said, SDL2's controller support for Android appears to be better than in the past.

I think SDL2 used a "Steam/desktop computer mentality" to the controller support for Android, and then started to gravitate towards using the existing controller support already that is part of Android (which from accounts I have read, works outstandingly well).

I may yet get some sort of Android SDL2 controller support to work (I have 6 buttons working, no axis working, several buttons not working).

I think SDL2 has done a tremendous job on Android.

Now I think I understand why the SDL2 blog and your code were different.

Anyway, just wanted to provide some feedback to as to how that went. Should I get it to work, having your skeleton of cvars/deadzone stuff will have been very useful even despite SDL2 Android wiring differences. 
 
I've got a question about an issue that is suuuuper minor -- but I'm curious so I'll go ahead and post it.

When quitting the game, or when using the menu to start a new singleplayer game while you already have a game active, Quake will pop up an "are you sure" dialog that waits for you to press Y before continuing.

Something I've noticed when using Steam streaming with Quakespasm is that the dialog will be visible on the monitor of the PC that is running the game, but it won't be visible on the TV that the game is being streamed to (through Steam link). On the TV it looks as if the game has frozen up. But you can still of course press Y (or ESC) and things work as expected.

(I'm not sure if this happens with other Quake engines too.)

This is not anything I'm losing sleep over, but do you have any guesses off the top of your head why that dialog doesn't make it to the streamed display? 
 
might be drawn to the back buffer and then the buffers aren't getting swapped before the game stops to wait for input?

Does the same thing happen if you try to start a new game from the single player menu while a map is loaded? 
 
oh, reading a bit more closely... maybe the streaming to a TV doesn't update the most recent frame? It's one frame behind somehow? 
 
Nah, what is likely going on is that the screen is blocking in Quakespasm, like it was in FitzQuake and original Quake before it.

So anything that depends on a normal frame or normal event process isn't going to happen.

(A counter-example: in Mark V very recent builds, the dialog screen is not blocking -- you could stare that the dialog screen all day and, for instance, not disconnect from a server. It might be like that in FTE also, I wouldn't be surprised. I may have even got the idea from FTE and then forgot.) 
Although Actually ... If It Is One Frame Behind ... Here ... 
Although ...

If the issue is "one frame behind" ...

Quakespasm source ...

scr_drawdialog = true;
SCR_UpdateScreen (); <---- I don't draw twice!
scr_drawdialog = false;
...
do {
..
while }

If the stream expects double buffering, it isn't getting it in SCR_ModalMessage.

The test for a solution would be doubling it up ...

scr_drawdialog = true;
SCR_UpdateScreen ();
SCR_UpdateScreen (); // Double buffer it.
scr_drawdialog = false;

(My first reply was on gut instinct about the event queue/not having a normal frame ... because I've experienced a fair number of headaches before due the blocking dialog so I had the blocking dialed in as public nuisance.

But gut instincts aren't always right ...

and although I've run into instances of the blocking dialog not drawing specifically because it is blocking .... may not mean anything at all in this situation ...) 
 
not all systems even support explicit *SwapBuffer calls.
Eg, webgl takes away control of your main loop, redrawning only when your redraw function returns.
There's other systems that do the same sort of thing, including Android's GLSurfaceView or MacOS's cocoa api.

Plus there are drivers that violate the GL spec and force triple-buffering, so you're never sure how many swaps you actually need to make to ensure that its actually swapped.

As a result, its imho easier to just keep redrawing the screen regardless (which is required on many systems anyway, where the system doesn't repaint unless the app explicitly does so - like windows).
But its best to avoid modal things entirely. Sometimes you don't really have a choice though (like QC debugging).

Regarding video capture, the recording program probably set up some code injection that copies the backbuffer to a pbo (or a compute shader) before the swap. Such things generally check the response the frame after that, which avoids forcing the cpu to sync with the gpu. This requires a couple more swaps before the data is available to encode, which of course makes loading screens really messy.
Hurrah for threads!... 
GNU/GPLv2 Question 
Am I allowed to sell a mod on steam, using quakespasm engine ? I need some guidance with GNU/GPLv2. 
 
Here is an example of someone selling something on Steam using a Quake engine: https://store.steampowered.com/app/793670/The_Wastes/

Here is a mod on Steam for Half-Life: https://store.steampowered.com/app/225840/Sven_Coop/

The engine source code license agreement does not have much to do with any of this. 
 
As long as I give credits to quakespasm creators, and if the mod doesn't include quake materials (models, textures, sounds...) it's ok ? 
 
You should read this: https://partner.steamgames.com/steamdirect

But then also ask the question: are there people who are going to pay for a Quake map/mod in 2018?

Probably not. 
 
It's not about the engine, but the vibe (Thirty Flights of Loving, DUSK...)

Thank you for the link. 
 
In the mapping help thread, you asked about WAD3 (Half Life 1 texture format).

FTE is the engine used in the first link I gave you (to the best of my knowledge) and it supports the Half Life 1 map format, which is like basically Quake map format except for the texture format is different which is why J.A.C.K. can easily do both Quake and Half-Life 1 maps.

I mention that because you referenced something with tons of color, and it is basically impossible in Quake because of the color count restrictions. 
 
I stick with Quakespasm. Quake palette haven't much "blue" colors, right. I haven't yet looked into customizing palette.lmp

Do ya know PixaTool ? 
 
Is there any way to smooth out jerky monster movement while they ride platforms or elevators? 
Suggestion: Autocomplete On Load Game 
I tend to store a ton of savegames with crazy names. I really like how the "map" command has auto-complete on the mapname.

Might it be possible to do a similar autocomplete on the "load" command for the savegame names? 
 
just a brainfart, not terribly important of course 
QSS Frame-rate Fix? 
Are there plans to add Spike's frame-rate/physics fix to QS any time soon?

I'm just curious as I've found that it has fixed my issue with intermittent stuttering on my 144Hz monitor. :) 
Yes 
QS has been on the backburner for me, but when I get back to it that is something I want to add. 
Great Stuff! 
It's kinda surprising that Spike's 'little' breakthrough hasn't caused a bit more excitement. I suppose that's to be expected in such a small community. :) 
 
that and that anyone who actually cared already had a choice of other engines that already had fixes for it. 
 
I implemented compute shader water warp (one pass) in vkQuake. Feel free to steal it, can easily be translated to a fragment shader with a triangle over the texture. 
 
I have troubles running "Eargasm" mod for Quakespasm. It seems the engine doesn't accept the new wav files, at least some of them.
For instance :

guncock.wav is played in the engine, but it seems to be filtered/emulated in 11025hz/8bit.

buzz1.wav isn't played at all (I've checked with the command "snd_show 1", the engine doesn't play the sound at all).

I tried x86 and x64 Quakespasm.
I tried to re-encode the files using different wav format settings.

Latest Quakespasm update : 20th Nov 2017.
Eargasm was released on 16th Dec 2017.
Would it be possible to make an update ?

https://www.moddb.com/mods/quake-eargasm/downloads/quake-eargasm 
>moddb 
says it all. 
 
Suggestion: Add option to disable auto weapon switch on pickup 
Makr0n 
That's the realm of QuakeC, and not something that can be done in engine without the hideousest of hacklets. 
#3395 
Not sure if this helps but all non-music sounds must be mono in Quakespasm. Maybe there are some stereo files in that pack designed for use with other less compatible Quake engines. 
Really? 
That explains why some of my sounds from a few mods fail in game. 
@qmaster 
As far as my tests this is the case with QS. I don't have a PC at work today so I can't confirm. But as I see in the DP docs stereo support is mentioned. "Stereo sound file support (useful for cd tracks)" I'm assuming that this was added, some mods were created with stereo files that break compatibility with Fitz variants. Which mods are messed up? I'd like to pursue this further and if you want I can mix the tracks down to mono for you. 
@qmaster 
I read a bit further in the docs and I am right -- DP added stereo sound playback for mods. 
 
stuff like this is why I made QSS convert stereo to mono on load.

also, change sndspeed to anything other than 11025 and that will disable quakespasm's low-quality filter. 
I'll Have To Check 
To save myself the headache of changing precache file paths in the qc when merging in from mods, I kept the files in the same folders.

This had the drawbacks of not being able to tell which files came from which mods as well has name conflicts.

So...might be a while before I can tidy up and get a comprehensive list to find those again. 
@qmaster 
Don't sweat it. I can peruse the files and check on my end if they are included in keep. 
Quakespasm 0.93.1 Released 
What About A Spike Version, For OS X? 
And what about that old quakespasm.pak that have date 1 march 2016, while the newest version (?) is 27 june 2017? 
PNG Screenshot File Sizes 
It seems like the PNG screenshots that QS writes are larger than they have to be? If I resave them in Paint or Paint.NET the file size is halved with no apparent difference in quality.

Also, I would greatly appreciate an option to disable the "wrote xxx.png" message. 
 
Also, I would greatly appreciate an option to disable the "wrote xxx.png" message.

And why does that bother you? 
 
speaking for myself:

When taking multiple screen shots in a row to perhaps catch a monster in a specific position, for example, you have to wait for that message to go away or to use host_timescale to slow down monsters.

When I have r_drawviewmodel 0 and crosshair 0 for screenshots, itd be nice to have some sort of way to avoid all on screen prompts and such. 
Freezeall 
You can freeze monsters at will. Mark V has the freezeall command and other engines have sv_freezenonclients 1 
 
The large PNG's are intentional to try to limit hitching. They're compressed in the main thread of the engine, and default settings of png libraries I tried caused unacceptably long freezes in the game (like 0.5 seconds - 1 second depending on the resolution.)

If we moved the PNG compression to a background thread, we could use good but slow compression settings - this is just more work to set up.

Agree with a cvar for hiding the "wrote" message. 
#3409 
Sometimes I like to take multiple shots at once, but then the best "takes" have the message printed on them which isn't too good aesthetically. 
 
There is a cvar called "con_notifytime" or similar which controls how long the console text appears at top of screen. Try setting it to zero, maybe even make a alias that sets it to zero before your screenshot and then back to default after? 
 
Thanks, metl. That works. Doesnt show on screen but still shows in the console so one can confirm screenshots have been taken. 
@otp 
What mukor said. I've never seen a screenshot with the message showing. Maybe an older version of QS? 
 
Screenshots And Messages 
One way of handling this is, rather than taking the screenshot immediately, just flag an "scr_screenshot" qboolean to true, then run SCR_UpdateScreen and if scr_screenshot is true selectively suppress certain UI elements. Finally glReadPixels and capture the screen. 
@3417 
 
yes, taking one screenshot wont display the message in the screenshot.

spam the screenshot key and youll get the message in the screenshot.

some people implement real world photography concepts into screenshots and one of those concepts is to take a quick series of images to then pull the best one from.

Think of skateboarding where they use shutter speeds to capture the whole trick then pick one of the pictures to use on the cover. 
 
heres a GIF with this in action:

https://i.imgur.com/Xe2Jd1U.gifv 
Here Is Another One 
 
Uuuhhhh 
are these last few posts just one big troll?

you know the "clear" command is a thing yeah? clears the console?

bind F12 "screenshot;clear"

does what you want I think? 
 
metlslimes suggestion of "con_notifytime" is better than using clear, imo. 
Sorry For The Tone 
reading that back again sounds a bit patronising, but I think it's a valid solution for now.

Maybe the fact it clears the console history doesn't make it a perfect solution. 
Con_notifytime 
lol, I skimmed past that.

Yeah that's even better. 
Lol 
yeah, i changed the binding now too.
no trolling intended. 
And Btw 
that rrp gif is 5 yrs old now, i just remembered making it was such a chore not knowing how to disable the message. 
 
It would be neat if QS allowed for changing the actual layout and functionality of the hud. I think stuff like that would be very cool esp for big mods like AD. 
Huddage 
That requires support for CSQC hud code - I think QSS has this supported, but I haven't had time to check it out yet. 
 
I always get warnings when I try to get QSS. 
You Mean 
the website? It's fine FYI.

http://triptohell.info/moodles/qss/ 
Because Spike Injected A Packet Sniffer!! 
j/k i get the same warnings, idk what windows doesn't like about qss, it is annoying. 
 
 
Yeah, getting a virus warning from that. From the zip as well. Wonder why that is exactly. I reckon it is some funky code which gets picked up by heuristics? 
I Was Wondering 
How hard would it be to get temporal dithering, similar to that of Inside, into a quake engine?

The banding that the fog generates, esp in dark areas is pretty harsh. With good temporal dithering, that is limited to the fogged areas, things would look a lot nicer. Obvs this is not important as it is not a gameplay thing at all, but it would be neat. 
 
Also, thanks Kinn for the hud linkage :) 
Cool Idea 
The main roadblock for Quakespasm is the renderer is not fully converted to shaders; mdl and lightmapped faces are, but water, sprites, sky and anything else are still using fixed-function OpenGL.

Dumping some links on dithering I found:
http://loopit.dk/banding_in_games.pdf
https://www.shadertoy.com/view/MslGR8 
 
Ah, I see.

Here's a good talk about what they did in Inside here.

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

I also think they gave away the plugin, or whatever they wrote for Unity to do this stuff for free. Not that that would help a lot with QS. 
Isn't Fixed Opengl Faster Though? 
 
 
On any hardware from the past 15 or so years, fixed function OpenGL no longer exists: it's emulated with shaders in the driver.

Maybe "fixed function is faster" was true in the GeForce FX era, but time and technology have both seriously moved on since then. 
Classic Settings And Weapon View 
Aside from being unable to get an accurate weapon view like winquake/mark_v I think the features here are almost perfect.

r_scale, cl_sidespeed etc fix any minor gripes I've had.

Any ideas if this will be fixed outside of scr_ofsz -2 would be good. 
@Fifth 
What about r_viewmodel_quake regarding the weapon position. Setting that to 1 does the job pretty good I think.

I personally really would like the oldschool underwater effect in QS, but yeah, shaders, etc.

That and a way to actually have accurate colormap lighting rendition, because a lot of older levels do look a lot better with the harsher lighting, imo at least. 
@Fifth 
Yep r_viewmodel_quake should do the trick.

btw check out the >60Hz monitor support in QSS if you haven't http://triptohell.info/moodles/qss/ - host_maxfps 0 means unlimited, and it keeps physics running at 72fps.

btw thanks for that video ptoing, when I get back into engine coding I'd like to do more with shaders, and the temporal dithering sounds like a cool project. 
1 post not shown on this page because it was spam
First | Previous | Next | Last
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.