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.
First | Previous | Next | Last
New Builds (0.85.10-r980) 
New prerelease builds uploaded at




Linux users can checkout the svn and build for themselves.

Changes since the previous r958 test builds from Aug. 08 include:
FSAA support, fence textures support, brush model drawing speedup,
better cross-map demo playback support, and increased limits for
MAX_ENT_LEAFS (32), MAX_EFRAGS (4096) and MAX_CHANNELS (1024).
For more detailed list of changes see the READE file (or browse the
svn history.) 
Orl's test map is playable now :). Nice one.

Any likely/possible regressions with the new brush model code ? 
I tried the OS X version, and I don't see any FSAA option.
Where is it ? 
Nice, Thanks 
Though what bothers me a little is that the readmes are called README.* instead of quakespasm.* - with all the stuff in my Quake dir, I prefer it all easily recognizable (without having to rename the files with every new version I install). </Spirit> 

You shouldn't have to read a manual for a graphical option . It needs to be shown with any other graphical option in the interface.

This is nonsense ! 
I support negke's cause at least for "extract and go" packages. All files should have unique names.</honk> 
Lava And Teleport Alpha ? 
Is there any lava and teleport field alpha parameters now ? I don't see anything related to these, in the readme. 
If there were, they would be documented in the readme. 
Fantastic Job 
My hats off to you Quakespasm team. My map now runs at a constant 60 frames per second or higher, never dropping below that. It even runs well on my laptop with much weaker hardware. Great job guys! 
Thanks for putting up the builds szo.

Orl, glad I could help. :-) Your map looks wicked!

There are still a couple more optimizations I want to look at some time, namely using vertex arrays for world/bmodels and alias models.

Barnak, I tried to put fsaa in the menu but it requires a cascade of deeper changes in the engine that need a lot of care to get right. You can just set vid_fsaa in the console and it'll get written to your config.cfg, and used on all subsequent launches. 
Thanks for the info.

Now, what's up with a separate alpha for water, lava and teleporters ? 
Rome wasnt build in a day.

@szo, ericw, steven you rock! Thanks guys! 
Sndspeed Issue In QS-0.85.10-r980 Win X64 
- If you change 'sndspeed' in the console, the value is not saved in the config.cfg.

- If you manually add 'sndspeed' to the config.cfg (I was adding 'sndspeed "44100"'), the engine uses the new value, bit it disappears from the config.cfg after closing the engine. 
AFAIK sndspeed wasn't automatically saved in 0.85.9 either. config.cfg is just for things the engine saves itself, you should put that a custom sndspeed setting autoexec.cfg.

I know it's confusing. i don't know if it's documented anywhere other than the source code which cvars are saved in config.cfg or not!

Also just a note, the meaning of sndspeed was changed slightly in this release. QS now opens the OS audio device at 44100hz by default, and internally upsamples the sfx to 44100.

If you were setting sndspeed 44100 for better quality with replacement sounds, keep doing that and it will work as it was before.

If you were setting it to 44100 to hear the music at full quality, there's no need to do that any more, the music will be output at 44100Hz even if sndspeed is at the default of 11025. 
Speaking of which: section 3.1 in the Readme needs to be modified a bit now, and 6.1 could be clearer about how music is affected (or isn't). 
Good Catch, Will Update That 

(Especially the fence texture support) 
Expect To Be Seeing That In A Map 
Sometime soon :) 
Thanks Baker! 
I pretty much just nabbed it from Mark V :) 
No Locs, Timer Is Tiny 
Hi guys for multiplayer play, I have some issues.

1) There is no .loc support, which makes the engine unusable for DM :(
2) The timer in the bottom right is very small, there's no way to scale it other than to also make the HUD big. Can we have some sort of command to scale the timer? Thanks! 
C&P From 

Baker says:

Unfortunately there are 2 standards for loc files:

1. The Quakeworld way (ezQuake, FTEQW, ZQuake, DarkPlaces)
2. The ProQuake way (ProQuake, Qrack, DarkPlaces)

There are about 160 loc files for Quakeworld, about 120 for the "ProQuake way".

The ProQuake way is harder to make, but far more accurate about your actual location (a series of 3d "boxes" defines where you are), the Quakeworld way is easier to make (a series of points, closest point matches).

Personally, I'd opt for the Quakeworld way as a priority because it is easier to get the Quakeworld community to play a custom map (the NQ community is more set on long-time favorite maps).

draw your own conclusions.. 
how about supporting both? or are the file formats hard to distinguish when parsing them? 
I dont have a clue actually:)

Here�s the link to the forumthread: 
FTE does both, so its definitely possible.
different number of tokens per line or something.
although the box vs sphere thing does require special handling. 
on the other hand, you can't install two different dm1.loc files in the same directory, so players will have to choose just one.

second, if one format is supported mostly by netquake engines, and quakespasm is a netquake engine, does it make more sense to support that one format? You'll be playing with teammates who are also using a netquake engine and therefore the "proquake" style .loc files. 
Loc Differences 
ProQuake locs are boxes. Quakeworld locs are points.

Quakeworld locs often give a wrong location because they don't know "what room you are in".

For example, let's say you are outside DM3 in the pent area, but standing near the wall close to the rocket launcher area --- if you go by point, you are probably nearer the rocket launcher. But not in that "room".

DarkPlaces supports both formats, although in the past LordHavoc stated once that he had a preference for the ProQuake version because it was more accurate.

/Mark V supports ProQuake .locs 
For completeness: ProQuake locs link:

I imagine the Quakeworld .locs pretty much come with ezQuake. 
Is there actually any benefit in using the 64 bit version? 
Sorry For The Doublepost 
Is there a way to get around display glitches like these? Or is it just imprecision in the construction? 
Display Glitches 
ptoing, do these happen with gl_zfix set to 0 as well? 
Just checked, it was set to 1. Setting to 0 fixes this issue. Thanks :) 
Thanks for confirming that. gl_zfix activates a workaround for the z-fighting (flickering textures) seen in some of the original id1 maps. It can however cause (minor) glitches such as these, so while having it default to "1" may best for the id1 maps, this is probably not true for custom maps... I'll discuss with the others. 
Yeah, I think I never noticed any of those flickers in the original id maps. But I distinctly remember finding some secrets in custom maps when it was set to 1. 
Try going to the quad secret elevator in e1m1 with gl_zfix turned off for a nice example of z-fighting (look at the elevator while it's still "in the floor" and look around a little). 
Oh yeah, I noticed that in Fitzquake. I guess that does not have the zfix thing? or maybe it is not on by default. 
Other Issues With Multiplayer 

I have further issues with the QuakeSpasm OSX client and just cannot use it for multiplayer. I am now using GLProquake OSX which has sound issues but I'd rather have problems with sound than the sum of the issues I've outlined below with the QuakeSpasm client. For informational purposes, I'm on the latest Retina MacBook Pro and also Thunderbolt Display.

1) There is a great deal of negative acceleration at the bottom and top of the screen. This makes RJing impossible. If you bring your crosshair all the way down to your feet to make a rocket jump, your crosshair will spazz out and throw your aim all over the place. Without RJing, multiplayer is severely limited.

2) The timer is inaccurate. The timer doesn't start at 0:00 if someone starts a CRMOD match. It ticks up from wherever the map started. So essentially it's like not having a timer. If someone pauses the match, the timer also keeps ticking. The timer needs to be fixed for clan ring / match play.

3) The teamscores in the HUD are not added up. Therefore, there's no way of knowing how far up your team is in the game without manually stopping the game to do math. This is important because in a DM game, sometimes with 2 minutes barely up you want to hide. Generally speaking,all clients have had these teamscores added for a while, they should be there?

4) LOC support missing.

I really think if all of this were addressed that this would be the best OSX client but even the negative acceleration is too big of a problem to ignore. 
Thanks for the issue reports.

Does negative acceleration happen with ioquake3? Specifically their prebuilt binaries from (over 5 years old fwiw) use SDL1.2 like QS and the mouse handling code at first glance is basically identical to Quakespasm's.

Searching for "negative acceleration" a bit, the typical cause seems to be systems where the mouse cursor is centered in the window at the start of each frame, but if it moves fast enough to hit the edge of the window it just stops. If that's the cause of ours, there may be nothing we can do but see if they fixed it in SDL2 and bug the sdl devs about it.

Also if you could post a demo of what the spazz out when rocketjumping looks like, that would be sweet! 
Neg Acc 
Try playing with higher display resolution. If this helps, we are at least finding the cause of the problem.
And you know what? It is limited to the resolution:
for 320x200 it is [-160;159], for 800x600 it is [-400;399]
and so forth... So, if the mouse responsiveness (dpi) is high,
like logitech g5/g9, the game becomes unplayable,
unless you set hi-res, like 1600x1200+...
Bug appears when mouse cursor coords try to go over "screen limit" -
movement is just trimmed.
Being able to execute mods from within the engine is pretty cool. But I wondered if there is a way to also change the -hipnotic and -rogue switches from within the game, and perhaps also have another one to switch back to default id hud layout. 
Yeah, those could probably be cvars 
Mark V has a such a feature.

typing: "game warp -quoth" in console.
or "game metmon -quoth" etc. 
Add: a vanilla implementation is pretty easy to implement. In Mark V, I paired it up with the "game" command because the existence of "-hipnotic" or "-quoth" or "-roque" affects what pak files to load. 
Would be a great feature to have in QS as well :) 
The mark v implementation sounds like a good way to go 
Fitz 1.0. 
I've wondered when next FitzQuake will come out too. 
FTE auto-detects the available elements in the gfx.wad file, and decides which hud to use based upon that. thus -hipnotic and -rogue arguments don't affect the hud by themselves. 
Spike man, it would be AWESOME if you nominated a version of FTE for a stable release, documented all of its current magical powers, and put it up on a webpage for the world to see. 
Just tried to load a quoth map, and there it did not work. fteqw.exe is what I used, latest SVN trunk. Didn't load the proper HUD with the Plasma. 
Is there a way to get around display glitches like these?
Yes, i've seen these glows before.
How prevalent are they. Are there any other zfix associated anoms ? 
I think that is it. It's either get weird z-fighting when you get levels which have overlapping faces or get those little glitter pixels instead. Though it really should not be hard to make levels in such a way that there will not be z-fighting and I think most modern maps avoid this so gl_zfix can be 0. 
should be fixed in revision 4744

@Johnny Law
you want it on a web page? Oh the horror!

regarding anti-z-fighting hacks, I can't help but think maybe we should have some special flag in the map/worldspawn to disable it.
alternatively maybe just enable it for id maps where its a problem and expect everyone else to fix it properly.
MH was against it too, and it can't easily be done in gles either. Mappers depending upon it without realising it is a bad thing. 
Z-fighting "fixes" aren't consistent. On one video card everything will look great.

On another video, the same fix will show every secret door or make the problem worse.

The cure is worse than the disease.

External .ent files to touch up the id1 maps would be the right thing to do. All you have to do is move a few entities 2 pixels down or 2 pixels to the left and problem solved. 
Cheers Baker Man 
Anyone know where to find the relevant .ent files for id1 ? Rogue and Hipnotic affected ?? 
Well, Here's To Evil 
Not that I know of and I would imagine no such thing exists at the moment.

However, if you load up Mark V, go to the terrible z-fighting area on E1M1 with the Quad.

You will notice there is NONE! Yet Mark V isn't using any anti-zfighting in the rendering.

Because Mark V moves that brush down 2 pixels as an internal hack. You cannot visually tell anything changed (and I'm one to notice anything like that because I want it to look precisely right).

If you want to see something funny, start a maxplayers = 2 game on Mark V and connect with Quakespasm, making sure Quakespasm Z-fighting fixes off. Then go to E1M1 Quad. No z-fighting!

(Because what I did was the equivalent of using an .ent file, which takes effect server-side. I did the same for E1M2 exit doors.) 
Hi Baker 
I've got two questions regarding this:
1. Why two pixels? One seems sufficient in my test setup, but maybe that's hardware dependent?
2. How did you find out what entities to change? Which tools did you use? 
One More 
3. What is the "lip" line for in Mark V? Adding an "origin" alone seems to be enough in my tests so far. 
Mark V's tool_inspector, just type that in the console. Switch between weapon 1 thru 8 to see different entity information. One of them shows the server edict #, then "type edict 79" or edict 151 or whatever the edict # is, into the console

In Mark V, to export the world entities from map load, type "copy ents" in the console and the whole entities from the map are on the clipboard.

re: the 2 pixels

I can't recall exactly, but I did testing on a few different graphics cards. Changing the origin won't work, the lift will be too high or too low in the raised position.

re: "lip"

That in related to mapping and entity properties for func_plat/func_door:

func_door (almost the same as func_plat) 
Try this .ent file in Quakespasm

You see the E1M1 z-fighting go away without any rendering attempt to make it happen.

Unfortunately, E1M2 has 1 or 2 instances (exit door). E1M3 has at least one (box of rockets in "sewers". Probably several other instances.

And that's just id1 
Thanks for those links. With this info (and some testing) it turns out that the e1m1 case can be fixed by just adding a "lip" line (since the "door" starts in the open position).

Lip 8 is the default and hence shows z-fighting, lip 9 has the door start slightly above the ground, lip 7 has it start far enough underground to stop z-fighting (for me). Changing lip has no effect on the closed (raised) position of the door. (This can be verified by adding for instance a lip -1000 line, the door will then start so far underground that it will take several seconds to rise through the floor; it will still raise precisely to its normal position though.)

Which makes me wonder why you are including an origin change as well? It doesn't seem needed, and will in fact change (although just slightly) the level to which the door raises. 
Things like that shouldn't be fixed with internal hacks, in my view.

As for .ent fixes, here's a tip: in cases where a regular door would cause z-fighting in its open position, you can change the angle ever so slightly so that it moves diagonally 1-2 units behind the wall rather than on the same plane. That's a much better (albeit more complicated) solution than changing the door's origin. For a lift, lip should do, yes. 
Why is changing the angle better than changing the origin? Because that leaves the door in exactly the same position when closed? Or is there another reason? 
Yes, that's the reason. Imagine a secret door that's part of a wall - if it was indented from the get go, you would be able to spot it right away. Or maybe at times it's desirable to have a door align neatly to adjacent walls to avoid clipping. Slightly changing the way the door moves has the least impact on the original design. 
...doesn't use "lip", apparently. Does anyone know a nicer way to make them disappear far enough into the wall to avoid z-fighting than by setting "t_length" manually? 
Make them shrink along the axis of movement by a tiny tiny degree? 
Misc/homedir_0.patch is broken in current SVN.

patching file Quake/sys_sdl_unix.c
Hunk #2 succeeded at 31 with fuzz 1.
Hunk #3 succeeded at 152 (offset 4 lines).
patching file Quake/common.c
Hunk #2 FAILED at 1928.
Hunk #3 succeeded at 1937 (offset -7 lines).
Hunk #4 FAILED at 1965.
2 out of 4 hunks FAILED -- saving rejects to file Quake/common.c.rej
Negative Accel 
I am on 2560x resolution with the negative accel issue, so it's not resolution dependent for me. 
Omi, any improvement if you try this build that uses SDL2?:

I play QS mostly on a mac with retina display too, and don't notice any negative acceleration; e.g. I have no trouble rocketjumping, quick mouse movements feel fine, but I'm not a great player so I could be missing it, or else it's not happening on my setup but is on yours for some reason.

Also - do you get the problem in both windowed and fullscreen? 
Re: Z-fighting 
svdijk has been working on this... it looks like we're going to disable the z-fighting hack (gl_zfix cvar) that was applied by default to all brush models in previous QS versions, and which caused visual glitches like the one ptoing posted earlier, and instead ship replacement .ent files with quakespasm (maybe packaged in quakespasm.pak) for some of the id1 maps with the most egregious z-fighting, like e1m1. 
Honedir, Sdl2 
Misc/homedir_0.patch is broken in current SVN.

It applies ok (with fuzz) for me (rev 993).
Check your common.c with "svn diff common.c" ???

Thanks for inlining your SDL2 stuff eric. :) 
Hm, PEBKAC, works fine today.

Great idea with the .ent files, I think that is the best solution. 
Sorry ... it probably was busted.
I'll try to do some doco and patch updates tomorrow.

Re .ent files - Yeah , thanks Sander for that.

I'd never had a problem with gl_zfix, but obviously some people do. 
I think .ent files shouldn't be done to 'fix' this. I can't see it working on demos for example. It's pure shooting-fish-in-a-barrel.

Instead, I think a new format (.off?) should be created just to add polygonal offset origins or angles to map entities and this would only apply visually in the renderer, rather than server. Probably could start off the same as ent files, just parsed separately, disregarding other entity keys the renderer shouldn't care about. 
Pure shooting-fish-in-a-barrel? I think you are misunderstanding that analogy, unless you mean that using .ent files to do this is super trivial. And if that is the case, why wouldn't you do it that way. :P

A special format for doing this might be warranted though, but I will leave the coder folk to that. 
If i were fixing it, i would do it as narrowly targeted as possible to the actual problem:

1. do it all in the engine
2. do it on the client (it is only a rendering problem)
3. detect the specifc combination of map (name + CRC), model, and origin that causes the problem. (i.e. this would only take effect when the model is in the open state, if that is when the problem occurs.)
4. apply a specific offset to correct the problem. (add '0 0 -0.5' to the position for example)

The engine would have a table of such fixes, one for each known map that has this problem.

Those fixes would work in demos, they would work as a client in a MP game, they would not affect gameplay at all, and they would never have false positives against other maps that have the same filename, and they wouldn't prevent players from using their own .ent files for other purposes (like replacing all the monsters.) 
Yeah, That Does Sound Optimal 
and more targeted than the .ent files. maybe we could migrate to that at some point, using the data from the .ent files as a guide 
I think there may be cases where a secret door slides sideways first, and z-fights the entire time it's sliding. This is different from the e1m1 platform that only zfights in one position. So there may be cases where you need to apply the fix for all but the initial position of the entity. 
Re: Followup 
Yes, that applies to at least two of the most obvious examples, the exit doors in e1m2 and the bars before the exit doors in e2m7.

I agree with most of your points, especially since not all cases can be fixed with ent files, at least not without noticeable side effects. For instance in e1m3 one of the sliding plates in the floor in front of the wall that shoots the big spike causes z-fighting with the floor in the adjacent room when opened; since func_doors can't move down "a little" (their direction is either vertical or horizontal), I don't see how this could be fixed without changing eithers its origin (not wanted) or its class (also not wanted).

There's one point that you mentioned that I don't agree with though, the first one, to do it all in the engine. These are content errors, and fixes for them hence also belong content side, not engine side. Support for some kind of external "renderfix" files would be needed IMO.

Anyway, at least for the moment I think external ents suffice, since they improve two things compared to the last formal release: they avoid the glitches gl_zfix gave, and the move the fix to the content side. 
.png Screenshots 
.tga screenshots are cruel and unusual punishment to an average user.

First, they can't share them on the internet easily.

Second, to even *view* their own screenshots on Windows they will need a special graphics because nothing that comes with Windows supports .tga.

The next Mark V uses only .png for screenshots.

I happen to be using since it doesn't require .dll/.so dependencies. 
Another Thought 
You might also consider applying the current level of gamma to the screenshots so the screenshots actually look like what the user sees on the screen.

[If you aren't, I haven't checked in Quakespasm lately ...] 
Omi's Negative Acceleration 
Might be solved with

cl_minpitch "-70"
cl_maxpitch "79.49"

The pitch bounds in original Quake are -70 to 80. Some servers reject pitch angles out of this range and bound them to the -70 to 80 range.

[FitzQuake 0.85 rounds angles to the next integer, even *after* the pitch bounds checking. Then the angles are converted to bytes (protocol 15) or a short (protocol 666), which may adjust the angle even further in the conversion process. So the 79.49 is to prevent it from being rounded up to 80, which can get converted to 80.0024 which result in some negative acceleration.] 
There's one point that you mentioned that I don't agree with though, the first one, to do it all in the engine. These are content errors, and fixes for them hence also belong content side, not engine side. Support for some kind of external "renderfix" files would be needed IMO.

Yes, thanks. This is what I have been thinking during that whole discussion. Sometimes you engine coders creep me out with your suggestions for fixes. A problem in the progs or a map does not ever belong in the engine. These are hacks!
If a problem lies in one of the ID maps, then it should be fixed in the .map, recompiled and an unofficial patch made. When people complain about bugs in stock maps, the patch can then be pointed to that will work on all engines. 
The z-fighting in the original levels in some places (E2M3 is one example) is too severe to ever be "fixed" without making material alterations to the map.

There are many platform entities that occupy the same location as the world model.

The only "true" solution would be an advanced rendering engine that clipped entities the way WinQuake does.

No amount of .ent files or even recompiling maps is going to stop that z-fighting.

Case in point, you have a platform that extends out which is situated exactly where a world brush is: you can't move the platform down; you can't move the world model brush.

If you do, it won't look the same.

WinQuake clips those. 
I feel like replacement content to fix bugs is an extra burden on the user. Maybe if there was a common, easily accessible pak file with everything fix in it (that everyone agrees on) for people to install, it might not be that bad. Otherwise, it's all theoretical. These bugs could have been fixed with a replacement pak file 15 years ago when glquake came out, does that pak file exist? And how many of you (non-newbie, power users) have it installed?

The reason I am okay with engine hacks to fix stuff like this is that the content wasn't broken when it was released (it worked fine in the engine that shipped with the levels) and it's only more recent engines that can't render it as intended. Also because i like things to be easy for the user and these hacks are completely transparent to them (or at least, they should be.) 
Another Way Of Putting It 
Technology available back in 1996 inside the original DOS Quake.exe --- can solve all z-fighting. 
metslime nailed it. 
I had actually forgotten dosquake didn't z fight... so the problem is that the renderer is different between software and opengl. Is it then not possible to just give precedence to bmodels? That would serve to emulate the original behaviour.
I just started to raise my eyebrows at the talk of detecting the map being played, the entity with the problem... it's just crazy.
I mean, you couldn't even say 'I will displace all entities up 0.5 units', because sometimes there's z-fighting on the walls or the ceiling. 
Is there a solution where you could draw the world, then change the depth test bias, and then draw the entities? I have NO idea how the engine works so apologies if that is super basic and already dismissed ... 
Seems A Bit Pointless 
Patching content over fifteen years old. How far do you go? Fix the texture misalignments as well? That will mean new brushwork and expanding on the texture sets.

The best way would be to organise some sort of community project to rebuild all the maps, maybe adding some new content like enemies and so on.

Has anyone tried that before? 
the engine guys want fixes in the engine and the level guys want to rebuild the levels 
What Would Jesus Do? 
the engine guys want fixes for the levels in the engine and the level guys want to rebuild the levels 
The funny thing is, IMO anyway, Fitzquake's rendering has been the benchmark for a lot longer than software quake. So even if we had a perfect OpenGL clone of whatever winquake does, I would argue there's not much point.

The gl_zfix hack that was enabled by default in QS was pretty decent, besides showing outlines of secret doors sometimes, and one of the results was Scampie put Z-fighting in one of his jam maps because he didn't see it when testing in QS :-/ 
I'd also be fine with not fixing these bugs at all. Either way the solution (or absence of a solution) should not break newer content that was authored correctly. 
VBO Version Revision 
Intel ATI Mobility:

Arwop: Roman1 --> +2 fps (18 -->20)
id1: start --> (-10 fps?) (172-->162) ??? 
Thx For Trying That Baker 
Would you mind trying the roman1 demo again with "gl_fullbrights 0" and "r_drawentities 0"? That should cut off all drawing that's not using the vbo - I just use it on the lightmap + texture pass for world + brush models - and maybe show more clearly if there's any benefit to the vbo.

I'm not sure about why id1 start got slower. I am using unsigned int indices which is sometimes not recommended. 
I didn't do a timedemo, btw. On both maps, I just stood still at the start for about 20 seconds.

On roman1, doing gl_fullbrights 0 has no fps change (still 19-20 fps).

r_drawentities 0 it goes up to 53 fps. (Older Quakespasm, gets 46 fps with that ... so this is a +7 fps gain) 
Weapon Model Position 
Yo, I am just reposting this comment from my youtube here as I don't know the answer to his questions :

"quakespasm best quake engine that I know of overall, but it still has some glaring flaws in my opinion. The biggest issue for me is the way it handles- or rather doesn't handle- weapon models.

In quake, just like in doom, weapon models were placed in the center of the screen intentionally to be used as aiming sights. This mechanic, for me at least, is a crucial tenant of the classic doom and quake experience, and it goes completely out the window in quakespasm, as the engine doesn't compensate for the absence of a status bar and draws a microscopic weapon model at the bottom of the screen, about two miles from the center of the screen. The only way to compensate for this is to jack the field of view way up to say 130, which brings the weapon up to where it should be, but seems to stretch it vertically, and of course comes with all the issues that come with a grotesquely large field of view.

If anyone has an idea for fixing this within quakespasm, let me know.&#65279;" 
I posted a question about this general thing on I3D a while back; there's some discussion about the issue in the thread:

...but as far as solutions for a player to change things, I don't think so. 
They might like using Fitzquake Mark V with r_viewmodelhackpos = 1? 
A Workaround 
You can use the "scr_ofsx" console command to move the weapon model further into view of the player. By default it is set to 0. A positive value draws the weapon in closer, and a negative value pushes it out further.

I personally use -4 as my value, but give different numbers a try and see which one suits you best. 
I will post this to them, thanks. 
sometimes I feel it's too low on the screen when playing with the statusbar partially transparent. It could be nice to have an option where the gun position doesn't move down when you make the statusbar transparent.

Thx for the link Johnny. 
it might look ugly though. the ssg is particular doesn't have much more to its model besides what's already on the screen. 
New Builds (0.85.10-r1032) 
New prerelease builds uploaded at





Linux users can build from the source for themselves.

Changes since the previous r980 test builds from Aug. 29 include:

* SDL2 support. Disabled by default, 'make USE_SDL2=1' to enable it.

* Unix/Mac user directories support. Disabled by default,
'make DO_USERDIRS=1' to enable it.

* Revised/improved the 'game' command, i.e. on-the-fly mod changing.
It now accepts an optional second argument for mission packs or
quoth support i.e. -hipnotic, -rogue, or -quoth. For example, for
WarpSpasm: "game warp -quoth"

* Command line: "-game {quoth/hipnotic/rogue}" is now treated the
same as -quoth, -hipnotic, or -rogue.

* Console speed now resolution-independent.

* Disabled gl_zfix, which caused glitches and is undesirable for new
maps. Replacement .ent files to fix z-fighting for several id1 maps
added to quakespasm.pak.

* PF_VarString buffer bumped to 1024, avoids truncated centerprints
from the 'In The Shadows' mod.

* Support for OpenGL vertex buffer objects (VBO) for world and brush

* Dropped support for GL_SGIS_multitexture

For more detailed list of changes see the README file, or browse the
svn history. 
Nice Changes 
As far as 'game' goes. If you start a new mod without any of those 3 variables does it default to no vanilla quake? 
As far as 'game' goes. If you start a new mod without any of those 3 variables does it default to no vanilla quake?

'game xxx' loads the xxx mod on top of bare id1. 
Builds Ok And Runs, But 
gl_texturemode only seems to take effect on the viewmodel. What's up with that? 
gl_texturemode only seems to take effect on the viewmodel.

Can't reproduce here: the rubicon rumble pack mod ( has gl_texturemode as GL_NEAREST_MIPMAP_LINEAR by default, changing it to GL_LINEAR_MIPMAP_LINEAR "beautifies" things for me, and going back to its original restores the mod's original setting.

Never Seen That Before 
Which OS / GPU / gfx driver are you running? 
Found It 
It's anisotropy. The combination of GL_TEXTURE_MAX_ANISOTROPY_EXT with values greater than 1 and GL_NEAREST appears to have vendor-specific behaviour - in my case, GL_NEAREST is ignored.

Hapless users are unlikely to understand this, so perhaps you should consider some workaround. 
Uh, More Detail 
The problem appears for textures that are mipmapped (eg, not models), when gl_texture_anisotropy is greater than 1 and gl_texturemode is 1, 2 or 3.

I'm on Debian with an Intel 82G965 running the usual Intel driver. (A fallback - the fan on my real card stopped spinning, sigh.) 
Ah Thanks For The Info 
Makes sense I guess that anisotropy + no filtering is undefined, We can detect that case and print a warning at least 
gamma adjustment doesnt work (nothing happens at all when you change its value) in r1034 (x32 binary) on win 8.1 x65 nvidia gtx 560 @ 340.52 driver. 
VBO Version 
It's reasonably normal with lower polycounts to get the same, or even a slightly lower, framerate. What's important to realise is that VBOs (and batching) are an optimization for high polycounts. In general you want any optimization to have benefit in that area. Don't sweat the id1 maps; if you see an increase in the big maps then it's doing it's job.

I suggest a move to regular vertex arrays in system memory for MDLs. That will work with any GL 1.1 or better driver (so you don't even need to special-case it) and being able to take each MDL in a single draw call will be of significant benefit. Where you need to multipass you'll also get benefit as you'll only need to do the vertex setup once.

With MDLs and frame interpolation you can't really use VBOs unless you also have vertex shaders (or GL_ARB_vertex_blend which virtually no driver supports) but old-style vertex arrays will work nice.

Be careful that the current colour is undefined after using glColorPointer so you need an explicit glColor3f/4f call for the next immediate mode stuff you're drawing. 
Stack Overflow 
in telefragged, shortly after collecting the gold key, i experience a 'stack overflow.' what do i do?!?!

P4 3.4 GHz, 3 GB RAM, Nvidia GT240, vista, quake injector using the required quakespasm engine (quakespasm svn r980), console screenshot, if it works: 
Excessive happens at that time, so it is probably just memory overflow. How much ram have you got? 
that has nothing to do with ram, that's a QC stack overflow.
looks some trigger (trigger once/multiple/secret) triggering itself without any delay (presumably via other similar triggers).
essentually an infinite loop. 
New Builds (0.90.0-r1036) 
New prerelease builds uploaded at




macosx (SDL2 version):


Linux users can build from the source for themselves.

Changes since the previous r1032 test builds from Sep. 15 include:

* Revised VBO code.
* Version bumped to 0.90.0.

For more detailed list of changes see the README file, or browse the
svn history. 
Wrong Thread. 
command line parameters: -width 1280 -height 720 -bpp 32 -winmem 1024 -heapsize 655360
i'll try the 0.90-r1036 build of the engine.

thanks for the help and info. i meant to post this on the Rubicon Rumble Pack thread. should i repost this over there? 
i used noclip to go over the floor to the gold door without triggering the stairs to continue. 
Linux/Unix Homedir Support Should Be Documented Properly 
The Quakespasm.txt compilation instructions say you can enable home directory support on Linux with the homedir_0.patch. However, a recent change turned this into a Makefile option. The current way to enable the feature can be found here.

You should update Quakespasm.txt section 4.1 to include this information. It is in the Changes section already, but some people might read 4.1 first and wonder where the patch file has gone. 
Thanks. Updated documents as of r1037: 
That's Weird 
I must have done something bad in the qc, but never saw the issue myself or from testers. I did see a similar one, but it was just a broken relay as spike says. 
It's All Good 
i'm just a grateful fan of the masters who keep quake alive. thank you. 
Is This A Known Issue? 
I noticed a cosmetic visual glitch while playing the Rubicon Rumble Pack's map by Hrimfaxi. In a certain location a lift is not visible from outside a room.

If you are careful, you can catch it a couple of seconds after the timestamp into the VOD by Daz. The lift support pillar is invisible for a small while when he first runs up the steps toward the lift room.

I have a save game at this location and a short demo that showcases the glitch. Before packing them up and submitting a bug report, I thought to ask whether this is already a known issue. Should I upload more details for people to look over carefully?

It could be a vis problem instead of an engine issue. It doesn't have any effect on gameplay. The room just looks strange if you happen to backtrack and notice it. 
Just Downloaded The Latest Build 
and was very disappointed to find that it no longer works with my way of launching a mod.

I place my mod files in C:\Quake\Addon\RPP (using Rubicon Rumble Pack as an example), and launch it via a commandline like:
Quakespasm.exe -game addon/rpp

It has worked well for me, as this keeps C:\quake folder tidy without too many mod folders to clutter it.

But it seems that since a few versions back, Quakespasm has introduced some mechanism to prevent using a path as an command line parameter.

Can any one revert its behavior back? Thanks.

Also, is it possible to introduce the capability of using multiple "-game" parameters? In that way, I may even place such folders as quoth into C:\quake\addon, reducing the clutter further. 
Re: Is This A Known Issue? 
I confirm the visual glitch. I noticed before that sometimes, a part could be invisible, then be rendered when the player is close enough.

I firstly noticed this rendering problem on a Cecerello map (jam2). 
Thanks for the report.. I can reproduce it. It's the MAX_ENT_LEAFS limit. I just put in a fix to quakespasm as discussed in this i3d thread: 
Does the Mac version have multisample? If so, how do I enable it? 
Does the Mac version have multisample? If so, how do I enable it?

-fsaa x (x == 0, 2, 4, 8) 
I had tried that. It doesn't work :(

2011 Macbook Pro running Mavericks - ATI Radeon 6490M

I have GL_ARB_multisample in the list of extensions available. 
I had tried that. It doesn't work :(
2011 Macbook Pro running Mavericks - ATI Radeon 6490M
I have GL_ARB_multisample in the list of extensions available.

Might be an SDL issue. Does the SDL2 version behave the same for you?
(See the latest builds at;O=D
I was using the SDL 2 build, 1068. 
I was using the SDL 2 build, 1068.

The latest is 1071, but it won't make a difference wrt FSAA.

FWIW, my situation is similar, both with SDL1.2 and SDL2: It reports that the multisample window creation succeeded but the jaggies are there, so no fsaa for me either.

Eric? Kristian? 
-fsaa works on both SDL and SDL2 builds work on both of my macs (2009 macbook w/ nvidia 9400m, 2012 retina MBP w/ nvidia 650gt).

Try with "-bpp 32" - according to this post, "FSAA only works with a 24 Bit depth buffer on ATI cards"

What does the "video mode (...) initialized" line in the console look like? 
Adding -bpp 32 didn't work ("-bpp 32 -fsaa 8"). Still have the jaggies. I use E1M1 as the test map.

I don't have a "video mode" line in the console when I scroll up. 
Ok, thanks for trying that.

Hm, really no "video mode" line? the top of the console should look like:

UDP Initialized
Exe: 21:43:21 Sep 28 2014
250.0 megabyte heap
Video mode 1920x1080x32 (24-bit z-buffer, 0x FSAA) initialized
FOUND: ARB_vertex_buffer_object
FOUND: ARB_multitexture

It should also print it if you do vid_restart. I'm just wondering what the "(24-bit z-buffer, 0x FSAA)" part is for you. I guess we'll have to put in more debugging logging, though it seems like an sdl bug atm. 
It doesn't print the 24 buffer 0x FSAA.

Just "Video mode 1440x900x32 initialized" 
That must be an old version of QS without FSAA or 24-bit depth-buffer support, then. Try szo's r1071 build from here? 
It works now. 
Settings For 144hz Monitor? 
I am unsure how to setup QuakeSpasm (or any Quake engine I guess) to run on a 144hz monitor.

Currently I am using vsync off with a host_maxfps of 144. I can't see any setting in Quakespasm to set a refresh rate of 144hz but it appears the monitor defaults to that already. Negke mentioned that changing host_maxfps might do weird things to the Quake physics so I'm wondering if there is another setting I need to change to set the max fps to 144 to get the benefit of the screen and no image tearing or input lag from vsync on. 
What monitor if I might ask? I've been wanting to get one of those 144hz 'lightboost' monitors. 
Good Question 
AFAIK the only controls you have in Quakespasm are host_maxfps, and vsync on/off. And negke is right, changing host_maxfps from 72 is probably a bad idea, physics goes nuts (you bounce on lifts, for one). So without messing up physics, currently you're stuck at 72fps.

There is some stuff on inside3d about doing framerate independent physics, IIRC, MH implemented it in RMQEngine and maybe DirectQ. So maybe we could implement that in a future QS release.

How does the default host_maxfps 72 look, with vsync on and off? 
vid_refreshrate doesn't exist anymore? Is it because SDL doesn't support it? 
There's no vid_refreshrate in QS, it looks like SDL1 didn't support specifying a refresh rate.

SDL2 does support asking for a specific refresh rate, so we could probably add it back in.

I'm not sure what the current behaviour is actually, suppose your desktop resolution is 1920x1080 @ 144Hz, and you launch QS in fullscreen mode at 1920x1080. I'd assume SDL would use the desktop refresh rate and not bother changing it to 60Hz or something.

Maybe you can check that Daz, if there's an info button on your monitor that shows the current refresh rate in the on-screen-display? 
Jumping Up Stairs? 
Was that not an original quake physics behaviour? Why cant i easily jump up stairs like in darkplaces or quake 2/3. It would be very helpful as an option at-least. 
Spiney : I am very happy with it!

ericw : The monitor stays in 144hz mode with vsync on/off with host_maxfps 72. There is a very noticeable jump in smoothness when you set host_maxfps to 144 which is why I wanted to ask about this :)

Thanks for the info! 
72 Fps 
Quake's physics and QuakeC expect 72 fps as a server, and single player is both client and server.

Jerky lifts, killer elevators, ... 
More Bugs 
There is a lot of lag in big/complex maps
like in scourge of armagon & Airquake

Some textures can be seen through at far distances like in e1m1

Moving models and those with an attached model are very jittery when moving (the tanks in Airquake) 
Which Exact Build Are You Using? 
Can you reproduce with the latest one from ? Try a clear config (delete/move your id1/config.cfg).

Scourge of armagon being laggy suggests software rendering, what are the first 3 lines of output from entering "gl_info" in the console?

Can you post a screenshot of the seethrough textures in e1m1? 
jumping up stairs is a darkplaces change. 
^ and one that doesn't come without its own knockon effects, like increasing the effective jump height to 64 units from 48. 
Zerst�rer Cutscenes Camera Weirdness 
In light of the map jam 3 theme, I decided to play Zerst�rer using a recent svn version of Quakespasm. I also tried it with the version that you can install from Ubuntu package manager. I downloaded the Zerst�rer package from Quaddicted. (I had to rename the file names to lower case.)

I found out that the cutscenes didn't work quite as intended with either version of QS.

The first cutscene (with the pit trap) had very noticeably jumpy camera movements at some sections. The end cutscene had the camera zoom off to the void before the conclusion and show mostly black.

There is a play-through video on YT for the maps you can watch for comparison (I think it's with Darkplaces), but I think it's quite obvious without them if you get similar results. Please try to replicate, or suggest config settings that might help (if any).

The maps with these two cutscenes are episode 2 and the end map. 
RE: Zerst�rer 
If you are on windows, can you compare against fitzquake-0.85 so that we can understand the source of the issues, fitz or us. 
Speaking From Memory 
The ending cutscene is a Fitz problem definitely. 
Afaik reQuiem has some fixes for that builtin and also it smoothes demo gameplay. jdhack was pretty proud of that. 
The camera jerks about when rotating, its a limitation of something in the engine - can't remember what.

Supa solved it in RMQ. 
I thought it had to do with the networking or something? Coarse values in rotations for faster transfers. 
The cutscenes use a bunch of svc_setangle messages which are controlled by setting ent->v.fixangle (sorry, I don't know the QC equivalent to this). It would be possible to lerp between consecutive svc_setangles engine-side, but there are probably edge cases (aren't there always) that need to be worked out.

Summary is that for zer cutscenes it is a combination of coarseness and widely-spaced (via nextthink) messages. 
Sends a byte angle (256 values representing 360 degrees), so using that to continually reposition the angles is going to be jerky.

[And can't be interpolated client-side because the 'resolution' of byte angles leads to inconsistent rouunding.].

Looks like jdhack has the client read it directly from the server-side camera entity in single player. 
We had daisy-changing and interpolation between multiple camera positions at once on all three axis in both rotation and position - it was pretty fucking sweet :D 
In RMQ engine, it looks like you have it reading/writing float with the RMQ protocol.

jdhack has a lot of code detecting the Zerstorer cut-scene.

I'm hoping that code isn't necessary and just doing svc_setangle as either a short (2 bytes) or a float angle would fix this kind of thing.

The choppy angles in the cutscenes in, say, Zerstorer are annoying. 
The texture bug is fixed in the latest version
Also the lag has been reduced but is still noticeable sometimes

A suggestion, allow quakespasm to read from the the game folders, not only the .pak files 
The camera is messed up in the Monster Match mod 
Svdijk, Szo 
I tested Fitz-0.85 with Wine on Linux. It has the same behaviour, as far as I can tell without a careful side-by-side comparison. The zerend fix pak corrected the end map camera placement.

Rewatching the Youtube clip, I now see it stutters too when the camera is rotating. I think I perceive it as much less annoying because the YT video has a lower resolution and a slower framerate.

Thanks for the responses, everyone! Things work well enough with the patch. It would of course be nice to have non-stuttering rotating cameras in modern Quake source ports, but it's not a feature I really need at the moment.

If I do find unexpected engine differences with a more careful comparison, I'll post about them later. For now, I assume it was resolution, window size and FPS that made the rotational stutter so much more striking in the engine. 
Svc_setangle As Short Or Float 
Right now I don't think this is going to fix anything.

The real problem is that you're relying on how often QC updates the angles. If it thinks at 10fps then the angles are only going to update 10 times per second so it's going to be jerky no matter what precision you send the angle as.

The more robust solution seems to be to detect if a Zer cutscene is playing and use the cls.demoplayback angle interpolation code in CL_RelinkEntities.

At least in this case the QC isn't doing a bunch of PF_WriteChar/PF_WriteAngle calls, but that's also something you need to be careful of. 
checking the zer progs, seems like camera updates are 100fps (time + 0.01).
This is just the low res angles for the camera. 
The irony being that the lower the packetrate used, the smoother the interpolation will be, as the network inprecision is hidden behind larger deltas.
with vanilla quake, with no interpolation, you wanted to spam as fast as you can to try to hit every notch to get it as smooth as possible that way. interpolation won't make that any worse, but you'll see it juddering still as the difference between each frame is non-linear due to rounding. shorts will help counter high packet rates.

my general recommendation would be to update angles exactly once per PlayerPostThink. This allows the client to properly detect when there's a camera active by the fact that every single update contains an angle change. The down side is that this requires the update be sent as unreliable packets instead of reliable ones so that they're kept in sync with entity snapshots over the internet where reliables cannot be acked near-instantly.
Anything else will be jerky in some situation. And yes... needs shorts or low snapshot rates. 
is cutscene smoothness an issue over a network though? 
Cutscenes wouldn't be affected.

Zerstorer happens to be particularly uncoopable in a way that is more than having extra coop spawn points (I recall be pretty disappointed but can't recall the reason why it is uncoopable).

[Nehahra has at least one cutscene but is coopable (although if I recall a couple of rare maps failed to have multiple spawnpoints), but I don't recall anything about the cutscenes in coop (i.e. did they happen or not).

I know there are a couple of more single player releases with cut-scenes, but I can't their names and whether or not they are coop friendly.] 
Config File Organization Tips Requested 
How do people organize their config files for Quakespasm and multiple game directories? I mean the dirs that are selected with the -game option, of course.

I understand that I should put the bindings and options I want into autoexec.cfg files and it is probably helpful to delete the engine-created config.cfg files after modifying the autoexec files. However, what exactly happens if there are several config files that might apply for a given game setting? In what order are they processed?

What config files should I backup/copy, so I can reproduce my settings on another Quakespasm installation? I don't necessarily want to backup my whole .quakespasm subdir, because I don't want to keep all the saves, screenshots and whatnot.

Basically, I'm asking that if someone has worked out a good practice to follow, could they be kind & share the details. I'm asking here because QS is now my engine of choice for SP Quake. 
Preach has a great explanation of how the different config files relate:

autoexec.cfg runs after config.cfg. You can put an autoexec.cfg in id1 and it'll get run on all mods (as long as the mod doesn't have its own autoexec.cfg), so putting all of your custom settings in id1/autoexec.cfg and backing that up is probably the way to go.

I'm pretty lazy and only change a couple settings from their defaults - always run, r_oldwater, statusbar size - so I don't bother with an autoexec.cfg. 
Thanks Ericw 
Thanks for the link. I also found this useful guide with a Google search.

Thought for the day: If I ever get confused which config files Quake is actually execing, I can put a lines like echo "this is from the foo directory" into them and see at the startup what is prints into the console. That'll help clear any confusion, though I think I got how it works already with the help of these links. 
When Quake starts up --- and this is in your console output:

execing quake.rc // This is in a pak file
execing default.cfg // This is in a pak file
execing config.cfg // This is YOURS

couldn't exec autoexec.cfg // This is YOURS

This always prints to the console so you don't need to put an echo in there.

If you are putting your personal settings in autoexec.cfg, that is the only file you need. 
I've run into too many mods that contain an autoexec.cfg, so now I just always launch with a command line that will explicitly +exec a file that has the stuff I'd normally put in autoexec. 
Wrongly Cfgured 
If it's any comfort, the post on how not to do that is one of the most read on my site, so it may happen less in future... 
I read it, agreed with the logic and then went and broke all the rules in a fit of malaise.

I didn't force a resolution afaik though. 
I might have asked this before but cannot remember where. Do any of the modern engines support Nehahra or are they too man mod specific hacks in that for that to be possible? 
is that a fitz derivative out of interest? 
Joequake mostly from what I know. 
I think I found the reason why gamma is not working for me in recent builds.

I have 3 displays connected to 2 videocards (nvidia + intel).
When only one of the displays enabled (whether it connected to intel or nvidia) /gamma starts working.

But it doesn't work with 2 or more displays enabled (and even connected to the same card).

Can you guys nail this bug, please?
Asking because despite the fact that 0.85.9 spams to the console it actually changes gamma with all 3 displays enabled. 
Nehahra Compatibility 
darkplaces is fully compatible with nehahra. i tested it accidentally just a couple of days ago and everything worked fine. new monsters, weapons, powerups and cutscenes.. it's all there. 
Could you give the quakespasm-sdl2.exe a try from here? 
Directq v 1.88 patch 1 also supports Nehehra 
The Requiem menu is hard to use with the backspace key, is there a new version with the traditional menu? 
just rebind keys as you like in the options. the next release will use esc for both Back and Close 
This build do it right - changes gamma only on the display with app (windowed or fullscreen) and restores original value on quit.

Also, there is one glitch - if you change gamma then move window to another display, change it again to another value and then close app, then display's gamma will not be restored to original values, i.e. a reboot required to restore the gamma.

Restarting QS 0.9 does not reset it, BUT 0.85.9 does.

So, you could use some bits from gamma init logic from 0.85 in 0.9, I guess :) 
Quakespasm Bugs Etc 
*qs still lags in big, complex maps/mods. adding "-zone 65536" "-heapsize 92000" "-surfcachesize 320000" to the commandline doesn't fix the problem

*cannot return into the game after alt-tab out to desktop from the menu (no map loaded)

*Use the DirectQ style of having only the muzzleflash have no interpolation; while all the objects of the gun/monster are interpolated

*Read files directly from the game folder, so user can drag & drop models/sounds etc

also, how can i play a music track from the console? "play" looks for wav files in the sound folder (not music) and "cd" looks for a physical disk in the drive

lastly can i restore the old quake menu background? 
remove the visible console bar going up when the map transitions to a cutscene

btw am using ver 0.85.1 
my mistake ver 90.0 
*qs still lags in big, complex maps/mods. adding "-zone 65536" "-heapsize 92000" "-surfcachesize 320000" to the commandline doesn't fix the problem
what are your pc specs? you were saying before that armagon lags - how low of an fps do you get (scr_showfps 1)? what are the first 3 lines of output from running "gl_info" in the console? (on windows, you should be able to copy and paste it from stdout.txt) Make sure gfx grivers are installed... what FPS do you get on the same maps in DirectQ?

remove the visible console bar going up when the map transitions to a cutscene
as a workaround you can make the console speed fast, e.g. set scr_conspeed to 10000

lastly can i restore the old quake menu background?
launch with -fitz or delete quakespasm.pak

also, how can i play a music track from the console?
"music track04" should work

*cannot return into the game after alt-tab out to desktop from the menu (no map loaded)
weird, i'll see if I can reproduce that 
Another Example Of A Disappearing Object 
I found another case of a moving object disappearing when viewed from a certain place. I'm posting a description and a screenshot in case the devs have a use for another test case. If this is already well-covered ground, just ignore my msg.

This happens when walking through the silver key door in e1m2quoth. I'm using Quoth version 2_2. I have not yet upgraded my Quakespasm to the latest SVN version, so I don't know if the latest changes affect this. (This is the second time I spot one of these minor glitches, so it's not like they bother me.)

In the pictures, the missing object is in front of the button near the center of the viewport. It's a moving mechanism that activates the button, and you have to first trigger it with a floor button for it to move into this position. 
That's Fixed In The Upcoming Release 
thanks for the note though. 
Big Maps Performance 
The most useful thing with big maps was moving MDLs over to vertex buffers too. When you think about it, this makes sense: in any big scene there are going to be a lot of MDLs visible and the stock FitzQuake code is particularly bad for these (and made worse because it does a lot of multipassing).

Quoth maps that use the long torch model heavily make things even worse because there is a lot of insane and intricate detail on that model (which you don't even see 99% of the time) leading to a stupidly high polycount.

This normally needs shaders to be able to handle frame interpolation with vertex buffers, but for QuakeSpasm an intermediate step can be done by using client-side vertex arrays. That will also work on any OpenGL 1.1 or better hardware, which pretty much means everything.

The advantages are being able to take each MDL in a single draw call, and being able to calculate the frame once only then reuse that for each pass. Without VBOs you're still streaming a lot of vertex data to the GPU, but it still adds up to a significant CPU saving. 
Quakespasm 0.90.0 Released 
Version 0.90.0 of QuakeSpasm is finally released.

Changes since the previous version:

Two Versions For OS X ? 
What's the diffirence between the "universal" and the SDL2 version for OS X ?

What is SDL2 anyway ? 
hey ericw

8gb ram

in quakespasm i get ~27fps
on the same map in directq,
I get a constant 60fps (vsync on),
constant 72fps vsync off

*Use the DirectQ style of having only the muzzleflash with no interpolation; while all the objects of the gun/monster are interpolated

>>to clarify, I mean in directq, all the gun models' animation are completely interpolated; only the muzzleflash object is not.
so it would make automatic weapons (supernailgun esp) look better when shooting.
Also it would make monsters' attack animations appear smooth instead of choppy

*Read files directly from the game folder, so user can drag & drop models/sounds etc
>>Will this be a feature in the next version?

can ambient sounds be made to always loop even if do not contain a repeat node? that you MH lol? please update directq 
Re: Two Versions For OS X 
Quakespasm is built against the SDL framework (don't ask if you don't already know what that is.) The SDL2 version for OSX is basically the same, except that it is built against SDL2 framework instead of SDL 1.2. 
The "universal" one uses SDL1.2 and will run on powerpc / OS X 10.4. The SDL2 one requires OS X 10.5 and an x86/x86_64 cpu.

SDL2 is just the latest version of the library quakespasm uses that handles things like mouse / keyboard input, switching video modes, etc..

There shouldn't be much difference but you might as well use the SDL2 one. 
@ Ranger 
Ok, cool. which map is that 27 fps on btw? Do you mind posting the first couple lines of gl_info output from Quakespasm? Oh, check that r_novis is set to 0. QS archives that which can be annoying if you leave it on by accident. Might be worth trying a fresh game directory, just extract the engine, id1/pak0+1.pak, and the mod / map in question with no cfgs carried over.

can ambient sounds be made to always loop even if do not contain a repeat node?
*Read files directly from the game folder, so user can drag & drop models/sounds etc
I can see these two would be convenient for modding, but would be incompatible with other engines so I'm not sure.

re: interpolation, it could be nice to have DirectQ's gun lerping as an option. we haven't touched the interpolation code from fitzquake so I'm not sure how much work it would be. 
DirectQ's Muzzleflash Interpolation 
I'm not too certain I'd recommend it. The main problem is that it makes a guess about which polygons belong to the flash and which belong to the gun: if the back-to-front distance from frame 0 to frame 1 is above a certain amount (don't remember what) it assumes a flash (and tags those polys for all frames as flash polys).

On the one hand this idea has heritage (of sorts) in the "if delta is large assume a teleport and don't lerp" code in CL_RelinkEntities. On the other hand it's easy to imagine it not being in accordance with a content author's wishes (although in practice everything I tested it with was fine so it's something that could happen in future). One potential breaking problem is gun models that don't flash in frame 1, of course (that on it's own is enough to recommend avoiding the code).

It does absolutely nothing to deal with player and grunt model flashes. 
For the next release, I'm thinking of going straight to having all mdl data in a static VBO and using a glsl vertex shader (vanilla GL2.0, #version 110) to do lerping and lighting, and fall back to the old Fitz code if glsl isn't available. I have this running and it was pretty straightforward, borrowing the vbo setup code from rmqengine (thanks!).

I got a nice lighting setup that produces identical results as the Fitz code; using the formula you posted here to reproduce the anorm_dots table without having to pass the table into the shader - I calculate the shadevector in C, and just do the dot product with each vertex normal in the shader.

code is here if anyone's interested, needs some tidying and fixing lazy memory management in places.. 
Since you're working on MDLs, and if you're interested, here's a better way of evaluating mins and maxs: (this just reverses the calculation from modelgen.c)

And here you can recalculate normals (again, based on code from modelgen.c):

The anorms table is just an icosahedron subdivided twice so that can also be calculated in code if you like. 
will check those out! 
How can I copy the text from gl_info to a file?
Not sure if this helps but here is the stdout.txt

Command line: C:\id\QUAKE\quakespasm.exe -sndspeed 44100 -heapsize 92000 -surfcachesize 320000 +crosshair 0 -zone 65536 -game aq
Found SDL version 1.2.15
Quake 1.09 (c) id Software
GLQuake 1.00 (c) id Software
FitzQuake 0.85 (c) John Fitzgibbons
FitzQuake SDL port (c) SleepwalkR, Baker
QuakeSpasm 0.90.0 (c) Ozkan Sezer, Stevenaaus
Playing registered version.
Console initialized.
UDP Initialized
WIPX_OpenSocket: Address family not supported by protocol family
WIPX_Init: Unable to open control socket, IPX disabled
Exe: 14:28:31 Sep 29 2014
89.8 megabyte heap
Video mode 1600x900x32 (24-bit z-buffer, 0x FSAA) initialized
FOUND: ARB_vertex_buffer_object
FOUND: ARB_multitexture
FOUND: ARB_texture_env_combine
FOUND: ARB_texture_env_add
Warning: vertical sync not supported (SDL_GL_GetAttribute failed)
FOUND: EXT_texture_filter_anisotropic
FOUND: GL_ARB_texture_non_power_of_two
Intel Display Adapter detected, enabling gl_clear

Sound Initialization
SDL audio spec : 44100 Hz, 1024 samples, 2 channels
SDL audio driver: dsound, 65536 bytes buffer
Audio: 16 bit, stereo, 44100 Hz
SDL detected 0 CD-ROM drives

========= Quake Initialized =========

execing quake.rc
execing default.cfg
execing config.cfg
execing aqalias.cfg
Unknown command "r_maxsurfs"
Unknown command "r_maxedges"
execing autoexec.cfg
Unknown command "#bind"
execing airsay.rc
Airsay.rc v0.9 (21.10.97)
Radio communications script for AirQuake
By FM1_Echo and FM1_Bravo
Based on SayTeam.rc v1.3 by John Laessig
3 demo(s) in loop
GL_RENDERER: Intel(R) HD Graphics 4000
GL_VERSION: 4.0.0 - Build
GL_EXT_Shutting down SDL sound 
can ambient sounds be made to always loop even if do not contain a repeat node?
*Read files directly from the game folder, so user can drag & drop models/sounds etc
I can see these two would be convenient for modding, but would be incompatible with other engines so I'm not sure.

Actually there are a few engines that also read from the folders: directq and i think qrack

the ambient sound looping would also be really useful

when "R_novis 1":
models, doors and sprites are not visible when looking into the water,
and while submerged looking out

r_telealpha, r_lavaalpha, r_slimealpha;
those commands don't exist ; r_wateralpha affects all fluids 
i think the ambient sound looping feature is bad because it would encourage the creation of less compatible content for no good reason.

Also, it wouldn't even solve the problem fully because looping is needed for more than just ambients.

How about a simple command-line tool to convert any wave file to looping? This would help modders just as much and the results would be compatible with all engines. 
You can do looping with which is freeware! 
R_novis 1 
r_novis 1 turns off vis testing client side which only affects the world model and static entities (torches, func_illusionary, ..)

Server side, the server is still checking to see if an entity is in a visibility leaf.

DirectQ has sv_novis 1 which turns off server-side visibility checking against entities (sprites, doors, monsters).

sv_novis is probably on in your DirectQ. 
fair enough lol 
ranger, the gl_info output looks ok, only thing i can suggest is try with a clean config if you haven't already. i've tested QS on the hd 4000 i think (recent-ish intel graphics, anyway) and IIRC it can handle even the largest releases like the rubicon pack decently. 
I Got This Error 
"gamedir should be a single directory name, not a path"

How to make the engine accept path (like addon/czg07) as valid argument for gamedir again? 
deleting the config did nothing

but removing the heapsize surfcachesize zone
args from the CL has removed the lag 
Hey Baker, are you interested in refreshing the QS build in
Well that's service! 
*sometimes the player gets stuck/stopped going down ramps/slopes

*sometimes the mouse randomly goes crazy and makes the camera spin wildly

*When loading maps digs05, digs06

the following appear in the console:

The anomaly
Using protocol 666
Couldn't find a cdrip for track 0
player entered the game
]map digs06
Client player removed
Warning: 40068 faces exceeds standard limit of 32767.
Warning: 48772 marksurfaces exceeds standard limit of 32767.
Warning: 36832 clipnodes exceeds standard limit of 32767.
Warning: 9667 visleafs exceeds standard limit of 8192.
Warning: 9394 byte signon buffer exceeds standard limit of 7998.


The Anomaly 2: Water
Using protocol 666
Warning: 370 models exceeds standard limit of 256.
Warning: 69 lightmaps exceeds standard limit of 64.
Couldn't find a cdrip for track 0
player entered the game
Warning: 913 edicts exceeds standard limit of 600.

*There is a lot of Z-fighting visible on maps 
*sometimes the player gets stuck/stopped going down ramps/slopes

Do you have host_maxfps above 72?

Frames per second above 72 will cause physics problems in most Quake engines in single player.

[Main exceptions: DarkPlaces and the last couple of version of DirectQ because they have framerate independent server and therefore physics. No Quakeworld engine (like FTEQW) would have this issue either.] 
I'm not presuming to speak on behalf of the QS devs but I do feel that this needs to be said.

You really shouldn't be reporting many of these things as bugs. If you actually read the text, you'll see that most of them are just simple notifications that standard Quake map limits are exceeded (which is OK because QS can support the higher limits) or that MP3 music is unavailable for the map you're loading.

These are not bugs.

Now, it could be argued (and I have done so in the past) that they shouldn't be displayed to players, but that aside, reporting them as bugs is just wasting people's time.

Regarding z-fighting, it was already dealt with before, and z-fighting is a content bug, not an engine bug. Again, bringing up an issue that's already been dealt with, and doing so without adding anything new to the discussion, is also wasting people's time.

I could add something here about one of the reasons why I bailed out of engine development being terminal annoyance at constant badgering of this nature, but - oh wait, I already have. 
*Not sure if it's a bug or a limitation, but models with an internal skin taller than 480 cause qs to crash... because qme allows models to have skins with a max height of 512

Actually it is a bug: the maps, esp the second map, lag in qs as well as interfere with the player's weapon anim lerp (due to the lag/overflow etc)

I don't know enough about zfighting but i believed that it could be solved via modifications to the renderer?

my host_maxfps is 72 
Skins with max height of 480 is an original limitation of the engine. Width (as far as I know) has no limit though. 
why would a too-tall skin cause a crash? YOu'd think it would at least give an error message and quit to console, or even better, load it correctly but with a warning. 
Now, it could be argued (and I have done so in the past) that they shouldn't be displayed to players, but that aside, reporting them as bugs is just wasting people's time.

I see your perspective, but I felt that the warnings would be useless if they required Developer 1, since i don't think many mappers use that setting. 
Visual Glitch In Jam3_mfx? 
Quakespasm 0.90 has worked great and I've lately enjoyed playing jam3_mfx among other cool maps. However, I came across a minor issue, which I think is a visual glitch.

There is a room in the said map with four bloodfalls and a gib fountain dropping gibs into the center of the room. Two of the bloodfalls show the other bloodfalls when viewed through them, but since they are not otherwise transparent this seems a little off. The other two are not seethru at all.

Here is a reduced-size screenshot which shows four images in one. The top and bottom ones show this effect, and the middle two ones do not. These four pics are all from different sides of the room.

As usual, I'm asking whether this happens to other QS users. I am using QS 0.90 compiled on Linux64 using SDL2 from the source release. The cmd-line options were -game jam3 and -heapsize 70000 (because I don't like typing numbers with five significant figures...) 
Known Bug 
I think that's the lack of depth-sorting transparent surfaces (FitzQuake does the same.) It's on my list of stuff to fix in qs at some point :-)

the same glitch is visible in the Rubicon pack in a few places (the entrance slipgate of telefragged, the exit of the credits map). 
Good example why fog should reset after each map: Jam 3 pack, playing Tronyn's level last. 
The issue of fog is that getting the right balance between what players expect and what mappers want isn't easy.

If a player sets fog from the console and if it's cleared on a map transition they will probably report it as a bug.

If a map doesn't include a fog key in it's worldspawn as a way of indicating "no fog here, please", but if fog persists between maps, then it's also a reportable bug.

Mix in mods that send svc_fog messages (or stuffcmd it - bleagh) during gameplay and you've a mess.

This is a classic case of a feature that fights itself. As an engine coder you just can't win, and no matter what you do (or if you just say "what a clusterfuck" and don't implement fog at all) you'll have someone pissed at you. 
fog should never have been a console option. wateralpha either, now I think about it.

But the feature was added before any mappers used it, so it didn't make sense at the time to make a feature that no one would see. I get it... but now players have a bizarre expectancy to be able to modify the way the map looks.

You wouldn't play Mass Effect and pull down the console so you could tweak the fog colour. 
Agreed. The map should dictate the fog settings. No other option really makes sense. If the player wants to change the fog AFTER the map sets it the way it wants it, then that's fine. But the map should dictate what it starts at. 
Fixed In Svn 
The bug was that on map changes, only the fog density was reset to 0. Now the rgb values are also reset to their defaults (0.3).

It's probably best to always specify all four density/r/g/b components in the worldspawn key; I just checked Darkplaces and jam3_tronyn.bsp gets black fog vs. gray in FitzQuake/QS. 
Fog Fog Fog 
In principle I agree, but the doubt I have is that this is exactly what a mapper would say. Meantime a player can come along and make an equally forceful argument in favour of user control of everything. The trick is to take off your mapper hat and try to view it from the other perspective.

I need to clarify that I'm not necessarily arguing in favour of the other perspective here: like I said, in principle I agree.

In practice what would be nicer to see is an agreed way out of this that involves both parties being able to have what they want; a way that lets mappers set their preferred fog settings (which could be no fog), that also lets players (and I'm primarily thinking of those who like to sex-up their Quake here, not that I necessarily agree with that mindset) set a fog that will persist over map changes, but that has a mapper-specified fog override a player-specified fog.

The major stumbling block here seems to be the convention of "no fog key in worldspawn = no fog". 
Meantime a player can come along and make an equally forceful argument in favour of user control of everything. The trick is to take off your mapper hat and try to view it from the other perspective.

I'd be interested in hearing that equally forceful argument, because so far I'm pretty sure it doesn't exist. 
In principle I agree, but the doubt I have is that this is exactly what a mapper would say. Meantime a player can come along and make an equally forceful argument in favour of user control of everything. The trick is to take off your mapper hat and try to view it from the other perspective.

To this, I only ask what other game lets you go in and change things like skyboxes and fog that are integral to the look of the game.

If I ever release another map, I'll stuffcmd the fog and skybox every frame just to be a dick. :P 
A Way Out 
A compromise proposal:

Fog has a "background state" which is only ever set by direct use of the fog cvar. The fog key in worldspawn is treated as a temporary override of the background state - once the map ends the background state is restored before the next map loads. Background state can be "no fog". If a fog command is issued during the map, this will not only produce an instantaneous change, but also update the background state to the given settings.

Result: on load, maps with fog keys look like the author intended. Maps without a fog key appear as the player sets fog by default (sober people: none, eyecandy freaks: lots).

Of course, info_command entities changing fog throw a spanner in the works. I can think of two unpleasant ways to work round that, but I will practice restraint and post neither... 
Does Requiem support BSP2? 
If you do what Preach suggests for fog, you should consider doing it for skyboxes as well. 
EUMA's, 2015 Going Forward! 
Cousin to the EULA, all maps and mods will be released from this point forward with "End User Mapper's Agreement".

Any player who changes a graphical or gameplay setting, config file or other game enhancing feature, excluding and limited to key bindings, will void said EUMA and have said map/mod removed!

Now we just need the Mappers to DRM their creations to enforce it... 
Conservative Hat 
I always thought the fog and sky commands in Fitz/QS were a good balance between mapper control and player tweakability. Yes, they're reset on every map load to the worldspawn values (or if not set, the engine defaults). I like this because I can mess with fog and not have to worry about restoring it to the original value.

If there is really a demand for a way to control the fog of maps with none set in the worldspawn, maybe a dedicated "r_defaultfog" cvar would be the cleanest. But I have to say, I'm not a big fan of the idea, e.g. my jam3 map has no fog setting in the worldspawn; it's really intended to be played with no fog, not "whatever fog". 
"To this, I only ask what other game lets you go in and change things like skyboxes and fog that are integral to the look of the game."

Yeah, I agree. We don't allow anything else to be customized ... what's so special about fog? 
Is there anybody who seriously goes and changes the density and color of fog, just for the sake of extra eyecandy? 
Absolutely, checkout the stuff at and the various HD packs. 
Yes, but should that override the mappers intentions? I mean, fog isn't chosen for a map at random. 
HD Packs Aren't Fog 
I Dunno 
They do stop you seeing the level if you apply enough. 
Fog is one of the settings that HD packs like to set (afaik, I am not into that kind of stuff). 
We should add settings for tweaking color ranges. Like, if I don't like red lighting I should be able to tint it more towards orange.

Also, lava kind of sucks ... being able to switch that to slime would be great. 
Is anyone here colorblind? Not that this matters a lot, but perhaps there's an argument for a colorblind mode or somesuch. 
Dark Places let you change the colour balance with RGB sliders? 
Lol Warren 
oh, i thought you guys were actually interested in some kind of meaningful discussion. my mistake.

zwiffle: there is at least one ex-mapper. statistically about 5% of men are more or less, they rarely speak about it though. I know of 4-5 players but that's a fraction. 
RGB sliders for fog would be awesome... 
Yes, but should that override the mappers intentions? I mean, fog isn't chosen for a map at random.

That's not actually the point being made.

Of course if a map specifies a certain fog setting, the engine should honour it and the player should accept it. That's not in dispute.

The point being made is that where a map doesn't specify it's fog (or water alpha, or skybox, or whatever), right now there are two possible interpretations and both are valid:

(1) The mapper doesn't specify fog because the mapper doesn't particularly care, never thought to do so, or else the map predates engine support for fog.

(2) The mapper is explicitly specifying no fog.

Interpretation (1) is the only case where the player can go nuts with user-specified fog. This is the case that, if you look at the world through mapper-coloured glasses you, may miss becoming aware of.

Interpretation (2) is unambiguous: again, the mapper doesn't want fog and the engine should honour that. Again, that's not in dispute.

The problem is: how does the engine tell which of interpretation (1) or interpretation (2) is the case? 
#2 is the safe assumption. 
Set it to whatever the map is set to on load. Players can change it after load if they want to, but assuming the map is authoritative is the best way of respecting the mappers intentions.

If players change it after load, so be it.

That should really be the end of the debate. :) 
Reminder that the original point of debate was:

fog should reset after each map

And it's bloody blatantly obvious it should. 
if you look at the world through mapper-coloured glasses

Shame for us all, looking at Quake maps through mapper glasses on a Quake mapper forum. 
Let's All Think In Binary Choices. 
You are ignoring mh's insights on how people out there actually play Quake. Try looking outside the box some day. 
What if there was an additional fog-related cvar to toogle persistent fog that carries over across level changes and reloads. Could even be 1 = persists until loading a map that has a fog field of its own, and 2 = overrides maps' fog settings. Disabled by default, so only to be used by people who know what they're doing, who are aware of the possible unwanted effects. 
Pfog! Phog! 
"You are ignoring mh's insights on how people out there actually play Quake."

Nobody here does that. And we all play Quake. 
01100110 01101111 01100111 
I'm gonna say to make the fog command a mapper/mod setting that gets reset on map changes. With mods stuffcmding from triggers etc, doing otherwise is too unsafe.
If users want to override it, they can either do it on each map change or the engine can implmement something per-map like:
I'm Not Ignoring 
I'm dismissing. 
Shame for us all, looking at Quake maps through mapper glasses on a Quake mapper forum.

Ah, but the question is: what's the purpose of releasing a map?

Sure, you can make a map for your own satisfaction (hell, even I've done that), but why release it? You release it to be played, by players, unless all you're interested in is a mutual back-slapping exercise among the mapping community. 
I'll Just Keep On Derailing The Thread 
what's the purpose of releasing a map?

Can't justify working on it anymore. 
"You release it to be played, by players, "

Yes, and ideally they play the map you designed not the one they customized. :) 
Talking At Cross-purposes 
I think there's a lot of cross purpose chat here, so I'm gonna try and post a few non-controversial things that everyone should agree on.

1. Maps with a fog key on should be loaded with those fog settings.
2. Going to a map with no fog key should reset fog to default in some sense.

There is a useful discussion buried somewhere in this thread, but it seems to be drowning amid people trying to argue in favour of 1. and 2. when actually nobody is arguing against them. mh, is this a fair point to start from? 
what's the purpose of releasing a map?

The feeling of self achievement of having a "thing" under my name being "out there". The knowledge that I've learned a lot in the process of making it. The enjoyment I get from playing it. The knowledge that my target audience might even enjoy it. And if they don't, I'll get earnest feedback from them, because there is no "mutual back-slapping" in this community at all. (But you probably haven't noticed that, because you're a complete cunt.) 
Because he makes reasonable well thought out conversation points and great engines? 
Both of those points are questionable to say the least. 
Guys, Please... 
Also, my cocern wasn't even so much about the questions "what the player wants" versus "what the mapper intends" than the risk of accidentally, unintentionally or unknowingly 'spoiling' a map with the wrong settings. 
Questionable But Not Questioned? 
OK, I think I phrased my preamble wrong. I wouldn't want to go as far as saying nobody would disagree with 1 or 2, simply that at the moment it doesn't seem like anyone here does disagree with either. 
Most players aren't going to customise the fog.

If they want to, that's fine by me - I always release the map sources and its not even my IP, so I've nothing to get shirty about.

It's just a bug; maps shouldn't inherit fog not intended by the creator. 
One Toxic Prick 
It's not just fog though, think of things like wateralpha too. I'd wager that custom wateralpha settings and vispatched maps are much more common than people using different fog settings. Quake is messed up. :} 
Just To Be Clear 
Fitz/QS have always reset fog on map changes (whether or not the map you change to has worldspawn fog). So do Darkplaces, FTE, DirectQ, RMQEngine, and Qrack. The only engine I know of that doesn't is ezQuake (e.g. map e1m1, turn on some fog, map e1m2 - the fog will still be there.)

The thing with Tronyn's jam map was just a weird bug - Fitz/QS were clearing fog on map changes by just resetting the density to 0, which would normally work fine, except Tronyn's map happened to only specify a density, so that was combined with the last set of fog colors used.

I don't think anyone's really arguing that QS should change its fog command to match ezQuake. 
I missed that in the back and forth.

So, just set all 4 values to avoid the bug... 
Yeah, my primary argument was towards just removing user configurable fog and skybox (thereby rendering the problem of whether to reset to no fog or user specified fog on a map change a moot point). 
Tweaking Cvars Randomly From Gamecode For Anything Except Menus Is Evi 
+1. People think these trigger_cvarset maps are buggy. I'm scared to copy-paste this into my engine. Also, why is 'fog' is a command and 'r_skyfog' a cvar? 
..Is Evil 
My title was one char too long. Anyway, skyfog could be an arg tacked on to the 'fog' command. 
+1 Qbism 
fog has 5 values then. 
Fog Alpha R G B Sky 
Yes. That would be more consistent with expected behaviour and compatible with engines that don't support it. The 5th value would be ignored without crashing in that case. There could still be an r_skybox cvar for players to tweak. 
one issue with that is that DarkPlaces already uses the 5th value for fog alpha, which is different than r_skyfog. Not sure if any other engines already use it for something too.

I still think skyfog as a separate worldspawn key is the way to go. 
+1 Skyfog 
That would be even more compatible. Again it does not preclude r_skyfog. Also I should have said 'fog DENSITY r g b'... density is more accurate 
But you probably haven't noticed that, because you're a complete cunt.

Maybe I am, but this kind of thing seems well-worth discussing even if so. Would you not think that nailing down some predictable and consistent standard behaviour in a case where a grey area remains owing to sloppy and/or weak initial standardisation is worthwhile? Is that something that could be of benefit to the entire community? 
Do whatever Preach says. :) Thanks! 
A number of old releases were made for GLQuake and never tested in WinQuake or an engine that supports fullbrights. And as a result, you have fullbright patches in the map textures.

It is possible that in the future, some sort of informational only external .ent file could tell the engine not to use fullbrights on the map textures supplied in the .bsp.

Similar to the idea of producing external .ent files signaling the author's intended r_wateralpha value for the level.

I'm just filing this thought here. 
.ent Files 
I have problems with these on practical grounds.

A .lit file can be associated with the source .bsp by comparing the size of it with the size of the original lighting lump.

A .vis file can be associated with the source .bsp by comparing the number of leafs in it with the number of leafs in the original leafs lump.

There's no such comparison available for .ent files.

Sure, you can do string comparisons of certain fields in the worldspawn entity but it just doesn't seem as robust.

I'm aware that Quakespasm has it's own way of checking these, by means of only loading them from the same gamedir, but I can see a case where someone might want to keep these modifications in a second gamedir so they have the option of playing with either the original content or modified content.

I personally have the extended Dismal Oubliette (among other things) in a pak2.pak in ID1 so how can I be sure that a hypothetical .ent file for it - even if loaded from ID1 - refers to the original version or the extended version?

I don't pretend to have an answer to this, just highlighting potential issues as they occur to me so that we don't end up with another half-baked standard that isn't as robust as possible from the outset. 
How can you determine if an external .ent file is for the right .bsp?

Right now, you can't.

But I guess a .ent file could have some information about the expected .ent size or count it should be replacing, perhaps in the worldspawn section or some such thing. 
what about an md5 hash of the bsp file? 
how about... don't use the .ent file if it's lower on the search paths than the .bsp file of the same name?

i.e. id1/maps/e1m1.ent won't override mymod/maps/e1m1.bsp

likewise, a .ent in a pak file won't override a loose bsp in the same game dir. 
how about... don't use the .ent file if it's lower on the search paths than the .bsp file of the same name?

I'm not saying this is something that does happen, but I'd prefer a solution that can handle a case where somebody manages to get e.g a hipnotic start.ent into their ID1 directory.

This is mostly coming from reading various QuakeOne threads and observing the difficulties that people have with even getting the most basic stuff set up right. 
i think my suggestion would handle that by rejecting the start.ent (start.bsp would be later in the search path in that case.)


Actually a pretty good check would be to compare number of submodels in the bsp... since they are referenced in the .ent file right?

That would only fail if the .ent file doesn't use the highest-numbered submodel, which is still a point of failure i suppose. 
@metslime ... I don't think it does even now with Quakespasm's ingenious content protection scheme. 
I think QS already does what metl suggested; here's a comment from gl_model.c:

// use ent file only from the same gamedir as the map
// itself or from a searchpath with higher priority. 
yay, problem solved. 
QS seems to run significantly slower after I die and reload the map. How come? 
Very Weird 
Shouldn't happen, I'd like to be able to reproduce that. Can you give me a scenario where it happens, like any command-line flags (heapsize), mod/map. Assuming the win32 0.90 exe? You're just pressing space to restart when dead, not loading a save? Can you see an increase in the frame times reported by r_speeds? 
Powerup Flash 
what console command disables the screenflashes when grabbing powerups? 
gl_polyblend 0 
Wait What? 
the powerup flash is built in and can't be disabled.

although, amusingly, if you type 'bf' into the console, it will play it. 
My Bad 
i forgot, but it's not actually 'built in', but is part of the progs.dat.
The code actually sends a 'bf' console command when you pick up items. In theory, you could make a mod to disable it. 
Or In Theory 
You could also create a modified engine that makes "bf" a command that does nothing - or have a cvar that introduces that change. I read ranger's post as looking for such a cvar, dunno if it's an existing feature in quakespasm or elsewhere... 
Minor Issue With Joined Console Commands 
This one is a really minor issue. It's about as non-urgent as they come, since working around it merely requires typing in the console commands separately.

I noticed that you cannot autocomplete map names when joining multiple console commands using a semicolon. The following happens to me on QS 0.90 using the Quoth mod as an example. Any collection of Quake maps will do.

I start the engine and enter the command "game quoth". There are now maps titled breakable, e1m1quoth etc. available to launch from the console. If I type "map " (including the space), I can press tab to autocomplete them. This works as intended.

Let's say I want to play on Hard. I type "skill 2; map " and try to autocomplete the maps now. It doesn't work. It only offers to autocomplete commands instead of map names, which isn't right in this context. If I type in a proper map name, the commands still work, as you'd expect.

Presumably the autocomplete logic considers the whole console command line and not the part after the last semicolon. This would be a nice little thing to fix if you revamp the autocompletion feature some day. 
Uneeded Levelshots 
SQ saves unneeded levelshots TGAs in the game's maps folder.
These image are never seen ingame and the files take up space, so QS should not generate these files anymore 
QS Crash 
texture coords on a brush were:
16777740 1584.00 832

don�t ask...

FitzMKV crashed too. 
What The Fuck Is That 
Looking For Testers 
I was wondering if anyone with AMD/ATI cards could try this build for me (I've tested some intel and nvidia cards already, but if you have those you're welcome to try it too):

It has the alias model speedup I've been working on (only requirement to get the speedup is opengl 2.0+), so a good map to test is jam3_tronyn from map jam 3, with its 120k epoly. A good commandline would be:

"-heapsize 256000 -game jam3 +map jam3_tronyn"

then check the first number of the r_speeds when looking at the demon face. If it's not too much trouble, checking the r_speeds with QS 0.90.0 for comparison would be great too. With any luck, the frame time should be half of what it was in 0.90.0. Thanks! 
Ok Here 
I guess you mean the start of jam3_tronyn. On my HD 6750 it improves from (some version of 0.90) ~ 13 ms to under 5 ms.

Havent played that map yet. Third of the way through now... Not bad :) 
in line 505 of vid_glsdl.c, can you please add SDL_WINDOW_BORDERLESS to flags? Makes it possible to run without window decorations in window mode, useful for dual-head setups when playing on non-primary monitor (for SDL2, i built it with USE_SDL2=1). 
@stevenaaus, thanks for testing - that looks like a good speedup!
@LeopolD, sounds like a good idea, we maybe could have a vid_borderless cvar. 
That would be even better:) 
R_speed Test 
Went from average 69.15 to 12.21 on a 6770 using OSS radeon drivers.
Pulling the console down almost doubled the value on the old build while the test build kept the rate. 
Gamma And Runes Problems. 
Hi! Thanks for all the hardwork in the port :) however, I seem to have come across two problems:
1.-Gamma isn't respected unless the engine is set for 16 bit color depth; if using 24 the gamma slider works and the gamma console command indeed changes the brightness, the gamma value is saved, but ignored when exiting and restarting the game (or rather reset when the vid_restart occurs in config.cfg), it's a bit annoying having to reset the gamma (by typing gamma 1 to "reenable it": the engine assumes the value it read is already there [despite being ignored] and does nothing, and then gamma 1.35, since the slider won't go above 1 and 1 is to bright, could these values by fixed, too?) every time I start the game.
2.-My runes disappeared! I finished episode 3 (after finishing 1 and 2 beforehand) and noticed the bars weren't there...true runes. Sure it can be fixed by impulse 11 (and I know it can happen in vanilla Quake), but it's annoying nonetheless.
The engine I'm using is the latest stable Windows 64 bit build, SDL 2 with a GeForce GTX 750 Ti using the latest drivers (347.09 at the time of writing). It may or may not interfere that I do have the drivers set to use NVidia color controls (since allowing "other programs to control color" makes the desktop [and mostly everything] look like ass). Other games have functional (or not ignored) gamma controls.
Thanks in advance :) 
@Bloodbat - Runes Disappeared 
Did you use the "kill" command at any stage? This is an old Quake bug where the "serverflags" field is wiped by using kill, and I guess that QS hasn't fixed it. 
@mh - Disappearing Runes. 
Nope, no kill command. The only command I've used is vid_restart and some screen related cvars (including, obviously, gamma) for dealing with and testing the other problem I mentioned. 
Bsp2 Leafs 
I'm getting an error trying to load a BSP2 map that exceeds 64k leafs. Shouldn't this limit have been raised (or abolished) for BSP2? 
The file format itself abolished the limit, yes, however, the PVS buffers within the engine tend to be a fixed size, and there needs to be one bit per leaf.
large leaf counts are just all kinds of bad.
By the time you reach 64k leafs, your uncompressed pvs data is half a gigabyte.
If your editor supports detail brushes, try using those. 
Ok guys, what are the chances of putting this into Quakespasm:

QuakeForge uses shader magic to simulate the look of the software renderer... 
I don't see the difference between that and changing the texture mode using gl_texturemode 
the output pixel colour uses quake's colormap like in SW rendering (which is a lut basically that combines texture pixel colour with the lightmap)

It really makes a big difference imo 
There's a subtle difference in that a GL engine, even with a gl_texturemode change, calculates lighting by doing a multiplication of texture colour by lightmap intensity.

The software Quake approach uses a lookup table but the result of the lookup is constrained to colours that are in the Quake palette, whereas the GL multiplication can produce results that are not in the Quake palette.

For a truly authentic look you'd also need to use the software Quake miplevels, since once again these are constrained to colours in the Quake palette but GL's miplevel reduction can likewise produce colours that are not in the palette. 
Oh ok, so the lighting being restricted to the palette? Fair enough. 
I would really like to see before and after shots on that. 
(because I have no idea what kinn is looking at) 
+1 Simulate Software Quake 
i think that would be great, I really like the look of software quake... it just seems more surreal and gritty. 
Random saw this

The QuakeSpasm developer said that I'd need a full version of Quake for the music to work.

Bacause of the shareware is limited to only what is inside pak0.pak file - music resides outside it so the engine ignores it.

I am 99.9% sure that the Quake shareware came with the CD audio, can check if you want me to. You could unlock the full version with just the shareware disc so the CD audio had to be on the disc.

So there is no reason to block CD audio if someone does not have pak1.pak. 
There is one important difference between software and GL: 
That's the first show that shows the difference pretty clearly. Winquake seems much sharper and harder due to the way the palette has to cope with gradients. 
also....models have minlight in software? 
IIRC models are minlighted to 5 in order to avoid a check for division-by-zero in an inner loop.

The MDL lighting is almost completely different in software in general; it just doesn't use the same calculations as GL did, although I don't recall specifics. 
Yeah, in software, mdl's have minlight. From this comment, it sounds like the reason for doing that was an optimization:

#define LIGHT_MIN 5 // lowest light value we'll allow, to avoid the
// need for inner-loop light clamping

I'm not sure if this is the only difference. The code for determining the light level of each mdl vertex in software quake is structured a bit differently than glquake. These are the relevant parts of sw:

And glquake: 
QuakeForge uses shader magic to simulate the look of the software renderer...

Hmmm - we're not really about geewhizz effects.

I do love these effect sort of things ... but the code belongs in separate patches and/or forked projects. 
I Don't See It 
unless.. are you talking about the banding from lighting? why would you want that, it looks shit. 
I can see where this conversation is going.

I'll just leave it at that, and say that yes, quite a few people do actually like quake's original 8-bit aesthetic, and have done for some time. 
I like the 8bit feel. It's difficult strokes for different folks. :) 
Dev Build 
if anyone wants to test a dev build, there's one here with some neat features:

@Bloodbat: this has a new gamma implementation that should fix your gamma issues
@LeopolD: I didn't get around to adding vid_borderless, but did add something: set vid_desktopfullscreen to 1 to make fullscreen mode use sdl2's new "fullscreen deskop" mode.

Other stuff:
-it has the glsl-accelerated mdl renderer. Szo reported an issue where some models are rendering black on his AMD card, still working on finding that bug.
-"game" command tab-completion
-demo pause support 
Cause Of The Missing Runes. 
I found the cause of my missing runes: if I die and click the mouse to respawn (and presumably load the last save)...the runes are gone, this behavior doesn't seem happen when loading from the menu or using F9 to quickload. Hope this helps fix it. 
I reproduced it this way:
"map e1m7", grab the rune, then "changelevel e1m1". save. get killed. click to respawn, you will still have the rune.
Restart the engine. Load the save, you will still have the rune. Get killed, click to respawn: this time the rune is gone.

I think this is the same bug mh was talking about, pretty sure there's a fix on inside3d, so I'll have a look at integrating that. 
Runes Runes Runes Runes Runes 
Almost certainly it's the same bug.

I've personally only observed it with the "kill" command (and have a hacky workaround for it there) but that doesn't mean that it doesn't occur elsewhere or have a different source. 
Re: Dev Build 
svn'd up, working fine here on my OpenBSD box, and gamma works, thx! 
Quakespasm Feature Request 
Have you lads had a taste of HRTF? Aka binaural audio. In case you're unaware, it's a form of surround sound which can be played through any standard ear/headphones and soundcard. It's available in zdoom/gzdoom, where it's rather amazing to hear. There is a version available in the form of openal soft. Any chance of integrating that into quakespasm? 
I will have to try that in gzdoom. yquake2 also has an openal backend:

Can't promise it will happen; the Quake sound code is a pain to work with so it might be a fairly substantial project. Also, I've found it's important to mix all the sfx at 11025Hz, otherwise you lose the "classic" sound (the Quake sfx clip a lot when mixed, but it sounds ok if the clipping is at 11025Hz). But it could be an optional backend of course. 
above was me.

re: the runes bug, I looked in to it, and the background is, there are two pieces of information about each rune: 1. does the player have it, 2. has the player beaten a level while holding it. #2 determines whether you get to keep the rune after dying. The problem is the savegame format doesn't keep both of those pieces of information, I think it only saves and restores #1. IMO it's best to just live with it as an "old gameplay bug". 
While you are still thinking about, can you describe in more detail the specifics?

The documentation of this problem is essentially non-existent and I know I'd like to "once and for all" at least know what is going on.

[And opens the opportunity for someone other than yourself to maybe even solve it.] 
Re: 1454 
I had a soundcard that did that way back. Gave me a huge advantage in multiplayer games because I could easily tell when sounds were behind me vs in front.

As far as I know, it was a hardware thing, don't know what software has to do to support it. 
The two variables are:
pr_global_struct->serverflags stores whether you are currently holding the runes.
svs.serverflags stores the "permanent" state of each rune: whether you completed a level holding the rune, so you would get to keep it after dying.

So when you grab the rune in e1m7, pr_global_struct->serverflags has a bit set to 1, while in svs.serverflags it's 0, so if you die in that level, you lose the rune and have to grab it again.

When you beat the level, Host_Changelevel_f calls SV_SaveSpawnparms, which copies the rune status into svs.serverflags making it permanent. If you die in another level, you spawn with the rune again. (In SV_SpawnServer, there is
pr_global_struct->serverflags = svs.serverflags which means you currently have the rune if you previously had it permanently.)

The issue is, saving only saves pr_global_struct->serverflags (via ED_WriteGlobals), and loading only restores pr_global_struct->serverflags. If you don't quit the engine, svs.serverflags will stay however it was, but if you quit it gets reset to 0. So the info on whether you had a rune "permanently" is not kept in the savegames.

mankrip on i3d also investigated it and I agree with his take on it:

He points out that if you try to work around this using methods like "copy pr_global_struct->serverflags into svs.serverflags when loading a savegame", it creates this bug: grab the rune in e1m7, save/load, die in the lava -> you should lose the rune, but you don't. 
Runes are stored in the QC in the "serverflags" global, which corresponds to pr_global_struct->serverflags in the C code. That's the "does the player have it" part.

They're also stored in svs.serverflags which is the "has the player beaten a level while holding it" part.

svs.serverflags is 0 when the engine starts and is only ever set to any other value during a "changelevel" (see below).

When issuing a "map" command svs.serverflags is set to 0, then SV_SpawnServer runs.

When issuing a "changelevel" command SV_SaveSpawnparms runs which first copies pr_global_struct->serverflags to svs.serverflags, then SV_SpawnServer runs.

During SV_SpawnServer the progs are loaded which sets all QC globals to their defaults, then copies svs.serverflags to pr_global_struct->serverflags so that it's updated from whichever value was stored - either 0 ("map") or it's previous value ("changelevel").

The savegame format only stores pr_global_struct->serverflags, not svs.serverflags.

So the value of svs.serverflags needs to be valid in order for runes to be properly restored.

Steps to reproduce.

Grab a couple of runes (cheat if you like).
Save the game.
Exit Quake.
Restart Quake.
Load the game.

Runes are gone; it doesn't matter if you die by the "kill" command, by jumping in lava or by getting too close to a Shambler.


svs.serverflags has lost it's stored value during the exit Quake/restart Quake cycle, so when SV_SpawnServer runs after you die, it restores them to 0.


In Host_Loadgame_f, after restoring all of the values of "svs.clients->spawn_parms" and before calling CL_EstablishConnection, add a "svs.serverflags = pr_global_struct->serverflags;" line.

I think that should do it. 
Now that I've read ericw's post, yup, that's a problem... 
nice two-person reply, mh wins for better formatting.

The only good thing about the original bug is, if you save, quit, load, and manage to beat the level without dying, svs.serverflags will get updated and everything will be fine after that. 
Just done some more testing, and I think that the bug where you still have the rune is the lesser of the two.

It only affects maps which have runes so it doesn't falsely give you runes you shouldn't.

The rune can still be picked up.

And losing them when you die gets fixed.

So it's a toss-up between having a rune which you're going to get later in the map anyway (and which doesn't otherwise affect gameplay) versus losing all runes to date.

The only thing I can think of against it is maps which use runes as keys as well as for cross-level info, which doesn't affect ID1. 
I guess the 'ideal' solution is to reload the saved game instead of restarting.
might need to cache the save in case someone overwrites it though.
possibly more useful in other situations too.

as mh suggested, I'd just go with giving the player a freebe rune, it won't break anything or confer any advantage, it'll just look a little buggy on the hud. you need to grab the rune to open barriers infront of the exit on each map anyway.
if you want to hack some kind of (hud) fix, you could just scan for an item_sigil entity and clear out any serverflags that match the spawnflags. thanks to the qc clearing out the rune's classname, this should work even if you save after grabbing the rune.

or you can change the saved game format (possibly just add some //comment at the end of the file, ala dp). 
Would freebie rune affect Cthton? You have to pick the rune up to trigger Cthton to attack.

[If he kills you and you still have rune, cannot complete E1M7.] 
Ah, I get it.

Save game doesn't know what you arrived on the level with.

How the heck do you keep carry-over weapons? Or do you? 
Most of the stuff you arrive on the level with is in spawn_parms. Sigils ain't, and that's the root of the bug. 
Elevator Bug 
when the player is looking up when on a moving elevator, the screen sometimes 'stutters'/character seems to sink into the elevator

QS 0.90 
When the moving down & up certain ramps/convex geometry, the player gets stuck/stops and can't move forward 
make sure the host_maxfps cvar is set to 72, having it above 72 will cause both of those symptoms 
Minor Bug In Multiplayer 
When dead players respawn, their corpse's colors revert to the default colors (yellow shirt/orange pants). This does not happen in any other Quake engine I can think of 
isn't that a bug with the original game? 
Yeah pretty sure that's a GLQuake thing. Not sure if any of the modern GL engines have addressed it. 
Don't have bug:
Quakeworld (any GLQuakeWorld, FTEQW, ezQuake, ...)
DirectQ + Remake Quake (pretty sure)
Mark V
Modern ProQuake (although I've seen a bug)

It is a pain to address because to do it right, you have to keep track of the color map for all entities (scoreboard) and then if a player color changes you have to recolor any skin or texture (it might not be player.mdl -- the player could have been gibbed. Some mods support more than 1 skin. Some mods support more than 1 model.). Then you have the problem that if the engine supports external 24-bit textures, then how do you even know what parts of the image are shirt or pants color (so DarkPlaces, for example, has _shirt and _pants support. ezQuake has something similar).

WinQuake doesn't care, it is a palette based renderer so when it paints color it can seamlessly substitute a slightly different palette -- it doesn't need to repaint a texture.

Stock Quakeworld including ezQuake just do it for the player skin. FTEQW from what I recall Spike saying, does it correctly for everything.

It isn't easy to address in code, you have to check changes in entities and changes in the player color too and rework the texture manager. It isn't fun. 
If a player does not change their color or model, could the corpse then still use the live player's already recolored texture in memory? Players changing models or colors is so rare that it would be a lot less jarring to revert when that happens than always upon respawning 
even when you do it 'properly' you still have weirdness when people disconnect or change teams (TF spies... grr, or worse: TF's animated+coloured teleport pads). 
could the corpse then still use the live player's already recolored texture in memory

You still have to keep track of what corpses go with what player. What if a player disconnects? What if a player grabs an invisibility ring? And if you ignore those, you still have to actively monitor any entity to be a corpse and change stuff in the texture manager. And there can be models with invalid skin numbers.

Doing it poorly isn't much easier than doing it right. Even doing it poorly is hard.

There aren't any easy answers for this one, but one of the older Mark V source codes has the changes marked in a straightforward manner. 
i've found that assigning a corpse's colormap to the player to work.

if ((gl_color_deadbodies.value) && (ent->model->modhint == MOD_PLAYER))
if (ent->colormap > 0)
texture = (playertextures) + ((ent->colormap - 1));//Colored Dead Bodies
fb_texture = fb_skins[(ent->colormap - 1)];
texture = (playertextures);
fb_texture = fb_skins[0];

Though, i'm getting black skins when someone is culled via cullentities...but the corpse suddenly 'color corrects' itself when the owner of the corpse comes into view.

And for 24bit skins i use ent->pantscolor ent->shirtcolor and run a pass twice over the model for shirt and pants; which DOESNT have any issues at all. 

in world.qc in the bodyque
we already have
bodyque_head.colormap = ent.colormap;

so we are already 'tracking' the color of the owner in quakec. 
Oops Cant Edit Post... 
here's how im assigning the shirt & pants in cl_parse

if ((i > 0 && i <= cl.maxclients) && (ent->model) && (ent->model->modhint == MOD_PLAYER))
ent->shirtcolor = (cl.scores[i - 1].colors & 0xf0) >> 4;
ent->pantscolor = (cl.scores[i - 1].colors & 15);
ent->colormap = i;
Fog Rendering Strangeness 
I have linked an image comparison of three views of jam5_hypnos.bsp.

It shows how the fog looks in Darkplaces versus Quakespasm 0.90. You will see that if I look across the grimy water in QS the fog colors all of its surface light blue even near me. However, if I walk right to the edge and look down, the liquid texture appears in place of the fog color. In other words, the direction I am looking affects how the liquid surface looks, which is weird.

I'm not sure what is going on here. Could I be using some odd fog setting accidentally that makes it work this way? Does anyone else see this, or does it look more like the Darkplaces screenshot to you in Quakespasm too? 
Further Info 
The rendering effect I described above happens when I have r_oldwater set to 0. If I enter r_oldwater 1 in the console, the scene looks similar to the DP screenshot.

So if you try to reproduce, see if the two different r_oldwater settings have the same effect for you. 
Hmm, thanks for the report. At first glance I can't reproduce that, with QS 0.90.0 r_oldwater 0/1 look the same (except the slight difference in water quality). Here's r_oldwater 0:

I have a guess at what's happening from you screenshot - with "r_oldwater 0" the water texture gets drawn on the screen between frames and copied back to a texture, it looks like it's picking up the fog there.

Would you mind checking whether you get the same issue with fitzquake 085?

Also, what's your graphics card? 
Same With Fitzquake 
I ran fitzquake with Wine and got the same result when I set r_oldwater to 0 in the console. Same thing with the water texture coming out when looking downwards too.

I have 64-bit Ubuntu on my laptop with an integrated gfx card. Here are some lines from my glxinfo.

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.2
OpenGL core profile shading language version string: 3.30 
There are like 3 or 4 different fog implementations in engines and that sucks. 
Here Is A Video 
Here is a little bit of video that shows how looking down changes the appearance of the slime.

I'd like to add that I can simply set r_oldwater to 1 and not worry about this glitch at all. So please don't spend too much time on this as long as it is just my system which has this problem.

(I should know by now how to record windows without including the header bit, but I forgot to do it right again while making this one. Derp.) 
Thanks Primal 
I will have a look, I should be able to fire up ubuntu on a Haswell laptop. 
happens for me too, Ubuntu 14.10,
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.0 Mesa 10.3.0

Will poke around a bit more 
The problem seems to be mesa is choosing to use vertex fog, which it is allowed to do in OpenGL. I tried adding glHint(GL_FOG_HINT, GL_NICEST) but still get vertex fog.

The other half of the problem is, there's a water textured func_illusionary stretching across the whole map; water doesn't get cut up by qbsp, so there are two giant triangles. Since the corners of the triangles are so far away they get fogged to solid white. You can see the issue if you do r_drawworld 0, r_oldwater 0, r_showtris 1, and noclip up above the map. "r_oldwater 1" avoids the issue because it chops up the water surface into smaller triangles that look ok with vertex fog.

So there's not much we can really do... I was thinking of upgrading the fitzquake "r_oldwater 0" effect to glsl at some point, and that would fix the problem since we can force per-pixel fog in the shader. 
Thanks for looking at this, EricW. 
Anyone Here Aware Of Quakespasm Rift? 
cause I posted it on my quakeguy blog ;) 
Software Renderer 
So, i just downloaded Quakespasm source and i'm curious about the software renderer. Has it been removed? Is it possible to compile the engine without GL? 
Yep It's Removed 
QS is OpenGL only, which dates back to Fitzquake.

Check out Fitzquake Mark V which re-adds the software renderer to Fitzquake. 
@ericw ... when you modified how the map is drawn by removing DrawSequentialPoly, did you discover any side-effects? And did you fix them?

I recall someone saying something about alpha or sorting --- perhaps alpha entities or water in some odd situations could be wrong. 
I don't think there were any issues with the final version of the patch.. the overall draw order is the same as before (opaque entities, world water, transparent entities). Only real difference is, within a particular entity, instead of drawing the faces in the order from the bsp file, they're now sorted by texture.

Maybe it was mh or metlslime pointing out that fitz doesn't depth-sort all of the alpha surfaces. So in your example, fitz and qs should always draw transparent entities on top of water.. this will look wrong if you have a transparent window underwater, viewed from above. MH's engines do sort every transparent surface properly, I looked at that but it's a bit of work to set up.

I do have a test map for checking weird cases like water textured bmodels, fullbrights on transparent bmodels, alpha bmodels in water, etc. Was meaning to upload it but forgot about it. I'll dig it out and upload it tomorrow. 
Yeah, it's quite a bit of work to sort all the alpha surfaces properly and even more if you want to add sorting for other stuff like alpha MDLs, sprites, particles, etc. Particles in particular are a bitch; you need to add a second level of "emitters", "active_emitters" and "free_emitters", otherwise you're measuring distance and sorting for every individual particle.

I think the payoff is worth it but it's not something you can just drop in quickly. 
Of course even then intersecting surfaces won't work.

People have been asking for a programmable blend stage for years and programmable blending would go a long way towards proper per-fragment fast order-independent translucency. Being able to select between "src + (dst - src) * alpha" or "dst + (src - dst) * alpha" based on a depth comparison should do it. 
@Baker here you go:
It's a quoth map, it uses mapobject_custom to load an external bmodel (crates.bsp). There's lots of unusual stuff, I don't remember exactly but the .map is included. Make sure to play with different wateralpha values.

MH, yeah, I'd like to fix it in QS sometime. It's not really uncommon to have the issue show up in maps, either. The teleporter behind you at the start of telefragged.bsp is a good example, it's just a free-floating liquid brush, but QS draws the rear surface in front of the front one. 
Interesting, I'll check it out. 
Bbox Rotation 
What are people's thoughts on rotating bmodel bounding boxes when the "angles" field is set, as described in Baker's tutorial here:

This lets you do "real" rotating doors without setting up func_movewalls.
I had a request to add this feature to QS. As far as I know the only quake singleplayer map to need it is e3m3rq.bsp, from the rmqwinter11 demo.

Here are some pros/cons I thought of:

- strictly speaking, this is a breaking change. for example, in those maps that have a func_train with 'angles' set, (recall the offset elevators in add.bsp or apsp1.bsp), with fitz 0.85, only the visual part of the model is rotated, the bounding box is left in the original place the mapper put it. If you add bbox rotation to the engine, the bounding box is lined up with the visible part of the model. Both maps still seem playable with bbox rotation, but it's possible other content is broken.

- better for mappers than hipnotic rotation, no need for func_movewall
- possible to make rotating fans, etc, with no qc
- already implemented in many engines: mark V (only if you use sv_protocol 668), fte, darkplaces, quakeforge, qbism.
- IMO the chance of breaking existing content is small; because you could consider the fact that bboxes don't rotate in vanilla quake a bug, and it's unlikely that somone would deliberately have the physics bbox in one place and the visual part of a model rotated away from that.

Question for Baker, was there any compatibility reaason you left this disabled in protocol 666 in MarkV? 
Remember the apsp1 issue with an entity being rotated a little? With a rotation of -1 or something? It had something to do with that, but I can't remember off hand --- it might have been of the "an entity has a strange rotation, do we honor it or ignore?" So I chose to disable rotation until the feature gains some usage. But I haven't thought about this in a while, so my memory could be wrong but I wanted to err on the side of compatibility.

The reason for protocol 668 was for smooth rotation. Something like FitzQuake interpolations positions nice and smooth, but not angles.

But yes, I'd love to see rotation go into mainstream usage. 
Rotation -1 
This was an angle key of -1 on the entity signifying something meaningful to mappers; probably the direction in which a moving brush model should move, I can't recall exactly what, but it was valid usage in Quake.

This wasn't a problem in the original Quake because angle-to-byte quantization with truncation meant that the value was transmitted as 0.

In FitzQuake it became an issue because it used a Q_rint call for better rounding, and so the -1 value suddenly became visible on the client.

It was only ever an issue on the client; -1 was insignificant enough that on the server things were just off by a little.

It seems that it should be possible to detect these entities at load time and flag them for special handling in the edict_t struct.

Another, possibly bigger, thing to watch out for with rotated bboxes is that some of the maps have an angles key set; e3m3 is one example from ID1. Things go quite insane if you don't exclude the world from bbox rotation. 
I believe the cause of the -1 angles in those maps is a door that was converted to a plat or train, without deleting the angle key. For doors the -1 is meaningful and i think the quakec even zeroes it out after doing its special thing. For plats and trains the angle isn't used, which means the unnecessary key is left alone to cause this bug.

Otherwise you'd see weird angled stuff in every level in fitzquake because almost ever level has a vertical-moving door (angle -1 or -2) 
It'd Be Nice 
To have true rotation instead of the hacky method.

Maybe enable it as a default on variable so if some map or mod does rely on weird qc usage it can be turned off. 
The Problem With Cvar Controlled Stuff... that you're pushing the solution on to the player. 99% of the time the player won't take up the solution and then it's going to be your fault anyway. Deervedly so, because you didn't fix it proper nor proive a sensible default to begin with. 
But you choose the default that works with most old cases, and place the onus on new modders to choose the one that they want in their rc or whatever. 
Here is a zip

Do -game rotate, map rotate or map rotate2

There is an old Mark V in there "fitzquake_mark_4.exe" which has rotation working and under both 666 and 668.

Rotate2.bsp only works right under DarkPlaces, I'm not sure why and I swear that ages ago I had that working in engine tests. I don't think even the RMQ engine does that map right. Try DarkPlaces and you will be standing on rotating platform to see the correct behavior.

Try Rotate.bsp with the provided fitz under 666 and 668. Pay particular attention to shooting the "drawbridge" and standing on it when it raises and lowers with 666 and 668 and try DarkPlaces too doing the same. 
The Problem With Cvar Controlled Stuff... that you're pushing the solution on to the player. 99% of the time the player won't take up the solution and then it's going to be your fault anyway. Deervedly so, because you didn't fix it proper nor proive a sensible default to begin with

Haha :) Fix it proper for 1000 Q1 maps/mods ?
Sensible defaults vary according who to joe dick and harry are. Roughly - QS tries to provide sensible defaults and interface for the Average Joe, and *document* cvars, workarounds, etc, for more technical users/features. 
gb made a bbox rotation demo map back in 2010 that has a bit more stuff to play with:

It works well in the engine baker attached in #1508, or here is a test build of QS with rotation:

(sorry about the url..) 
Works great!

And in Quakespasm if I noclip onto the top of the rotate continuous it works fine with the rmq_rotate/rotatetest.bsp (and it works in the old Mark V I provided, so I'm not losing my mind that standing on top of a rotator works fine in a correctly compiled decent .bsp)

[Perhaps my rotate2.bsp in is "wrong" or the map compiler used (unknown what it was) did a poor job.

I've not thought much about rotation in quite some time ...] 
Quakespasm 0.90.1 Released 
Thanks Oz and Eric 
Thank You Again 
Thank you guys for all your hard work on this. It really is appreciated by those of us who enjoy playing Quake. The new games have _nothing_ on the classics. 
A Rendering Glitch? 
hi all!
thanks for the new version of the engine!

found this visual glitch with the teleporter and the secret door on the start map of 'contract revoked' pack:

i was using 0.90.1 windows version, seems to happen on both x32 and x64 executables. doesn't happen with quakespasm 0.90.0. graphics card is nvidia gtx 550 ti with recent drivers. 
thanks for the report. Was trying to be clever and sort the bmodels by texture to gain a bit of performance, but it breaks that scene.

I guess the entities were ordered in the bsp file so that the teleporter entitiy would draw after the bookshelf. 
Weird Fog Issue 
I've noticed some rendering issues with certain models and fog in the map: 
Feature Request: Write stdout so that it is line-buffered or unbuffered or something. This would allow grepping the output and have the Quake Injector's engine output log update while playing.

Darkplaces does this well, no idea about other engines. 
Animated Texture Question 
In Jackhammer textures animate depending on which is their assigned frame. So you can do an animation that looks cascading inside of the JH viewport (for example with having a bunch of brushes with slip textures with increasing framenumbers.)

This looks pretty cool, but it seems this is not the way the engine handles things, since they all seem to start at +0. This is kinda lame (esp seeing as in Doom having them at different frame offsets is possible. Step back :|)

Would there be a way to implement this easily somehow? r_animtexoffset maybe? 
Duplicate the textures and offset them by hand. 
Well yeah, that is the obvious hack. Have the same textures a whole bunch of time with different offsets. Would be nice if it was possible in a non-stupid way :/ 
Stupid Is As Stupid Does 
Why not just offset the UVs on the brush? 
How would that help with which animation frame is played? 
It Wouldn't 
But it could help hide the fact they're all marching in unison, depending on how tall each brush is.

If you have large flat wall, it's always going to be visible. however, if you break the wall up into steps or multiple slopes and have the liquid flow over each one, this will also help hide the repetition.

Especially if you scale the textures as they 'flow' over the different angles to give them different flow speed. You will get some misalignment between brushes doing that.

If you do want them to move at different speeds (even though physics don't do that) you can just scale the textures on each of your flat brushes. A minor range of variation, say between 0.9-1.1 in Y. 
I think you misunderstood me slightly. As in what I wanted to do.

Imagine a slipgate with that animated red grate texture, +0slip and following.

Imagine now you want to have 4 of these grates next to each other, but starting at different frames, +0slip, +1slip and so on. That would give a nice effect of the pulse going through the machine, not all as once, but flowing through it.

But the animation does always start on +0 no matter which frame you actually put on a brush.

So you would actually have to duplicate the brush and change the frames so that +1slip in the new animation becomes something like +0slip2. pita. 
I don't really see any reason why this wouldn't be possible in-engine, but I'm trying to think of how it could possibly break compatibility with other content. A cvar isn't the answer because that other content might be in the same map. 
The simplest solution would be a variable which starts animations at the frames which is actually set on any given brushface. Of course this depends on how stuff is handled by the compiler? Does the compiler by any chance set all animation textures to +0?

But if that was possible something like r_textureanimframeoffset 1 or something would work well enough. 
I think the way to do this right now is changing the texture names to suit your needs. There's no way of staggering the start points of the animation cycle. 
Yeah, simple but kinda dumb way of doing it is duplicating the texture a bunch of times with different offsets. I really wonder why they did it like this in Quake when it works fine in Doom :/ 
have you tried it in software quake? It might actually work there and just be broken in all GL-based ports. 
hmmmmmmmmmmmmmmmmmmmmmmmm. Trying now. will report back in a bit. 
Tried in Winquake and original DOS Quake.exe 1.08. Same behaviour. 
ah well. I think you should just duplicate the textures and be done with it. 
Yeah, that's what I will do when I wanna do something like this, which I likely will at some point. 
Weird Bug. Engine Or Map Related? 
I just played a bit of A Desert Dusk in QS and at some point I got a weird bug. My axe was replaced with what looks like a scorpion stinger or something and all my other weapons could not be used until I found more ammo for them.

Link to demo, sadly not from start: 
Little Idea, But Would Have To Be Coordinated With Other Engine Makers 
func_water, func_lava and slime as well, so you can make something with a different texture have lava properties as well, without having to do hacky shit. But I reckon such a feature would lead to between-engine-headaches. 
func_water, func_lava and slime as well, so you can make something with a different texture have lava properties as well, without having to do hacky shit. But I reckon such a feature would lead to between-engine-headaches.

This isn't determined by the engine, it's determined by the BSP compiler.

The only thing that the engine does is identify surfaces who's texture starts with "*" and draws them with the turbulent warp effect. But contents are already set during BSP compilation, so any changes would need to be made there. 
Ah, that makes sense. 
It Also Means... 
...that if a BSP compiler was modified to support this, then all engines would automatically pick it up without any headache or grief. 
Can't Suicide -- Allready Dead! 
^ typo. Looks like many engines have it, at least Tyr too."Can%27t+suicide+--+allready+dead!" 
more important than moving lava imo 
Seems To Have Been A Recurring Problem.. 
Was Wondering... 
The alpha variable is pretty cool, but alpha always has the sorting issue, as we all know.

It would be pretty cool if there were also vars for additive and subtractive blending. Of course they should be mutually exclusive, but I think some cool stuff could be done with those, and they do not suffer from any sorting problems, from what I know. 
If you want to go that far, tbh you should use something the supports Q3 maps, and just use shaders. 
Darkplaces Is Also An Option For Q1 Bsp 
There is a sort of simplified shader support in darkplaces. While it is not as powerful as doom3 or anything, it is close to q3 except for some limitations and you can still use q1 bsp format.

It's all done with text files just like q3 and is pretty easy to set up. You can get some pretty wild stuff with it too: 
Scampie: how is a bit of additive blending going further than alpha, skyboxes or coloured light. It really is not. And it is one of those effects which could add to the atmosphere of a map but still feeling like Quake, which the stuff that necros linked, while looking neat, decidedly do not. That water does not mesh with Quake at all, imo. 
But it's even nearest neighbor! 
Lol, no it's not. :P 
For some reason putting demos in mod folders does not seem to work. Quakespasm does not list them nor does it play them if I manually enter their name. Only stuff in id1 gets recognised even if I am playing something out of another folder. Is this intended? 
they do work in mod folders. double check where you put the files, i guess? 
I originally downloaded mapjam6 and put it in a folder called func_mapjam6. And then later downloaded it from quaddicted via Quake Injector. Which has it inconsistently named mapjam6 *shakes fist* So that is where the problem came from. 
Don't You Dare Blame Us. 
The zip is, the readme tells us to use jam6/ but is called func_mapjam6_readme.txt.

I hate this job. 
what you really need is something like those elder scrolls loaders where authors include the metadata. :P 
I Wish! 
Quaddicted does not have enough traction though plus there is 19 years of baggage. 
Well, all the other jams went into func_mapjam# folders. But I guess you can blame Daz, lol. 
It Really Doesn't Matter 
Everything has to be in perfect order! EINS, ZWEI, EINS, ZWEI! 
Additive Blending... 
...doesn't need depth sorting but it does need content designed to work with it. It's not enough to just ask for vars to support it.

Don't underestimate the power of 19 years worth of inertia. It's not enough to just ask for a feature in a manner that shows you haven't even thought through the implications of it.

The best way to resolve blending issues that require depth sorting is to just add depth sorting. It's not hugely complex but it does involve quite a bit of work. I'm sure it's on the QS guy's radar but asking for it more and more isn't gonna help it be done faster. 
Of course I know that additive blending needs specific content to be made for it. Most of the stuff in Quake already would not work that well with just slapping that on top of it.

But it is not really hard to make some textures and things that work really well with it, as shown by some Doom maps for engines that support it. 
Learn To Code? 
If Days Had 48 Hours, Maybe... 
I know how to do some scripting and such. But yeah. Don't really have time for that atm. 
Relative Path Support 
Would it be very cumbersome to implement starting the engine via relative paths? Right now, the .EXE will return the error message in the screenshot below (I have a faint recollection of seeing the same msg in GLQuake back in the day, not sure tho).

I tend to get myself doing lots of stuff in Windows CLI these days, including compiling my never ending stream of "test maps" :D 
Addendum To The Above 
Not sure if relevant, but I'm running the latest SDL2 build from ericw's repository (

Quake Version 1.09
QuakeSpasm Version 0.91.0
Exe: 10:39:47 Aug 23 2015 
Where is the id1 folder relative to the retrojam folder? Pretty sure those have to be at the same depth. 
They are at the same depth. But your comment prompted me to try and lauch the engine with NO command line parameters (which I haven't tried before), and interestingly enough, this time it returned a different, and a somewhat more creepy, error msg:

(sorry for any possible english mistakes) 
Check out the -basedir parameter. 
-basedir FTW! 
Holy crap, -basedir is the solution:

All of the above worked flawlessly!

Thanks a lot Spirit haha, I now remember using|seeing this cmd line parameter *way* back... damn 15yo memories! 
For Reference 
... this screenshot shows the "cmdline" cvar for the above two examples, in order.

Just in case it might be useful for someone in the future. 
-basedir might choke on paths with spaces in them. 
If you make sure to quote the path argument, paths-with-spaces works for Quakespasm IIRC.

Last time I checked, basedir support was generally missing in Fodquake, DirectQ, and Qrack. It was broken on paths-containing-spaces for Engoo and Super 8. 
From working at a bookshop and often punching in EAN's I can say: Finally an engine where typing from the numpad works!!

Here's hoping more engines follow this example. 
No Spawn Function For Func_dm_only 
I'm trying to set my jam 6 level for deathmatch. Navigation would improve with some teleports. Then I found this entity func_dm_only, a teleporter for deathmatch only. But standard id1 doesn't seem to have it and I get a "no spawn function for" console message.

Any ideas? I believe id1 progs.dat should have this entity... 
Sorry!!! Wrong Thread! 
Recolored Texture/skin Bug 
Arghh, QS 0.90.1 has a bug where a random texture or skin gets shifted colors after a video mode change. ("map start", change video mode, "map e1m2" and you will have a gray shotgun).

I'm working on a fix for it 
must be on certain gfx cards as it doesn't happen to me. 
I had this happen to me as well where sometimes I got a red shotgun. 
That's a rare drop.

You can combine it with the red super-shotgun to make a level one tri-barrel. 
Only If 
You have the first and third rune though.

Having any of the others just summons the dopefish. 
The bug was running the shirt/pants recoloring code on a random texture. There's a bug report with more details.. I put in a workaround (hopefully) last night.

The latest dev build with the fix is here if anyone wants to try it. 
It's Early And I'm Still A Bit Drunk 
So you can imagine what I misread shirt/pants recoloring code as 
It's like Quake 2's damage skins - as scary things transpire, brown patches appear on one's trousers. 
That Was 
A RMQ feature, but it got bugger and went to /bed. 
SDL2 Build Issue 
hi again, found an issue with the sdl2 builds, both stable and dev. every time i start the engine in fullscreen mode with resolution lower than native, the screen flickers terribly as if half of the frames are dropped. it goes back to normal if i vid_restart or alt-tab. native resolution works fine, as well as windowed and borderless fullscreen modes. that doesn't affect sdl builds. graphics card is nvidia. 
Reproduced that right away on 0.90.1 launching with "-width 1920 -height 1080 -fullscreen" on Windows 10. Will investigate it..
It seems fine if you switch within the video menu. 
I think I fixed it, there is a dev build here 
Oh Ok 
i had switched from the video menu. 
R_pos 1 
Dynamic position info, aka r_speeds + viewpos , in svn. Maybe this is useful ? Feel free to modify. 
Issues (0.90.1) 
>cannot see menu after alt-tab out to desktop from the menu (no map loaded)

>R_novis 1: models, doors and sprites are not visible looking into the water, and while submerged looking out

>sometimes can get stuck going down/up ramps/angled brushes, touching obtuse (convex) corners

>committing suicide with a thunderbolt in fluid without gibbing prevents respawning

*Read files directly from the folder, so user can drag & drop models/sounds etc

*r_telealpha, r_lavaalpha, r_slimealpha; those commands dont exist and r_wateralpha affects all fluids 
for 1) not sure what's happening, could you post a screenshot?
2) that needs a new sv_novis feature. agree that would be useful to have.
3) not sure if we can do much. you can try lowering host_maxfps to 60 from 72.
4) not sure.

1) I think you're noticing that assets in a pak file have higher precedence than loose files. we can't change it at this point, best bet is to put new assets in a mod folder like quake/mymod/progs/xxx.mdl, then they will override id1 assets when you launch with -game mymod
2) lavaalpha etc. are in the nightly builds 
Quote "sometimes can get stuck going down/up ramps/angled brushes, touching obtuse (convex) corners"

Actually, this could be a problem in the map. Small invisible walls that stop normal movement over what looks like a smooth surface can be caused by CutNodePortals_r warnings during the bsp process not being fixed. 
I thought that was a common hull expansion bug caused by silly old trigonometry 
never mind the comment about host_maxfps, I was thinking about the bug where elevators sometimes hurt you. 
Could just be a coincidence, because I've gotten invisible walls without having any errors or warnings during compile and I've had CutNodePortals warnings that didn't cause invisible walls.

But many times I have run into invisible walls exactly where the compiler said there was a CutNodePortals problem.

Either way, I don't think it's a problem specific to Quakespasm. 
CutNodePortals sounds more like something to do with visibility. Any engine folks have any info? 
It's a QBSP warning, I don't recall ever seeing it during VIS. It's generated during the hull building phase I think.

I got tons of them while working on my Jam 6 map, but I fixed all but one. It was outside the playable area, which didn't make much sense to me, so I figured it wasn't worth worrying about. 
Rick - Yes, I've gotten invisible walls and clipping problems in cleanly compiled maps as well. Quake is old and crotchety... 
Some collision issues are the result of bugs in the qbsp code that expands brushes for the clipping hulls. I believe Aguirre or tyrann fixed some if those bugs in their versions of the tools a few years ago. Not sure if there are still such bugs in the current tools. 
I still get clipping issues like the one described above and I am sure I am running the latest stable release that ericw put out 
Md3 Support? 
Just wondering if this has been considered as an addition to this engine? I'm more looking for the ability to have higher vertex precision than anything else because MDL can be rather brutal if you try to add any subtle details on large meshes. Pointy teeth on a shambler would be an example... I've seen a few other now dead Q1 engine updates that added MD3 support to their builds but those are dead and unsupported developments unlike the lovely Quake Spasm. 
Was Just Talking About This 
in the custom engine thread.

I for one would be over the moon if QS supported md3. Once you start adding long swords and stuff to monsters and big swinging attacks, the .mdl format becomes a real problem. 
But Yeah 
backward compatibility is a real issue. the whole point of .md3 is to do stuff that would look terrible in .mdl, so there's not really a decent option to fall back on.

I'm inclined to start thinking about composite models as a way to workaround the mdl vertex butchery, but I imagine that's another big can of worms. 
Swords Eh 
Reasons? :) 
I am all for textures with no filtering and even playing at 10fps for the models with or without interpolation... but integer precision is inexcusable in this day and age regardless. Its just unsightly jitters. We support colored lights for that reason. Sure some folks will make a disco map but these features allow for folks that know what their doing the little bit of extra flexibility.

Besides if folks want to keep the oldschool look for their monsters or create them to work with MDL then feel free. I would prefer to not see vertex swimming on my subtle idle animation that has spikes on the back or toothy maw. 
MDL Limits That Suck 
The biggest issue I have is with the vertex precision dropping indeed with bigger models or making animations that take up a bigger volume for limited frames in your models animation frames. Because MDL takes those ranges as the maximum and then scales up the volume of detail that everything else gets. So either you stick to small critters or big creatures with limited range of motion to avoid losing detail. 
When it's just certain animations use a large bounds (eg an attack animation) it can be worth outputting those anims as a separate mdl file and swapping as appropriate in qc. That way your model doesn't get totally trashed because of that one time where he swings his weapon around. 
Hacks I Say... 
That sounds like even more annoying hackery than simply supporting a better mesh format... :) 
"Simply" means getting all engine authors on board with the same standard. So, good luck with that. 
I think it would be nice to have the support for it but I really doubt it will be used by most modders. 
Yeah, there are ways to improve the situation a little in the absence of .md3 support, and I think QuakeC "hacks" - such as making a monster from two .mdls stuck to each other (e.g. Armagon), or switching to a different .mdl for certain problematic animation sequences - are less of an undertaking than getting coders to write .md3 support into the engines. 
It's not that difficult. Engine guys love making stuff, you just approach one and ask if he'd be interested in supporting the model you've made. Or even write in the change yourself to a QS fork.

Once it exists, it exists and will get adopted. Same as with any other feature - skyboxes, coloured lights, BSP2 etc. 
I find your optimism appealing and look forward to feasting on it's burnt husk in the future. 
I begged for higher res shadows and .lit2 came and seemingly passed with no real outcome. 
I thought with .lit2 everyone wanted it and then after looking at the actual results we all went "err can you make it blurrier? A bit blurrier still? Actually on second thoughts I'm happy with Quake's original look I guess". 
MD3 Support Already In Other Engine Builds? 
Not sure how interchangeable the render between quake 1 and 2 are... but I know KMquake engine supports MD3 as a mesh format to use. I for one would LOVE the support of the MD3 format or IQM whichever one is added to the engine builds.

On another note has anyone thought about portal skyboxes like in the original unreal engine? :) That would be fun to build skybox areas that become the levels distant views but with some parallax. 
I would love unreal style portal skyboxes. If that happens though I think alpha on masked textures needs fixing. Currently if you have an index 255 masked { texture it will only alpha as low as .7 I believe. This would need fixing in the main engines.

Also, will someone tell LordHavoc to added masked textures to DP? 
It was the RMQ that first got the ball rolling with fence textures and 2PSB (BSP2).

It's not so much optimism as - if you do it, it will happen, I know because this is how it has happened before when I was involved with feature XYZ.

Complaining that it won't happen because nobody will do it is a self-fulfilling prophecy. 
Bringing back the stencil style of the old quake sky but make it an actual skybox would be awesome. 
ijed - Sure. Awesome. I mean, I'm pessimistic on a new model format being adopted by all engines and people actually using it but I'm happy to be surprised. Go forth. 
I'm Busy 
We Need Md3 Models First, Then The Engines Will Follow 
I'm sure if someone started making a mod that uses .md3 content (I mean you can already use md3 in Darkplaces and a couple of other engines), then I can see Quakespasm following.

It's just nobody is currently making quake stuff with .md3 content so there isn't a demand for it.

People saying how much they'd like md3 is one thing.

But if you can say "I have a mod. It uses md3 and plays in Darkplaces but wouldn't it be great if it played in Quakespasm also?", then that's another thing entirely. 
How To Make Feature Requests Work! 
Demonstrate a real, working example of a problem that the feature request solves. In the case of BSP2 it was created to solve a map that blew right through the clipnodes limit. The map existed, it was there, it could be loaded in an editor, but it wouldn't compile or load in an engine.

It's not good enough to say things like "has anyone thought about" or "it would be fun to build" or whatever. It's easy to forget that a feature requires work to implement, and that sometimes it may not be nicely compatible with other engine features. The feature may end up being cool or fun, but would anybody ever actually use it? To quote from john Carmack's .plan file from 1997:

Sure, any given feature list can be implemented, given enough coding time. But in addition to coming out late, you will usually wind up with a codebase that is so fragile that new ideas that should be dead-simple wind up taking longer and longer to work into the tangled existing web.

The trick is to pick the features that don't fight each other. The problem is that the feature that you pass on will allways be SOMEONE's pet feature, and they will think you are cruel and uncaring, and say nasty things about you.

That's as true today as it was back then.

A good rule of thumb is that if you're asking an engine coder to invest time and effort into implementing a feature, then you should be prepared to show that you've invested time and effort into thinking about the request to begin with. 
"wot Kinn said", in other words. 
MD3s In The Works :) 
I was asking because my shambler remake has nice teeth and Mdl makes it a gibbering mess. Not to mention more subtle muscle details and form that get all garbled by the MDL format as well. Its been driving me a little nuts. I like Quakespasm. Have not used Darkplaces yet so I guess I will test it there for now? No normalmaps though :P Don't care for normals on my retro art remakes.

Starting to paint this guy up now finally :P 
Pls Remember 
Shamblers are furry!

Looks like you're off to a great start though!

I agree with Kinn/mh. I would say that there is already a fine case for having md3 models as the limits of mdl are plain and clear to anyone with eyes. The problem I think is that the standard mdl models are good enough as is and people still are making great quality mdl assets.

It's definitely a "would be nice" feature right now. 
the standard mdl models are good enough

Allow me to disagree.

Stock Q1 monsters look like baloon animals. 
In modern vanilla like QuakeSpasm you can push level art way further than mdl characters. I believe this is the problem md3 would solve. 
What About Fiends?! 
clear to anyone with eyes 
Stock Q1 monsters look like baloon animals.

I'm more worried about the guns - 
Stock Q1 monsters look like baloon animals.

I'm more worried about the guns - 
I have no idea who's responsible for whatever's on that screen, but they should be banned from using a computer. 
looks like someone put meshsmooth into the engine???? 
My Eyes!! 
Yeah that screenshot's like a bingo card of terrible programmer art "enhancements":

Ultra-hi-res replacement textures? Check.

Replacement textures look like they were made with Gaussian Noise?Check.

Parallax mapping on textures dialled to 11? Check.

And so on... 
JoeQuake 0.15 has an implementation of MD3 that mere mortal engine coders could work with. source

But the MD3 implementation in JoeQuake is different than DarkPlaces or FTE.

There are also several outstanding questions like how to communicate eye position?, spinning (unless you don't care if ground weapons work), blood trails, frame groups? and the other flags/info in .mdl not present .md3. And where the texture go, which should be the folder the model is in but I don't think DarkPlaces does that. And how will you colormap the textures or do you just say to hell with it.

Then you have the idea that the implementation should be compatible with DarkPlaces, which could be awkward because you might be talking effectsinfo.txt (name?) to have compatibility for the extra flags.

Then you have the the idea of what MD3 extra features will or won't be supported. Shaders? Alpha?

But JoeQuake has an implementation. Does it work with monsters? Tea Monster MD3 ogre

/Extra info.

If there is *serious* demand for MD3, someone should see if the MD3 implementation in JoeQuake works with monsters and find out how hard it is to make it work. Or even make a prototype for DarkPlaces. Did Spirit's engine inherit MD3 support from JoeQuake?

If people aren't willing to do that, the Quakespasm team has an empty bag of test case scenarios.

/One opinion maybe even wrong. 
Keep in mind, Quakespasm doesn't even support external textures for monsters! Which is more of pain than it should be in a FitzQuake engine because of gl_mesh.c

[Mark V does, another case of great code being available for the taking! Some of it being due to some great tips from MH.] 
For Science I Say! 
I'll have to give that engine a look I guess. Never heard of it till now. Alpha Key would be a cool feature to support at least. I don't mind making textures look classic quake in palette or at least heavily reduced colors either to fit in with the games look. I would still be down with some shader support down the line like glow textures but for now MD3 on its own would be cool.

For model info like blood trails or spinning maybe include a text file with the same name as the MD3 with some prefix or suffix to include some flags? In the end I just want more vertex precision that is all or IQM for bones still running at 10fps so the game logic does not get borked. 
Yeah - I actually love the crunchily pixellated skins and chunkily low polycounts on the monsters; the vertex swimming is the only thing that could do with being corrected really, as there's no way that can be seen as a desirable artistic look by any sane person.

Eye-candy "creep" isn't really my thing, but fixing obviously bad things about the current look is cool. 
Why not have the md3 act as an extension for the mdl?
If there's a flappy.mdl, get all metadata from that, and then load the actual data from the flappy.md3 if it exists.
Kinda how lit files work.
Progs.dat refers to the mdl.
Trying to load a md3 without a mdl being present should be an error.
As I understand it there are already tools that convert md3 to mdl, so for content that has been explicitly crafted as md3 it shouldn't be too much work to convert it to a craptastic mdl that people running a good engine won't see anyway.

Though I have zero knowledge of the md3 format, so I dunno if there's some obvious obstacle.
The progs will have to be able to treat whatever new format as if it was a mdl anyway. 
Czg Is Spot On 
I think if the md3 is present it should load that instead of the .mdl kind of like how texture replacements and lit files work.
But it should be a requirement for the .mdl to still be present.

Also Skiff, I hope you're aiming for the lo-fi cabnbubs implementation of your shambler model. It should still fit in with the Quake roster of monsters. 
i like it, do it that way! 
Yes I Like 
what czg said 
We'll See 
In the end the shambler I am making will be a more modern take on it. BUT if I do get this one done then I could make a more "true" to the original version for folks to enjoy... but seriously the old shambler is origami... its 200 triangles... the dog is almost 600 ha. I have no idea what went on in their heads when making that guy. 
MDL Requirement 
Yea I like this implementation. MDL as a base with all the proper info and MD3 for more precise updated visuals... 
# of triangles is irrelevant. there was enough there to convey the shape of the monster.

it's a very efficient model and well constructed. 
I have no idea what went on in their heads when making that guy.

Every poly saved was a win back then. Also I imagine the 'bler was one of the early models, like the knight. Later on they had optimised the engine enough to allow for 400-600 poly characters like hellknights and dogs, but I guess no-one deemed it worth remaking the shambler. 
Necros Come Now Seriously? 
I will let that one pass because I do this for a living. Quake got me hooked on modding and game development after all when it came out.

I do agree with Kinn that it was most likely one of the first things and never got updated. Any game with a consistent art standard would not give a tiny dog enemy over 500 triangles and then 200 triangles for what is effectively an end game boss monster.

We love the shambler for its size, soundscape and evilness. It could have done with better construction and for dang sure better rigging back then though :P 
Quake originally ran in 8-bit and 320x200. At that resolution it truly makes no difference whether there are 200 or 2000 triangles on a model. 
But now we try to enjoy it with a little more detail... just a little bit. 
is the implication in your reply that the shambler is a bad model? not sure how you can come to that conclusion. with 200 triangles, it would be difficult to make a convincing model like the shambler. i am judging the model based on 1997 as that is when it was made. i guess you are judging it on 2015 standards, which is not really fair. 
There's also the disparity in triangle counts. The dog gets 600 while the shambler gets 200? I think it definitely smells like a case of the shambler got done first and the dog was done later ... and there was no time to re-visit the shambler. 
Mandatory Mdl 
So, if I make an md3 I would still bother learning mdl stuff? MD3 is not an industry standard outside Quake world, right? So I would have to learn the tricks of two proprietary vintage model formats? Correct me if I'm wrong, please.

If my model's mdl version is just boilerplate, it would be... more boilerplate to care about. If I have to craft an mdl it would double my work, I would have to model for two formats, my monster would still have to look and work decent in mdl. 
.mdl is about as hard as downloading preach's md3->mdl converter I think.

I may be missing something, so others please jump in. 
it's really that simple. 3d app -> mdl involves md3 so you just keep doing the same thing. 
Playing Devil's Advocate 
The issue of md3 backwards-compatibility would present a unique - and possibly quite annoying - quandary, because the more you make use of the capabilities of md3, the worse the fallback mdl is going to look.

Do you not care that a certain percentage of players will witness your awesome tentacle boss monster in the form of a horribly mangled soup of quivering triangles?

Do you purposely constrain your design so that the mdl will still look "ok"?

I think I'd take the latter approach because the thought of it looking terrible in certain engines would grind my goat a bit. But this approach does undermine the whole idea, I will admit. 
How will darkplaces deal with this md3 + mdl model you're planning? 
Progressive Enhancement 
Do you purposely constrain your design so that the mdl will still look "ok"?

I wrote this article a while back and I think some of it would relate to MD3 upgrading MDL

The most successfully adopted features across all engines, like fog, skyboxes, external textures and alpha, all exhibit some echo of progressive enhancement, so I think it's a pattern to bear in mind. 
That is very sensible and sound. I agree. 
If I recall, DarkPlaces uses .mdl as the file name.

And then it checks the first few bytes of the file with the name "solider.mdl" for the word "IDP3" to see if it is MD3 (or some other model format). 
With Precedent 
In standard quake engines, whether something is loaded as a mdl, bsp or spr is always determined by the header, never by the file extension. In theory you can use any extension you like for anything!

But the scheme that plans to rename an md3 file with a .mdl extension does fail to have any level of backwards compatibility. Something a bit more along the line of...


...where precaching "progs/cultist.mdl" will first try to find "progs/cultist.mdl.md3" and load that as a substitute if it's available, would work a lot better. A bit like how .lit is a separate file with a name-matching convention, so it doesn't affect old engines but takes effect automatically in new ones. 
I Want A Cultist Model... 
I want a cultist model now! 
I really should go back and revisit this chap someday...

He needs a quality pass on the skin and a completed set of animations though so may take a while. 
What Warren Said 
As I said before and Warren pointed out again... Shambler 200 triangles... Dog 600 triangles... smells suspect to say the least. I think we can all agree that the shambler was a little light back in the day. Now on a pure quality standpoint I found the rigging to be a sad sight with how it deformed back then even. But that is a discussion for another day. :) 
Give him a pump-action shotgun and some blade legs instead! 
They didn't have rigging at first. Kevin Cloud had to do at least some of that animation pose by pose by moving verts.

I don't know what software they used, but the original tools all only parsed Alias .TRI files, so whatever Alias's 3D package was at the time. Advanced Visualizer, maybe?

anyway, off topic 
Well not much excuse for bad rigging even in 1996. Soft skinning was already supported in various art packages like Maya, Softimage and hell even 3ds DOS with an early version of bones pro. Yea off topic. crazy how just improvement in the art tool pipeline can upgrade old games without changing the underlying systems. 
I'm having some fun writing some GLSL shaders effects lately and i wanted to know how to apply them into QuakeSpasm. Small and fun things like Nightvision, B&W, etc. Where i can find docs on the subject? 
Dunno, but make sure you write a shader that makes it look like software quake. 
is right... the software mode would be neat. Also make sure you get the terrible z-plane texture wobbliness. 
Making the large models (like shambler) just disappear if they get too close to the edges of the screen would be sweeeeet. 
Some glitches can be left to the past. 
You could hack the gamma shader, which postprocesses the entire screen just before displaying it. See:
Just make sure to set your gamma cvar to something other than 1, otherwise the shader isn't used. 
Re: #1674 
That bug was actually in glquake too. 
Indeed It Was 
Anyway, obviously I was being sarcastic, Skiffy.

I do however think the 8-bit colours of software Quake is a feature worth emulating if possible as an option. It's one of those things that really defined the look of Quake for me. 
When you had to imagine what was going on between those fat pixels being splattered across the screen.

HD takes that away and sends you into a vegetative state. 
cl_maxfps Doesnt works in Qspasm right ? Any tip to get my quake1 running at more than 70 fps ? 
Change the max fps limit to number LIMIT with this command:

host_maxfps LIMIT

Show the result on screen:

scr_showfps 1

Since you are already running at around 70 fps, you won't need to mess with vsync. The command for it is vid_vsync if you do need to. 
there's host_maxfps, but unfortunately going over 72fps can break physics (you get stuck on slopes, etc.) 
I realize this is a pretty trivial thing, but the default Quakespasm icon is almost invisible against a dark (black) Windows desktop. Maybe a second one could be added that shows up better if a desktop shortcut is created. 
8bit rendering would be a nice addition to emulate that is for sure. I don't know if there is a quake engine that supports it but I would love shadows on water. And has anyone considered expanding lighting to have ambient cube maps to capture light volumes instead of just sampling the bottom pixel under a monster? 
I don't know if there is a quake engine that supports it but I would love shadows on water.

This was discussed a while ago and no-one could agree on what these shadows should look like.

In my current map I've just gone "sod it" and literally made the fullbright water emit a little bit of light using the new surface light feature in eric's tyrutils. It's magic glowing water I guess. Looks not bad actually. 
Kinn - I too have embraced glowing water. Works pretty well, plus the area under the water gets lit for basically free. 
I was surprised how ok it looks. 
<czg> have a water-looking texture but it's actually lava
<czg> have blue lava. ths is new and pioneering!
Blue Lava 
is rather innovative 
Blue Lava 
rocks ! 
Makes sense since light hitting the surface would be reflected upwards and diffused by the ripples. 
Screenshot plz 
Meh, it's just a bunch of unfinished brushwork and crap placeholder texturing. 
"I don't know if there is a quake engine that supports it but I would love shadows on water.

This was discussed a while ago and no-one could agree on what these shadows should look like."

Retroquad does support it. Here's a bunch of screenshots: 
I like the look of that ALOT. 
No Idea How That Works 
But QS needs that desperately. 
That Is Nice 
And the software look lends an extra special cachet to any engine. 
Oh Wait 
It is a software engine. Impressive. 
Quoth supports loading any model for an entity, including .bsps, which is very useful in situations where the lighting doesn't matter (stained glass windows) but stencil alpha with a { texture doesn't work on a bmodel if it's loaded this way, only if it's built in the map itself. :(

Currently if you have an index 255 masked { texture it will only alpha as low as .7 I believe.

I can confirm this too - spiderwebs and the like below .alpha 0.7 just don't draw. 
Thanks For The Report 
will try to fix those. Weird that { textures would not work on external .bsp's, but I imagine it is something easy.

I think I know why entity alpha < 0.7 makes the whole fence texture disappear; normally the alpha test value in Fitzquake is left at 0.666, but I think I just need to lower it to (entity alpha * 0.666). 
There's only one alpha value, and you can't use it for both alpha testing/masking(NOT stencils! /me shudders) and alpha blending at the same time... well, you can, but the results are generally wrong.
glsl would allow it by doing any .alpha transparency stuff after the texture-only alpha test.
on the plus side, you might be able to get some funky burn-away effects.
also, its 0.667 and not 0.7. close enough though, but hey, precision!
but yeah... the exact details are very engine-specific, so try not to depend upon stuff too precisely. 
I think the reason the alpha test threshold is 0.666 in glquake is that 0.5 makes the explosion sprite edges look blocky/pixelated even with bilinear filtering (i know this because i tried changing it to 0.5 once), while 0.666 creates a more rounded appearance on the edges. Since that is the most visible sprite in stock quake, i believe they chose that number because they liked the explosion sprite edges to be more rounded. 
In that base map you tested the other day were breakable models(bsp) with {textures on them and they showed up rendered correctly (the unfair breakable grates on the floor).
Dunno if this is on topic, as no alpha is set on those. 
> i believe they chose that number because they liked the explosion sprite edges to be more rounded.

Also because 666 haha. 
Actually, Lunaran 
I'm having trouble reproducing the { textures not working on external bsp's, they seem to work for me. Mind trying this test case I made? just load fencetest.bsp in Quoth. It loads the fencebmodel.bsp with a mapobject_custom; you should see a box in the room with a metal grill texture. 
ericw, you aren't wrong, I am.

I always make sure to do my due diligence and create a side-by-side test case before ever involving a programmer, which I did: I had a func_whatever pulling from another bsp and a func_whatever in the map next to each other, with one alphatesting properly and one not. But, I got caught out by the external bsp having a stale texture, with whatever color in the Quake palette that looks exactly like index 255 but isn't. I discovered that error in the wad while tracking down this one, and forgot I had to recompile the external bsp to refresh the textures in it. :( sorry guys. everything actually works fine. (except that 0.7 thing, that's totally a thing still I swear)

Is it specifically because of alpha-tested matte lines in linear texture modes that they picked a color for the transparent index that's so damn similar to a lot of the rest of the palette, and not like hot component pink or something? (Doom used cyan iirc) 
no worries! Yeah, the alpha 0.666 thing is real and I will have a shot at fixing it sometime.

Your theory sounds right.. with stock glquake using linear filtering, you can see the "index 255 beige" fringes on the main menu text. They probably foresaw that and made index 255 a fairly neutral color.

Fitzquake has a cool trick for eliminating those fringes: for any index 255 pixels which have opaque neighbours, it gives them an alpha of 0, but changes the RGB values to an average of the opaque neighbours's colours (iirc). 
hmm, i doubt that they picked the transparent color in the palette based on glquake's bilinear filtering, since the game shipped before glquake was started. (Unless they actually attempted a hardware accelerated version before the original game actually shipped? That would be news to me.) 
^ Yeah, that's what I figured, but my angry head rant was "christ, it's like they picked an alpha color based on the average of all the others or something. ... wait a minute." 
Quake's alpha color is just a random color, and there's a duplicate of it in the default palette (which annoys me, because several custom textures used the index 255 instead of the index of the duplicate, and this gives problems with alphamasked texture support).

There were no 3D hardware accelerators when Quake was released. It was created with only the software renderer in mind, which is why it loses some of its charm when rendered through hardware.
Carmack coded GLQuake in a weekend, and he certainly would've done a lot better if he had the opportunity before.

The first Id Software game made with hardware acceleration in mind is Quake 2. 
I never saw those Retroquad screenshots before. They are amazing. You managed to push that water towards modern standards without losing Quake original charm. Way to go, man. Quake water needed this love. 
Besides those screenshots however I can't seem to find more info about it. 
(Sorry in advance for hijacking Quakespasm's thread.)

The only place with a good description of Retroquad is my Patreon page:

The engine is not released yet, there's a lot of work to do. I'm currently doing some major rewrites in the network protocol. 
Start A New Thread 
when you're ready. 
Surround Sound? 
Hey. Is there a way to enable 5.1 surround sound in QS? 
No, Stereo Only Unfortunately 
I think DarkPlaces has surround sound support. 
Any Plans For It? 
It does. So does FTE (though for some reason it doesn't seem to remember my settings).

I only recently got into QS and I really like it. It would be nice to have some more audio options though.

Slightly off topic but QS also seems to have some issues with music playback too. The original game and the official expansions seem to work fine but Abyss of Pandemonium, among others, seem to skip during playback or even not play tracks at all. Messages like "CD Track 07 Not Found..." even though they're in the folder.

I'm using Windows 7 Pro (64 bit). Perhaps that's the root of the problem? :) 
Music skipping is not good, never experienced that myself. Win7 64 should be a fully supported OS. I'd suggest re-downloading the latest version from: and make sure to overwrite any existing DLL's in your quake folder. It's annoying that the DLL's from different engines conflict with each other.
I'd also test both of the SDL versions (quakespasm.exe uses SDL1.2, quakespasm-sdl2.exe is SDL2).

For the Abyss of Pandemonium music issue, I'm not sure, but if the id1 and mission pack music works, then I suspect something wrong with your AOP music files. What format are they in? There's extra info about the QS music system here, not sure if it could be helpful:

I'm not sure how likely surround support is right now; I don't have a 5.1 system myself to test it with, and it is something that's tedious / messy to implement. Maybe at some point, not sure. :-( 
I do have QS in its own folder. I'll try a fresh install and I'll try it on another machine too and let you know how I get on.

With regards to the Abyss of Pandemonium music. I've got both the ISO audio disc (I use Daemon Tools) and the OGG files as found on Quaddicted (as far as I know they're correctly named track02.ogg et cetera). Obviously I've only used them one at a time! :)

I have a similar issue with the Travail soundtrack too.

The most perplexing one is when QS reports not finding the CD track when playing random SP maps. To me, they're quite obviously there and working as they all play fine during the original Quake maps... 
Shame About 5.1... 
That's a shame about there being no surround sound support. For me, audio is a huge part of the Quake experience.

I do understand though that such things aren't a priority (or maybe not even that interesting!) for you. Still, I'll keep my fingers crossed for the future. :) 
A Small Feature Request 
Sorry to be the typical noob posting lots of stuff but I have a small request if that's okay.

I wonder if it would be possible to add a CVAR to centre the message text? At the moment all text (including Showscores) is centred except those in shown in the top left (pickups et cetera). I know it's a trivial aesthetic thing and I know that it wasn't part of the original Quake but I just think it's a 'small thing' to tweak that would make the text aesthetic more consistent.

Hope that makes sense and hope that it doesn't bug you. :) 
Are You Saying 
You want ammo pickup text to appear in the centre of the view? 
Pretty Much. :) 
Perhaps I wasn't as clear as I could've been. It would be nice if it could appear in the top centre rather than the top left.

ZDoom offers a similar option in the HUD menu. I just think it looks a lot nicer.

Scores are shown in the bottom centre.
Context messages are shown in the centre.
Pickups et cetera shown in the top middle.

That Would Break Console Behavior 
Quake text is on the top left because it's part of the console. When the console scrolls up, the recent messages stays at the top while the background scrolls up completely.

Changing that would make recent console messages move from the left to the center when the console scrolls up, and that would be weird.

Anyway, that's a matter of preference. 
could fix in in QuakeC with centerprints maybe 
con_centernotify in fte and I believe dp.
also applies to kills, of course. and chat.

probably the best thing is to just remove pickup messages completely. they're basically just spam anyway.
flash an icon somewhere if you want, but expecting the user to read stuff in the heat of battle is folly. 
the only time I ever use pickup text is to see whether I've picked up a 15 or 25 health, just so I know for my next run if I die. Of course, the obvious fix would be to make the health box graphics display this more obviously. 
I've tried it out in FTE and it's great. The in-game text is top-centre while in the console it remains left justified.

Is that something that could be added to QS? You'd make an old man happy! :P 
Fog Bug 
There was a bug with fog in the SDL1.2 build (quakespasm.exe) - when changing video modes, the fog formula was getting reset to the OpenGL default (GL_EXP) when it should be GL_EXP2.

Quick fix is to just use quakespasm-sdl2.exe. (SDL2 preserves the OpenGL context when changing video modes, which works around the bug, but it's fixed properly now anyway.) 
- Allow for bigger weapon models, or at least winquake style weapon placement. The weapon model on winquake, and in the latest version of mark_v, allows the top of the status bar to be the 'bottom' of the screen, allowing you to see more of the weapon. Guns look silly in QS.

- Despite choosing to have music turned to 'off' most of the time Quakespasm INSISTS on playing the music regardless of setting. It's infuriating!!

- contrast and brightness as separate controls? I dunno if this is possible, it would be nice to have this level of control. I find QS to be a little washed out. 
Yeh, I second the need for a contrast cvar to avoid washed out visuals, I always miss it if I'm using Quakespasm rather than another engine. 
Minor Quibble 
regarding the quakespasm website with all its "Being", "Manifestation" etc. faffery.

What's wrong exactly with the tried-and-tested "About", "Download" etc. type headings?

I'm trying to get some colleagues onboard the Quake train (by way of Quakespasm), and it's something that has been raised more than once in a not-too-enthusiastic way. 
I'm with you on the guns; on a widescreen monitor with the full statusbar showing, the SSG barely pokes out about the top of the sbar.
If you lower "statusbar alpha" to the minimum value in the settings screen, it pushes the gun up.

re: music, the "external music" switch in the settings menu seems to only take effect when you restart the level - it should stay off from that point on, but maybe there is a bug there? I usually just lower the music volume slider to 0 if I don't want it.

contrast adjustment is a good suggestion too. Raising the contrast in MarkV does brighten the image without washing it out. 
I just tried what you suggested to make the gun look bigger but you're trading off the status bar for very little gain. QS basically only displays half the gun model, it looks atrociously bad IMO.

I have the external music switched off in addition to the volume being zero and it still plays the music (at full volume no less!!). 
For Visual Reference -

I believe Mark_V didn't always display properly and was only recently fixed when the option was added for a "winquake" mode... basically the top of the statusbar is considered the bottom of the screen. the behaviour in Mark_V is that as soon as you add alpha to the statusbar the weapon is drawn from the bottom of the screen again (I guess there's no easy fix for this). 
I think it's cool, just a bit of flavor. I have difficulty imagining this being an impediment of any significance to anyone. 
Here here! And now imagine not being a native speaker and wondering even more what those complicated words might mean. 
When I first heard of Quakespasm and went to download it, I saw that weird web page and thought my browser had been hijacked. 
I have difficulty imagining this being an impediment of any significance to anyone.

Yeah I get that for us it's no barrier - we just click on the funny words until we find the one that goes to the page with download links.

It's just not user-friendly to newcomers, that's all. 
Agree With Kinn 
The QS website is purposely obtuse for no real reason. 
I thought I had gotten a bad link the first time I arrived there too. FWIW... 
If this was a website for an actual game then I would be more approving. Art has room for the abstract, to allow for interpretation and subjectivity.

I think for an engine, something that provides a utility, the website is quite poor and you cannot apply the same design philosophy. 
And now imagine not being a native speaker and wondering even more what those complicated words might mean.

Ah, this hadn't crossed my mind. I can see how some would find this annoying or even inconvenient.

Perhaps using rollovers would help; hover over Manifestation and the word will change to Download.

Probably not the most elegant solution but it might be more user-friendly while still having a bit of flavor. 
Referring to metlslime as just "Fitzgibbons" reads very awkwardly. 
come on you guys... you click the links till you see 'windows' or 'linux' or whatever you're looking for, then you click the highlighted text.

you don't need to read anything to actually get the engine.

kinn, since you brought it up initially, what were the exact complaints with the site anyway? i mean, i agree it was weird when i first got there, but i just started clicking links till i saw something that looked like a download link. 
Clicking around until you stumble into what you want is not really the ideal user experience. 
I agree about the labels, they could at least have normal translations above/below. will ask the other qs devs when we are prepping the next release.

Fifth, thanks for the screenshot.
I checked winquake at default settings ( surprised how weird it feels that the gun swings when you look up/down), and you can see the top half of the end of the barrels:
I'm not sure of the history of it but QS is the same as Fitz 085 I think, except with compensation for 19:9 resolution. I'm sure baker and others have researched and written about the topic so i'll look into it sometime.

Also, if the music volume slider doesn't work, the only explanation I know of is it's playing CD audio - do you have the soundtrack CD inserted/mounted as a virtual drive? The CD support in QS might lack volume control, I never really used it. There is a "-nocdaudio" command line option to disable CD support entirely, or use the -sdl2.exe builds which lack CD support iirc. 
When I originally changed it in fitzquake it was to fix the weirdness of the gun moving when you looked up/down. I was also trying to fix it for wide fov views. I think looking at screenshots now the part I failed at was making the gun look like winquake when the camera is level, not enough gun is showing. 
Show Us Yer Gunz 
Referring to metlslime as just "Fitzgibbons" reads very awkwardly.

you just have to read it in that lou gossett jr. vortigaunt voice

"the One Fitz Gibbons has come to save us from the dark placessss" 
I don't remember exactly what I did for the gun, but I'm pretty sure I fixed it so even "FitzQuake gun" will always be visible and in the same place no matter the aspect ratio.

I may have calculated one perspective matrix to draw the gun and another perspective matrix to render the world, with the gun matrix being limited to the largest 1:1 square on the screen. (i.e. 1368x768 ---> 768/768).

Having a WinQuake-like gun positioning option ended up being "non-optional" in my mind. I'm not going to make a Mark V WinQuake renderer that can't look exactly like WinQuake. Would make no sense. 
Hahah I didn't know about that.

The fact that there is a page set up as a workaround for the puzzling nature of the main site is, hmmm, well. Nice to know though! That's a good link to share for evangelizing Quakespasm. 
Loading game from /home/me/.quakespasm/ad/quick.sav...
ERROR: couldn't open.

I did not pay attention to saving but thought I had saved. The message implies an error reading the file to me but in reality I did not save and the file did not exist. Maybe reword it if the file is not found? 
Hm, "couldn't open" is printed when the fopen() call fails, so it makes programmer sense :P I guess it could check for the specific reason and print a clearer message.

However I'm more concerned about why the saves failed, I guess you are using the patch that adds ~/.quakespasm support.

Is there any way to get fog without banding? nvidia on Linux.

Make sure QS is using a 24/32 bit video mode.
There's a vid_bpp cvar which is archived, but since it gets saved in every mod directory it's safer to launch with "-bpp 32".

(I'm surprised the QS default for that cvar is actually 16bpp, which I never noticed.)

Aside from that, banding will be the least at "gamma 1". There should be the same amount of banding as other engines @ 32bpp. 
No saves failed, I simply did not make any =)

Still some banding but I guess that might be the low dynamic range of the lightmaps. 
Not Urgent 
But the soon to be released map(s) of mine extends beyond Quake's standard -+4096 boundaries. I understand a new protocol will have to be made in order to accommodate this, but I am unaware of how difficult such a change will be. 
I wouldn't rely on that. It's REALLY unlikely to happen anytime soon. 
what are you currently running them in? 
larger boundaries is basically the point of rmqe's 999 protocol.
servers can fairly trivially use a specific subset (which is what fte does), while clients can probably get away with just short/float coords and byte/short angles. 
RMQ version 0.85.3. It is currently the only publically available engine that plays the map properly without any visual problems. 
Loading Mods In Game And Quake.rc 
Seems when I load a mod using the console (e.g. game x) it doesn't exec that mod's .rc file.

The Console Says.. 
'Enter 'exec quake.rc' to load new configs 
i never read that 
Controller Support? 
Sorry if this has already been discussed, but is there currently or will there be controller support for quakespasm? 360 or otherwise?

I know the majority of players use mouse and keyboard and I agree it is a more proficient way to play. But I currently use a controller for my gaming for various physical reasons.

I wanted to check out quakespasm to play arcane dimensions, but it does not seem to have any controller support that I can figure out. Not even the original quake joystick support. Is there a way to enable controllers or plans to add it in the future? 
+1 For Controller Support 
I also find console-style controllers much more comfortable than mouse & kb.

Would love 360 controller support in QS. 
I appreciate that the number of people who want to use a controller in QS is probably single-digit.

Legend - have you looked into using some sort of scriptable input emulator? A quick google throws up this: looks like it could be cool if you fancy doing a bit of python. 
Count Me In 
but only because I would also love to see split-screen functionality in the game. 
Xbox360 Controller FreePIE Script 
Legend - If you wanna have a look at FreePIE - I found a script for the 360 controller that looks like it could work well.

Note: I haven't tried any of this stuff out yet - but will do as soon as I can.

Also, you can (and should) edit the .py file to change button mappings to what you want.

script here: 
Controller Support 
There is none currently.. I tried implementing it in QS a while ago; I do have a 360 controller.

What I found frustrating is, the FPS games that have good-feeling controller support (Valve games) are doing some fairly complex easing stuff. Like, if you flick the analog stick all the way to one side, there's a period of time where you turn slowly, then suddenly it accelerates like crazy - so there's some sort of time-based acceleration going on.

I don't actually game with a controller ever, so maybe that stuff is not really desirable, but I'm guessing it is. Anyway I'll try to dust off what I wrote and post a beta here for feedback. 
get that 4 player split-screen support coded in while you're at it ;) 
FTE can do split screen. 
why are the players christmas lights 
that's cool as hell!

Does it have Pad support though?! 
Didn't make the pic. ;=) 
@fifth -- don't know. If I recall, Spike said it basically needs 2 USB keyboards plugged in. 
Fte+splitscreen Input 
bind w "+p1 forward"
bind uparrow "+p2 forward"
bind lctrl "+p1 attack"
bind rctrl "+p2 attack"
bind 5 "p1 impulse 5"
bind kp_5 "p2 impulse 5"

if you omit the p1 / p2 stuff then yes, the engine uses an internal index of the input device that generated the key events in order to determine which player the event is meant to be controlling.
4-way splitscreen kinda needs a lot of keyboards and binds... you could of course also use csqc for really weird bind setups, which has access to the devid stuff too, but of course this isn't relevant unless you're making a mod.

you don't need two keyboards, just really weird binds.
also, fte is supposed to have support for xinput now, including support for per-player headphones as part of that (I don't actually have one, of course), so that's an alternative way to play splitscreen games.

yeah, bloom + fullbrightskins kinda has that effect. quakeworld players might be crazy for wanting fullbright skins, but at least they don't use bloom. only a crazy person would use both at the same time...
also looks like someone disabled rtlight shadows in an attempt to make rtlights look obviously worse than lightmaps. 
Direct Input Controllers? 
what about the direct input joystick support that the original quake had? I know it works with directq and qbism super8. they don't recognize 360/x-input, but work fine with direct input controllers like logitech f310. 
FTE Cvars 
in_xinput 1 //enables xinput for 360 controllers.
joystick 1 //enables the old joy* apis that vanilla winquake used. some of the stuff will have been tweaked over the years, however... you'll probably need the binds menu to figure out which button is which. 
Does FTE splitscreen work with networked multiplayer? IIRC a few years ago it didn't. 
set 'allow_splitscreen 1' on the server if you want cl_splitscreen to work with a separate server (otherwise its only permitted for the local client by default). This setting has existed for as long as fte has had splitscreen support. 
This mean we can create an 8-player game using only two computers, right? 
Imagine a team deathmatch like this. Two teams of four in two computers. 
I Play Lots 
Of local multiplayer. So it would be awesome 
^ I Need A Job Like This 
Noclip Fun 
You know when you're noclipping and you hit a brush sloped in a certain way, and it takes control away from you and sends you floating vertically upwards until you exit noclip?

I know it's low priority as it only affects developers/cheaters, but I just wondered if it was an easy fix because when developing I seem to spend a lot of time wrestling with this quirk :( 
Never seen that... noclip always, well, doesn't clip with anything no matter what shape it is.

Is it just because I only make boxes? 
I think that's a trigger_monsterjump and the following tutorial I wrote over 3 years back on Inside3D is all you need: 
It's when i noclip into brushes that are sloped in two axes maybe??

But - it's definitely world brushes and happens to me constantly. 
That's weird ... I mean, as was said, noclip shouldn't be colliding with anything. At all. 
just checked - slope in only one axis will do it.

Hmmm..maybe it's only in unsealed maps?

Leave it with me, when I get a second I'll make a test map to demo it. 
I've seen it in id1 maps too. Or maybe there's two problems here and the one I've seen in id1 maps is trigger_monsterjump... 
A Test Map 
Would be cool by the way. It would be possible to trace through the physics code, selectively disabling sections of it, and home in on exactly what's causing it that way. 
it's obviously more complicated than I thought. I made a simple test map with a number of different slopes and noclip worked fine all the time.

I have no idea what's going on now. If I ever find a way of reproducing it in a test map i'll let you know. 
^ Moved To Drunk Thread 
theory: do you press space to strafe up, realize that doesn't work, then press x instead? I do that a lot when noclipping, and that might be setting a stale jumpflag on the player that doesn't evaluate until you're near a surface. 
I Have Had Similar Troubles 
and I think Lunaran is on the right track. I could always remedy the problem by mashing buttons until the player stopped moving again. 
i think the only time i have seen this it was from hitting a waterplane at the same times as a ~16 unit lip above the water. I think it was triggering the "jump out of water" code that lets you get up onto the shoreline. 
which implies that the quakec is responsible rather than the engine. 
Ok, get into waist high water. Go into noclip and fly around. when you hit geometry that would trigger the get-out-of-water-jump, you go on a space adventure!

Thanks metl.

I have so much waist high water in this map, that's why it seemed like it was happening all the time for me. 
i know some of these words. I had similar troubles during testing, a mystic force pushes you up when noclipping. But this also occured for me in maps with yery little water(RRP). 
Nothing more. 
Quakespasm 0.91.0 Released 
Enjoyable Changes 
Raised limits:
Default max_edicts 8192 (was 2048) and no longer saved to config.cfg.
Default heapsize 256 MB (was 64 MB).
Default zone 4 MB (was 384 KB).
Raised MAX_SFX to 1024 (was 512).
default zone is nice. it's a mostly unknown setting, and most people don't notice it like they would -heapsize, but it causes crashes if not set high enough. thanks for that! 
Someone should add a "-singleplayer" command line or something that just jacks everything to the max. I'm not networking, I don't care ... I just want to play this level without crashing. :) 
That's not actually necessary: the engine should be able to detect when a single player game is being played (if ( && !dedicated && svs.maxclients == 1) or something similar, and automatically tune itself. 
Anything that means people have to write less crud in configs and command line arguments is a positive step. 
mh - That would be awesome. 
None of those new defaults has anything directly to do with networking or single player, by the way.

max_edicts was a cvar in FitzQuake dating back to at least 0.80 because in earlier times some people would use GLQuake or another custom engine (there used to be tons of them) and GLQuake had a max_edicts limit of 640.

FitzQuake allowed you to set max_edicts from 2048 to 640 to make sure things worked in standard Quake without using a different engine so a mapper could ensure wide compatibility. 
Site Blocked 
Just as an FYI, I recently installed uBlock Origin as I finally got sick and tired of the increasing amount of ads online and mainly because the latest version of Chrome had a terrible freezing problem. One of the filter lists this plugin uses blocks Sourceforge. It can be disabled, but just thought I would let you guys know. Maybe switch hosting of the site to Github Pages? 
So you have an adblock plug-in that blocks SourceForge ...

And your idea is that to accommodate your adblock plug-in, that the Quakespasm guys should uproot all of their machinery and tools from SourceForge to GitHub because of your plug-in?

Is this a correct way to understand what you are suggesting to the Quakespasm guys? 
I use uBlock Origin too. Just click "Temporarily" olol 
I use FireFox + AdBlock Plus and Quakespasm's SourceForge page works just fine. That's all I'm saying! 
Not telling anyone to move anything. Just letting them know. Sourceforge has bigger problems anyway.

I'm a savvy user so yes I unblocked it. I was just posting an FYI. 
I Use 
Adblock. The original one written by one guy.

I don't really trust the others since I got massive slowdown from Adblock Plus one time and another from uBlock. 
Adblock ... I also installed a YouTube specific ad blocker. 
Called, surprisingly enough ...

"Adblock for Youtube"

I was just saying suggestion sounds a bit extreme. ;-)

And if other adblockers don't have issue, sounds like uBlock needs to get on the ball. 
Adblock seemed to hog resources. uBlock Origin is light as a feather, in my experience (Chrome). All the kool kids seem to use uBlock Origin also. 
I use adblock on its own to block youtube crap as well, seems to work fine.

It does have a problem with more than one ad blocker installed at once though (on chrome) because each becomes a new instance that doesn't play nice with the others. 
I use ABP... seems standard 
Just fyi �block Origin is the best ad-block around, especially in terms of performance.

Pro-neckbeards might like �Matrix. 
my keyboard doesn't have a � key 
alt gr + m 
I don't have any ad blocker specifically, just NoScript and Ghostery. However, my HOSTS file is nearly a megabyte in size and has close to 30,000 entries.

It's extremely rare for me to be blocked from a reputable site, and I almost never see an ad. 
Thanks for the new Quakespasm update. You guys are awesome. 
MD3 For The Shambler In QS Engine? :) 
So yea... this guy has an MD3 version as well... I convert him to MDL afterwards.

I would love to include a more precise version for folks to use in Quake Spasm in the future. If that lovely tech gets added then I would just for joy. 
OK here is my wishlist:

What are the chances of sticking in a simple external file read/write ability, accessed via QuakeC?

Something a bit like this? 
I posted it in the thread for the new Q1SP map, but whenever I try to start a game with this new updated client, the game exits to the desktop. Anybody know what's going on? 
Is this with the "Experimental build" in the oms3 thread (quakespasm-rf6d[...].exe)?

Argh, crash to desktop is the worst. No error message / dialog I assume?
Could be some dll conflicts.
If you don't mind trying a clean setup, this could help: create a empty directory. Extract all files in the QS zip. create an "id1" subdirectory in the same dir, and copy your pak0.pak/pak1.pak files to there. 
Haven't tried with the one in the oms3 thread, just the newest one in this thread and on the quakespasm site, 91 i believe. I'll try a clean install when I get the chance and report back. 
Alright so making a clean install didn't work either. To answer the previous question yep, no error message at all, just exits to desktop. 
Run it from a cmd window, might show something 
quakeisdead, ok, thanks.

Did a previous version of QS work for you?
There are 4 QS build to choose from for windows, 32/64-bit and SDL1/2 - which are you trying, or do all fail? the full download list is here:

One thing to check is enter "gl_info" in the console. It'll print a bunch of GL extension info, but scroll up with PageUp and check the GL_VENDOR, GL_RENDERER, GL_VERSION.

Another idea is launch with the "-condebug" command line option (create a shortcut and put it in the end of the target field.) This creates a qconsole.log file that may have some info on the crash. 
QC File Access 
If you're going to implement this, then I strongly recommend that you first implement a Sys_FileOpenAppend function in your sys_*.c rather than using the zone-memory nastiness in the original tutorial. I have no idea why the original authors didn't do this. 
Not a mapper or a programmer so I have absolutely no idea what any of that is. I guess I'll wait til the next stable release of Quakespasm to play again 
Case-sensitive Console 
I just realized you can type in small or big.

Is this a feature for case-sensitive OSs?

In Windows versions it does not seem to be a very useful feature, because if you happen to use a capital letter in a console command it says 'unkown command'. 
RE: Case-sensitive Console 
Seems like it is not case-sensitive for commands, but it _is_ so for cvars. The behavior seems to be the same in the original quake source too. 
all quake engines do this. it's not very useful. 
I don't know the difference between command and cvar.

If you type 'mAp e1m1', it will load e1m1.

If you type map E1m1, it won't.

Is that what 'it is not case-sensitive for commands,
but it_is so for cvars' means? 
"map" is a command. What the engine not being case-sensitive for commands means is that "map", "Map", "mAp", etc will all work and will all change the map.

It's actually even worse because the engine is case-sensitive in some places for commands, but not in others. Cmd_AddCommand for example is case-sensitive, so it would in theory let you add "mAp" and "map" as separate commands. Cmd_ExecuteString is case-insensitive so which of the hypothetical two it actually executes depends on the order they're added in (or something else if you e.g sort commands for faster finding).

All of this is clearly buggy behaviour, but is it the kind of buggy behaviour that legacy content may have dependencies on? 
Are you thinking like cfgs and stuffcmd/localcmd? 
Not thinking anything in particular other than I've been in a "put the bugs back" scenario before, so caution seems merited. 
All of this is clearly buggy behaviour, but is it the kind of buggy behaviour that legacy content may have dependencies on?

Is Cmd_AddCommand used for alias commands? If not, then surely only the engine is going to be calling it. That should make it safe to fix in a given engine. 
i was thinking there may be some mod that executes commands from a config to set things up and maybe they typed the command with/without caps. 
Is fence texture support on .mdl planned? 
Is there a way to change water color? Underwater everything is beige and in dark corridors I can't see anything. 
try setting "gl_cshiftpercent 50" in the console (default is 100) 
Mark V has a cvar r_watercolor for the underwater cshift color. There is also r_lavacolor, r_slimecolor.

In the engine code itself, it is referred to as called r_watercshift as a more descriptive internal name. 
Thank you, ericw. Now underwater fights aren't a pain anymore.

PS. I'm planning to speedrun a forgotten map pack. 
Suppress Launch Dialogue 
Am I correct in understanding that, on OSX, there is no way to suppress the Quakespasm launch dialogue (which allows the selection of command line parameters and resolution)?

I am writing a shell script to compile my map and then launch it in the game and it would be great if I could pass an argument that tells Quakespasm to suppress the launch dialogue and go straight into the game engine. 
You Can 
open ./ --args -nolauncher

Substitute the correct bundle name, of course. 
Suppress Launch Dialogue 
Excellent, thank you. 
how do you launch this engine windowed with a specific size?
when working on maps, i prefer to keep it windowed... i am using these args:
-vid_fullscreen 0 -width 1440 -height 900 -bpp 32
it starts windowed, yet it is not using the size i specified with width and height... 
Any chance of a command similar to "kill", but...

like kill, it reloads the map but it preserves the player's position, angles, and flags such as god, notarget, noclip etc...

When mapping I find the time it takes me to noclip over to the distant area I was working on after each map reload, really adds up, especially when making millions of tiny incremental tweaks to lighting and things... 
This works fine for me:

c:\quake\quakespasm.exe -width 400 -height 300 -window 
cool, thanks. looks like -window does the trick :) 
Use "testplayerstart"? 

not a command it seems 
could you do that by relying on an alias with multiple commands and some QC support?

impulse 50; kill; impulse 51

eg: impulse50 encodes player position and angles into temp1, kill restarts the map, impulse 51 uses data in temp1 to reset position? 
well I was hoping there would be a solution that doesn't require the use of a custom mod 
ok I can abuse the save/load system to reload the world whilst preserving the entity state of everything...

that may do for now :} 
It is an entity i place to avoid noclipping 2000 units over and over.
AD doesn't have it, i used the normal "info_player_start" there.

You'll see a warning of multiple start entities in the engine, usually the engine picks the first it finds to place the player. (or was it the last?eric?) 
Right - I have never managed to get region compile to work in netradiant, so I'd have to stick to using one info_player_start and keep moving it around with me, which would be a pain.

Meanwhile, I have stuck this in my config:

bind "F5" "echo Dev Reload...; wait; save devsave; wait; load devsave;"

Of course no entity changes can be viewed with this, but it works a charm for refreshing the world geometry and lighting, which will save me a bunch of pain already. 
Windows Defender Is Detecting Quakespasm As Malware 
Windows Defender is now detecting the latest QuakeSpasm as malware:


It detected it when I tried to run the version already on my computer, and then when I tried to download the engine again, it caught it again on the download. 
Sourceforge Is The Asshole Here 
Lets move this project to github? 
That Were My Two Cents 
Another Image 
This image shows the culprit file when it detected it on my existing installed version:

See that it flags the file quakelibopusfile-0.dll

I'm assuming it's a false positive, but it's stopping me from playing it right now :( 
delete your HDD, throw the screen out the window(just to be sure), and melt your HDDs with thermite(to be super sure). Thanks Sourceforge! 
Note that Windows Defender has only just started doing this - the version I had on my PC has been there for a couple of weeks with no problems. Dunno why Defender is sharting over it now :/ 
I Know The Answer To This 
use tails. 
Windows Defender isn't detecting anything for me. I just updated the definitions now and am running the latest windows 10.

Would you mind uploading that dll somewhere, or the whole .zip that is being flagged? I'd be curious to see if it has been tampered with or is binary identical to what it should be. 
microsoft's virus scanner spuriously detecting false positives in software that uses technology that might be a competitor to their voip product? who'd have thought it!... 
Adware Is As Bad As Cancer. 
Once they started this, they prepared their demise. In my view. 
Windows defender removes it so I don't have it to hand but the file that this link downloads has the "trojan" apparently: 
Re: Sourceforge 
Hey Guys,

Not to sound like a smug a$$hole, but I did mention problems with Sourceforge a month ago here and was treated poorly by Baker.

You should just move the hosting to GitHub Pages. 
We Don't Know It's Sourceforge 
Right now my bet is it's a false positive. Weird no one else is getting this. Windows 8.1 using up-to-date Defender. 
Re: Sourceforge 
Well whether it's a false positive or not, Sourceforge has been caught red handed last year injecting malware into software they host. I wouldn't trust those guys anymore. 
Last year the Direct X version of Mark V was continually flagged as a trojan by Microsoft while 61 other file scanning services say it is not a trojan.

As a result, I now I distribute the Direct X version in a separate zip.

It's somewhere in the Mark V thread around post #732 
What Tamarisk is referring to is this:


Developers must opt in to a new "DevShare" feature.

If you opt in, your project gets embedded in SourceForge's custom installer.

That custom installer may bring crapware along for the ride.

Important thing is that if the developer doesn't opt in, none of this happens.

Personally I think that Tamarisk is scaremongering a bit. 
Scaremongering eh? Did you even read that article mh.

While true that the DevShare is opt-in, SourceForge has been caught red handed doing other not so nice things. Repackaging "abandoned" projects for one. 
Done And Done 
Anyway, I'm done with this thread until it goes back to the real purpose, to discuss Quakespasm. You know this is just typical of the BS online nowadays. Try to post some useful information and get some nitwit shooting you down. Have a nice day folks. 
Home Of The Critics 
Func_msgboard is home of critics. It's what makes this place high quality. Participants here are expected to be able to explain/prove what they say or defend their thought process.

If you want to say Sourceforge is messing with a .dll fine, but you better be prepared to back it up with evidence.

That's just high standards at work. 
Sourceforge has new owners, clam down...

Antivirus is a fucking laugh. 
"If you want to say Sourceforge is messing with a .dll fine, but you better be prepared to back it up with evidence."

^^ This.

I mean, seriously, dude .. YOU brought it up! Don't get pissy when someone asks you to prove it. 
Kinn, when I download using the file I get has this SHA1 sum: 080f764fd7ace0764906a4d524e9463c47731f3a
If you want, check the sha1 on the zip file you download to make sure it's the same.

Here's an alternate download with the dll's:
The libopus-0.dll file is in the subdirectory: quakespasm/Windows/codecs/x64/

Note that this dll should be binary-identical to the one in the from SF (it is for me.)

My windows defender info is:
The archive comes up clean with both Windows Defender and Trendmicro HouseCall.

Sorry you had to deal with this, hopefully it's a false positive. 
Thanks - both of those links work for me without Defender shitting a brick :)

The SHA1 I get is 080F764FD7ACE0764906A4D524E9463C47731F3A

which is the same as yours (typical it comes out uppercase making it more annoying to compare hehe)

My defender version is now this:

So yeah it looks like a false positive and Defender's new virus definitions have sorted that shizzle out hopefully. 
since sourceforge changed it's owners in what 2012 I tried steer away from it. I used to like the service but not anymore. I'm always reluctant when stuff is hosted there and it leaves the impression of an abandoned project.

I don't understand why quaskespasm is hosted there. I don't even care that they changed owners again in 2016 because there's github and that service I do still trust in and also really like.

I'd leave sourceforge just for the sake of not making people download from a site they distrust. I don't care if they get their shit together or not. 
Yeah, let's put everything on Github because that is never going haywire. Self host, you lazy people... Gitlab is fun.

flp: Read my post above. 
is this ever going to happen? i cant bring myself to game from a desk when i can game from a recliner.

let me play quake again, please. 
shub: Yes, soon! I have it working pretty nicely - played some of AD with a 360 controller, just need to polish up a few things.

.. continuing from the RRP thread about Barnak's HOMs when using fsaa + "r_oldwater 0" + OSX 10.6...

Baker, I found a workaround, adding "GL_SetCanvas(CANVAS_DEFAULT);" to the end of R_UpdateWarpTextures.
R_UpdateWarpTextures leaves the glViewport configured for the warp texture (the square in the upper-left of the screen), and R_Clear is the next thing to happen after R_UpdateWarpTextures, so my guess is that fsaa activates some code path within the mac GL implementation where glClear is broken and uses glViewport as the area to clear..

Here's what it looked like for reference:
The second shot has gl_clear enabled, but you can see it's only clearing part of the screen. 
Ironically, the bugged glClear behavior would be better standard behavior. 
glClear should respect scissor test but not viewport, which is a bit more flexible IMO. 
360 input - awesome

Will we have tons of commands where we can fine-tweak deadzones, accelerations, and all that? 
Yes, the bug I described looks like your screenshot. But on Rubicon3, it is terribly much more messy, with an extremelly luminous background (skybox ?).

I'm still wondering why it only happens with this Mod, and never saw the bug on any other Mod or map before. 
It was probably RRP's quake.rc with settings put in there. I would expect r_oldwater was in there. 

I made a few personal changes to Quakespasm to solve a few minor annoyances I had. I was told I should show them off here in case any of them could be added to the main project.

What I've done:

QW hud option (cl_sbar)

Did the legwork to adjust the weapon offset on screen, I noticed some murmuring in here about what the best behavior should be as QS draws it with no offset. I decided to make it work closer to WinQuake, however I also made it adjust according to your status bar scale setting and status bar alpha, so it isn't ever too far up. There's some screenshots in the github link.

Adjusted centerprint message canvas so it's always above the crosshair. Depending on settings they used to cover the crosshair or even appear below it!

Right now I'm adding a new feature, automatic UI scaling. What it will do is when any sbar/console/whatever scale cvar is set to 0, automatically set the scale factor to make it fit the screen as cleanly as possible (integer scaling). That way new players won't have to mess with cvars to be able to read things at high resolution, or mess with the scale slider until it's even looking. Could be handy as a possible default. 
Great work man!! 
I finished and pushed the auto scaling feature. I've also been experimenting with a widescreen status bar implementation when sbar alpha is 1, though it's a bit hacky (lots of tris)

Does it look good or is everyone used to the regular border graphics? 
Looking From A Phone Screen 
It's a nice idea, but the empty boxes above bother me more than they should.

Ideally this sort of thing needs a proper layout design first. Try grabbing a pen and paper - for me random scribbles are good during the creative phase and the computer during the productive one. 
Side note: Don't want to interfere with the current conversation.

Quakespasm inherited bad centerprinting from FitzQuake. No other engine from DarkPlaces to ezQuake to WinQuake to JoeQuake has a centerprinting problem (Mark V does not have the problem either).

The FitzQuake centerprinting location can't be solved by moving text up or down a line, because "what line" it prints on was never the problem ...

It's a multi-factor problem that will resurface with a different combination of settings if "fixed with a hack" --- the problem is the "definition of a line" is not consistent across various settings.

(Please carry on with existing interesting conversion ...) 
My description is a bit simplistic, I did not simply change a y-coordinate. I reorganized centerprints to its own GL canvas that spans the height of the screen, and I have the lines start printing in reverse order from 1/3rd the height of the screen. This keeps it off the crosshair even when the sbar is fully scaled up. (if there are more lines than would fit in that area, then they do start covering the crosshair, but this would have happened in any engine)

Winquake (and I'm assuming the other quake engines you mentioned) did it by drawing lines 35 pixels from the top of the screen, scaled to whatever scaling values each engine uses. The drawback is the smaller the text scale value the closer it is to the top of the screen, which draws it away from the player's focus more and more.

Quakespasm's old behavior drew centerprints in the Main Menu GL canvas, which originates from the center of the screen. This limited the height that centerprints could start at without shifting up the main menu as well. 
To Ijed 
My intention with the widescreen sbar was to be able to construct it in-engine from the sbar graphic, that way it could be compatible with whatever mods replace that graphic. Since QuakeC can't rearrange the HUD, any such graphics would fit the same layout and probably look about as good. 
+1 Sounds like you are detail oriented and anal retentive and do your homework and then plan.

(I like this guy already!) 
Back On Centerprints 
I checked Mark V and it seems we had the same idea. Yours just takes into account status bar height as well. Mine doesn't, I based it on Winquake's offset at 320x240.

I guess I remembered WinQuake's behavior a bit wrong, it only used fix offset from the top when there was more than 4 lines.

Still, what I did was make it always originate from about 1/3rd the height of the screen. The difference is I set it so that point is where the LAST line will be drawn. If there are more lines, they originate from higher, unless it would start offscreen. 
At Baker 
True enough, it's why I did this fork to begin with...:P

@ijed: How's this? Now it skips the vertical lines 
Controller support :)
Amazing the amount of stuff Eric is doing.


The QW Hud option is great, but i'm not sure about adding the option to the main option window. Probably ok... but the Menu-Item should be something meaningful, like "QW Style Hud".

Weapon Offset changes.. not sure about that.
Personally, i'd favour bigger field-of-view over re-placed weapon models.

The other things - an auto scale option is interesting, but not gonna bastardise the scale widget like that. It'd have to be a cvar only. And not keen on the widescreen status bar. Centerprint should be left as-is if crosshair 0, but otherwise - i don't use the crosshair, so can't say if it's an improvement. 
"The drawback is the smaller the text scale value the closer it is to the top of the screen, which draws it away from the player's focus more and more. "

Where the hell did this guy come from? Engine coders that preemptively analyze for situations that aren't on the screen.

(But yeah, that's true and fixed in Mark V. Probably DarkPlaces too I would hope because if LordHavoc cared about getting the gun to be in the same place in all resolutions, no doubt he thought about the text placement too. The gun thing is of course fixed in Mark V.) 
"The difference is I set it so that point is where the LAST line will be drawn."

But you can't do it that way. Some mods print 20 lines of center print.

(Ok, so he's extremely intelligent and introspective but isn't a grand master --- I'm kidding around a little with you) 
Sounds like some nice changes, thanks for contributing!

I'm not sure about , I think we'll want to keep the original tiling background. I imagine most people use a bit of status bar alpha so they don't see the tiled part anyway.
One change that could be good though is scaling the dark tiled part so the pixels are the same size as the main part of the status bar; currently QS doesn't scale that part. e.g., here's winquake at 640x480, sceenshot scaled 2x: 
Wow, thanks for the feedback guys.

@Baker "But you can't do it that way. Some mods print 20 lines of center print."

Simple "if (y < 0) y = 0" check takes care of that :)

A cvar to disable the weapon offsetting back to regular QS behavior is simple enough.

As for the wide-screen HUD, maybe it's not worth it after all. At least the regular tiling border is a close enough color to begin with (unlike Doom)

As for center print positioning I guess that's a personal preference sort of thing. I guess I just don't like text obscuring where I'm shooting.

Can cvars have multiple callbacks? If autoscaling was made a cvar it would be handy if any changes to the regular scaling cvars would disable it. 
Re: Tiling Sbar 
no way. those empty boxes would drive me nuts.

why even show the border at all? just remove the brown areas on the side of the sbar and float the sbar in front of the screen. 
why even show the border at all? just remove the brown areas on the side of the sbar and float the sbar in front of the screen.

Yeah, that would be my first thought too :P 
It's a "What do I need to find!?" OCD thing. 
Here Is A Fun One ... 
Omicron Bots mod has a feature Quakespasm can't use.

"registered 2 - the patch does not load the models supplied with the bots"

You can't set registered 2 in Quakespasm.


Omicron Bot Mod Download 
Controller Support 
Finally committed this! Windows builds available here ( r1293):

I'll need to add some documentation later, here is a first stab though:

* joy_deadzone - fraction of the stick travel to be deadzone, between 0 and 1. default 0.2.
* joy_sensitivity_yaw/pitch - max angular speed in degrees/second. Defaults are currently 300 for yaw (turning left/right) and 150 for pitch.
* joy_exponent - for the look stick, the stick displacement (between 0 and 1) is raised to this power. Default is 3. So a value of 1 would give a linear relationship between stick displacement and fraction of the maximum angular speed.
* joy_invert, joy_swapmovelook - enable to swap the move/look sticks or invert the look stick. Default is move on the left stick, look on the right stick.

Some of the controller buttons are hardcoded: back=TAB, start=ESC, dpad=arrow keys. The others are normal bind-able keys: L/RTRIGGER L/RSHOULDER, L/RTHUMB (pressing in the sticks), A/B/X/YBUTTON.

quakespasm.pak's default.cfg has been updated to give some default bindings, so make sure to install the quakespasm.pak. L/R shoulder buttons are bound to weapon switching, L/R trigger are jump and attack. A and B are hardcoded to operate the menu, but they're not bound to anything in game by default. If you choose "reset config" in the menu, these default bindings will be loaded, and I think "exec default.cfg" will also do it.

Other stuff:
The key bindings screen in the menu now supports 3 keys per action. This could be annoying for non-controller users, so maybe controller bindings/settings should get their own menu page. I just try to avoid adding things to the menu if possible.

Anyway feedback is welcome! Especially, are the default sensitivity/acceleration settings good? 
Amazing, this feels really responsive on the default settings. I blasted through episode 1 and I don't feel like I was hindered too much by the pad.

I bound jump to LT and shoot to RT and it was great. I wanted to have weapon up and down on X/Y but for some reason weapon down doesn't work??

I'm really hoping that at some point we can get split-screen working 2-4 player so I can run "lan" deathmatches and co-op from a single pc set up. I'm not sure how you would implement multiple pads but this would be a dream come true IMO.

Yes, I still play games in the old-school console way with my buddies even though I'm an old codger. ;) 
Here's a demo of me playing through Episode 1 with a pad -

As you can see I didn't really have much trouble, admittedly I can go through a bit quicker with the keyboard and mouse but it's still fun. In-fact it's almost more fun because of the slight handicap, some of the challenge was reintroduced. 
Awesome, glad to hear! Not sure why weapon down didn't work.
Yeah, local multiplayer would certainly be cool to have for lan parties.

I've had a lot of fun testing this too, played a few maps from AD with it while working on it. 
Possible feature?

Instead of weapon cycle it could be interesting to use the D-Pad to cycle through weapons.

Left = SG/SSG switch
Up = NG/SNG switch
Right = GL/RL switch
Down = Axe/LG

It will be a little bit like a weapon wheel but less crappy. 
Years ago there was a way of getting splitscreen to work on Quake 2 I think it was. The implementation was a bit funky, you opened separate executables and there was a window that allowed you to input the in-active window as well as the active window. You connected to your own pc through your LAN.

I tried searching for it but all I could find was this Quake 3 Arena source port that has native split-screen - 
Multiple Monitors, Multiple Engines? :) 
Open up 2 Quakespasm clients.

Use the new borderless feature.
Carefully position the windows and then toggle the borderless. Do this twice.

For the Window you touched last, the player uses the mouse and keyboard because only the active window can actually receive keyboard and mouse input in Windows.

For the Window you didn't touch last, the player uses the 360 controller. This will work because I suspect the 360 controller code won't check to see if it is the active window (but I didn't look) because the original Quake joystick code never did.

Now the guy using the mouse is going to own the 360 controller dude, so play coop.

You might want to set sv_aim 0.93 (the default Quake sv aim) so the 360 controller dude gets a little bit of aim help. 
D-Pad weapon cycling could be hacked in like this:

alias ng1 "impulse 4; alias ng ng2"
alias ng2 "impulse 5; alias ng ng1"
alias ng ng1
bind leftarrow ng

That would make leftarrow cycle between NG and SNG. The problem is you might have to tap it twice if you have the SNG but not the NG, the first press would try to select the NG.
Not sure if that can be improved on without doing it in QuakeC.

I can add a cvar to select which controller number is used, I assume SDL2 properly handles multiple controllers plugged in. Running multiple QS executables as Baker mentioned might work OK, I'm not sure if the background window gets joystick events, need to check. Also, currently sound is muted when a QS window loses focus. 
If the mouse/keyboard computer ran Quakespasm older Quakespasm without controller support and the 360 controller window ran newer Quakespasm with 360 support ... 
typo: not "computer", "window". 
you could do it like

bind leftarrow "impulse 4; wait; impulse 5"

This will pick SNG if available or NG otherwise, or do nothing if you have neither weapon. 
failed at my own board markup!!! 
I think native support would be more desirable than workarounds. The quake 3 source port shows its feasible. 
Looks like FTE has splitscreen support... would be interesting to see if controllers work with it! 
Sorry to do this again, but I went to try this out and Windows Defender is shitting itself again. it claims to find:

Trojan: Win32/Pocyx.gen!C!plock

in SDL2.dll

This is from downloading this build:

I'm sure it's nothing, but is anyone else having issues? 
Well I just tried sending that link to an online virus scanner and everything seems to check out, so

wtf is wrong with my windows defender? 
You've Already Got A Virus That Injects Itself Into Everything You Dow 
Czg - Is That A Thing? 
Ok...any idea why it would only pick on quakespasm downloads? 
Do you mean controllers working w/ splitscreen particularly, or FTE in general?

FTE seems to have controller support:

...but I haven't tried it myself. 
I can't get pads to work with FTE at all!

I have enabled the joystick CVAR but it only lets the d-pad work for some reason. 
in_xinput 1; in_restart
someone tells me that controller axis works, but buttons don't or something. not sure what's up with that, it might also be specific to csqc-only mods. all I can say is that faking xinput inputs (I've no physical hardware myself) appears to propagate events through my code in both csqc-only and ssqc-only mods, so I'm not sure what's up with that. 
Custom Mdl Doesn't Load From Id1/progs 
But if you put it in some folder ("quakedir/s/progs" for example) and enter "game s" then the model will be loaded and used.

quakespams 0.91 windows-x32-sld2

You can test it with a new shambler: 
That's normal Quake behavior. WinQuake and GLQuake will do the same thing. Files in a pak > files sitting around in the folder. 
Just recently discovered the "maps" and "mods" commands and tab completion by accident. Don't know if these are Quakespasm-specific features, but they're great!

A question, though: if I understand things correctly, the "maps" command lists all of the maps in whatever directory you're in (i.e. whatever "-game" option you've selected), as well as the maps in id1/maps. Is there a way of showing only the maps in the current mod directory? E.g. let's say I started up Quake with "-game retrojam1" is there a command for listing only the maps in the retrojam1/maps directory?

For that matter, is there a list of QS commands somewhere? 
Oh Wow... 
Didn't realize it was possible to use Quake with external controllers.

Will have to investigate this. 
List commands -> cmdlist
List settings -> cvarlist 
Thanks, Baker! 
I'm guessing the answer to my first question (whether it's possible to list just the maps from the current mod directory) is "no"... 
Segmentation Fault When Trying To Load A Particular Map? 
Not sure if this is a QS-related, mapping-related or perhaps even TrenchBroom-related issue, but: I've just made my own version of this test map by Rick, and when I try to load it in Quakespasm, QS just immediately quits and says "Segmentation fault". Other maps etc. still run fine.

(On another (possibly related?) note, I always have to add "-zone 4096" whenever I start up QS, otherwise I get

QUAKE ERROR: Z_Malloc: failed on allocation of 4100 bytes

I once read the "-zone 4096" tip somewhere and since it works, I've been using it ever since ... but I don't actually know what it does and was wondering whether it is normal that I can't even run the stock id maps without it. Does it mean there's something wrong with my QS installation?) 
it's been a few years, but iirc, zone is a special space in memory different from heap where textures and such go. in qs, zone is used for strings, so if you have a mod with a lot of text, it runs out of space to store it there. other engines use other parts of memory, so you don't always need more zone space. 
The fact that this even matters is another artefact of Quake's MS-DOS origins. No virtual memory, no multitasking. In Quake 2 "zone memory" is just a wrapper around malloc and the issue of potentially running out of space never even comes up. 
I'm guessing the answer to my first question (whether it's possible to list just the maps from the current mod directory) is "no"...
afaik that's correct, there's no way to list just the mod's maps.

The most common reason I get engine segfaults when loading maps is:
- if you have no brushes in worldspawn (all brushes in func_group) + compile with tyrutils (my version at least), the bsp will segfault when loaded in engine. That's a bug in tyrutils I haven't got around to tracking down.

If that's not the cause of your issue, post your map source and bsp, and QS version. :-)

Re: -zone 4096, it sets the size of a memory pool in the engine to 4096k (4MB). The latest QS release 0.91.0 does this by default. It seems wrong that you get a crash on launch without -zone 4096, though.
IIRC, QS keeps the mod/map filenames for tab completion in zone.
Are you compiling QS yourself btw? 
Yeah - I have a patch similar to your i3d tutorial on replacing zone with malloc. Should probably do that, as well as the cache one.. 
Thanks, Necros, Mh And Ericw 
ericw: Thanks, that was exactly it! I had only func_groups in that map, and when I ungrouped one of them, it worked. :)

I'm running QS 0.90.0, so I guess I need to update ... once I manage to remember how one does that. It's possible I compiled it from source (it's been a while), but if so then not without help. A lot of what I'm using I got up and running by following instructions on this board and elsewhere without really understanding the commands I'm typing.

Is it possible I did something wrong and that that's why it won't work without -zone 4096? 
Oh wait, can't I just download the first Linux precompiled, uhm, package (or whatever the correct term is) from and stick somewhere in my home directory? I think that's what I did to get 0.90.0. 
About Controller Support 
The xinput support is great!

The only thing I would suggest is acceleration functionality, where you don't instantly reach the top turning speed but rather ramp up to it over time, even when the stick is all the way in a direction. That way you can have fast turning but retain precision aiming. It really helps it feel more natural.

Pretty much every console shooter makes use of this. 
Zone Memory 
Heee, the zone memory system comes nearly straight from Doom. Fun times... 
Color For Dynamics Lights? 
Is it possible to add as an option? All I really want is orange lava balls, but it might be nice to have color light available for everything. 
All I really want is orange lava balls

What a marvelous sentence. 
No trojan warnings for me with the latest windows defender definitions (March 8). Weird. See if updating Defender fixes it (that worked last time, right?) 
Xinput/controller Support 
ericw... you have made america great again.

im off to do my happy dance. 
Needs splitscreen in order to receive his free handy j 
It would be great if this engine had an option, or default, so it handles stairs like Q3 does.
Or more so, really small edges, so when you jump up some stairs, you can't get stuck in them.

I know this isn't a thing in Q1, but it really improves the movement 
Yes Please 
That would improve gameplay on those maps with unclipped overcomplicated floor design. 
Is gooning with the player physics not a crossing a bit of a red line? 
Yes, I was thinking that too. But the reason why I choose to mention this is cause I don't think that would be crossing the line, this small specific "fix".

I can see if even more things were added, like double jump, ledge leaps, etc etc.
I think Id added this small thing so you wouldn't get stuck as easy when jumping too close to something.

Actually, I'm not sure what the difference really is, I mean, it's not like you are jumping close to a ledge in Q3 and magically just appear on top of it, but in Q3 you can jump around in stairs and not get stuck. 
it's not like you are jumping close to a ledge in Q3 and magically just appear on top of it

Not sure if it is related but q3dm13 mh? 
Maybe you are right, can't try it now.
In any case, it's not an issue in Q3 afaik =) 
Case Sensitive Autocomplete 
makes it harder to run some maps 
Quake Physics 
is a little twitchy. I personally hate that a floor connected to a slope will often stop you dead as you transition onto the slope. It's like there is a forcefield stopping you. 
In quake2 and darkplaces you can do this, i think in darkplaces it's called "air step." It's a nice feature because you won't get snagged on things like running across the floor grates in dm4.

I added it to Fitzquake early on, but deleted it before releasing because I realized it changes gameplay too much. The player can jump onto much higher crates with the feature -- ~40 without the fix, ~56 with the fix. Of course it's tunable, but the lower you tune it the less beneficial it is. 
Fifth, I noticed that in ad_zendar, when you climb the bricks at the start and go up the slope, there is an invisible wall blocking you at the top of the slope. It doesn't happen in DarkPlaces though - maybe LH fixed a bug in the collision code.

QS probably errs on the side of leaving everything vanilla; touching physics can have unintended side effects like metl mentioned. 
modern quakeworld servers have airstep enabled via the pm_airstep cvar.
even small airsteps of 1 or so should help work around the invisible barriers issue that results from bsp hull precision (tbh I don't actually remember quakeworld ever having that problem).

you could also only allow it when near to the ground which would fix steps (but also mean people could bunnyhop far too easily) without making ledges too easy.
that bunnyhop thing is why its not enabled by default in fte. I believe it is enabled by default in dp. 
I try my best to avoid using ramps in my maps specifically for this reason. I fudged the ramps in q-deck by having a "lip" to prevent getting caught when moving down the ramp. 
...this small specific "fix"...this small thing...

First rule of engine coding is that what may seem to be a small thing from a player's perspective quite often isn't.

Second rule is that this applies doubly so when it comes to the physics code.

Anything involving Quake physics code is almost definitely not a "small fix". It may seem small to you because you're just describing one single problem that only seems (to you) to happen in certain very specific circumstances. But the physics code has ways of blowing up spectacularly and innocuous-seeming changes in one place can have huge repercussions elsewhere. 
Go to E1M1 quad secret area. Stand under the screen with the world on it. Lower gravity a little. Jump. In a normal engine, you'll hit your head on nothing. In DarkPlaces you will jump unimpeded.

It is odd. 
That's a trigger_multiple with "health" "1". I guess it's solid? 
What is weird is load up ezQuake and -- like DarkPlaces --- you won't hit your head on the invisible trigger.

Go figure ...

So normal Quake = it is there.
Quakeworld/DarkPlaces = it is not there. 
Frogbots Support? 
Hey, I've been learning to play with bots in Q1 and it's come to my attention that compatibility with some bots is borked in QS.

Frogbots seem to be the best bots around but sadly they're one of the bots that don't work. Frogbots work fine in Fitz et cetera

Is it possible to add support back in to QS?

PS: The Xinput support is a godsend for my tired old wrist! Thank you. :) 
Auditory Funniness 
"Couldn't find a cdrip for track 0" the console tells me.

happens in aop, and in some custom maps like teacups. playback works fine *most* the time(?) so i am at a loss.

hoping this is just a case of operator error.

using win7 and the xinput build of qspasm. 
I Think You Can Ignore That 
I just checked and AOP's qc code sends a "svc_cdtrack" command to the engine requesting track 0, which is what causes that warning to print. Possibly QS should suppress that warning message, not sure.

btw, valid music tracks are 2-11 for the original soundtrack. You can enter a console command like "music track03" to start music manually, if a map doens't have it set up. 
Thanks Eric 
hmm. well ive got my naming convention correct, and my oggs in the proper dir. so perhaps i will just go with the manual playback for now. thank god for the console.

i wonder if the tracks playback sequentially in the game, or what. i need to find out. i guess that is the real problem now? not knowing what track an author has intended for their map. 
It doesn't sound like an issue with the engine or with your setup. It sounds like the mapper forgot to specify an appropriate music track. 
i wonder if the tracks playback sequentially in the game, or what. i need to find out. i guess that is the real problem now? not knowing what track an author has intended for their map.
They don't play sequentially; mappers can set a key on the worldspawn entity of their maps to specify a cdtrack.. I forget the key off hand. All of the original game maps do this.
e.g. the base maps e*m1 all use the more industrial sounding music track. 
I think mappers used to set the music track to track00 so that no music would play during their map even if a CD was in the drive...

I vaguely remember someone creating a track00 song so that one could listen to that instead if one liked (I think that was around the time Travail was released). 
it would be cool if there was a way for the user to specify a custom playback via autoexec.cfg ie

music_eXmX "trackXX"

manually playing tracks via the console is an acceptable workaround, i know 100% aop compatibility is not a huge community priority :D 
You could always bind keys to whatever tracks you like. Then it would only be a single keystroke instead of going into the console every map. :) 
// entity 0
"classname" "worldspawn"
"message" "Centerprints this text on map start"
"worldtype" "0" // specifies silver and gold key models
"sounds" "10" // specifies CD track to loop
"wad" "path to wad; path to wad" // paths to texture wads used
"fog" "0.025 0.50 0.50 0.50" // fog density and color
"sky" "skyboxname_" // specifies skybox to use 
I Just Found A Problem 
My main laptop has a partially broken keyboard; the C and D keys doesn't work. Due to this, to play Arcane Dimensions I've went to the Controls menu and configured QuakeSpasm 0.91.1 like this:
bind 2 +forward
bind w +back
bind q +moveleft
bind e +moveright

Now I'm using an external keyboard, so I've decided to reconfigure the movement controls back to the WASD keys. I've done this through the Controls menu again, but to rebind the "impulse 2" to the number 2 key I'd have to use the console.

And this is where the problem happens. Take a look at the ABNT2 keyboard layout. This is the keyboard layout for Brazilian keyboards. Also, remember that vanilla Quake engines does not require quotation marks around the command string for the bind command. But QuakeSpasm does, and instead of using a fixed American keyboard layout like vanilla Quake does, QuakeSpasm uses the actual keyboard layout from the OS.

Now put these factors together, and you'll understand the problem. QuakeSpasm made it impossible for me to rebind impulse commands through the console. If I don't put quotation marks, QuakeSpasm doesn't accept the binding, and when I try to type the quotation marks, QuakeSpasm toggles off the console - even if I type "disconnect" to get a full screen console (it switches to the main menu).

From an usability perspective, this is an awful situation. The only way to restore that binding without resetting everything else is to manually edit the config file.

Such problems must be predicted when designing input interfaces. Even the American keyboard layout can have problems in some cases, since the tilde character is used in some filepaths. The solution I've implemented in the latest versions of Makaqu is to not toggle off the console when pressing that key; the Esc key should be used instead.

Also, an additional user-friendliness feature can be to only toggle off the console by pressing that key if there's nothing typed in the commandline. That would prevent the user from starting a line with tildes, quotation marks or other stuff, but the user can work around that by inserting a space first. 
Not knowing history means being doomed to repeat it:

DarkPlaces 2007-03-15

"Changed default value of con_closeontoggleconsole cvar to 1, to put an end to the nearly 2 years of complaints about the tilde key not closing the console." 
That's an awesome bug report for the Quakespasm guys.

I'm just pointing out your suggestion was the most universally reviled feature that DarkPlaces ever had and people complained about it without end. 
That's why I also suggested to only close the console if the commandline is empty. 
Thanks for the detailed report Mankrip.. that does sound annoying. :(

I was hoping all keyboard layouts would have some unimportant character at the tilde key location, but double quotes break that assumption. That microsoft site looks really useful.

I'm not sure what fix we should take.
- Maybe 'Alt+console key' suppresses toggling the console, and types the character instead?
- a '-uslayout' command line option makes the keyboard act like a US layout, like vanilla Quake? 
I'm not sure what fix we should take.

Making the "toggleconsole" key not toggle the console if the console prompt isn't empty should be a good solution for everyone. When the prompt is empty, let it toggle as usual.

I've just created a tutorial for it, and implemented it in Retroquad. Worked perfectly:
User-friendly tilde typing in the console 
Making the "toggleconsole" key not toggle the console if the console prompt isn't empty
Sorry that is a really annoying feature in DP, that in order to close the console you have to clear the console line of anything typed! Having a single key toggle the console regardless is certainly a good feature. 
Why not just make it so the user can specify which key toggles the console?

Am I missing something? 
of course you can already do this. just edit the config.

bind "~" "toggleconsole"

replace ~ with your key of choice

So what's the bloomin' problem here? 
Kinn: Looks like ~ is hardcoded, even if you bind another key to toggleconsole. It was like that in winquake too. Not sure it's a bug, there could be some value in having it hardcoded in case a mod rebinds it by accident. Anyway, a cvar to move it completely to another key might be good.

I agree with sock, blocking the toggle when there is text typed annoys me in DP because the QS beahviour is muscle memory for me, I don't even think about it. 
Shift-escape is nice 
I Second Shift-Escape 
I agree with sock, blocking the toggle when there is text typed annoys me

How often does that really happen? In my case, it's almost never.

Is is okay to effectively punish some users in order to keep a behavior that is not a concrete need?

- Making a command work is a concrete need.
- Avoiding seldom small nuisances is a emotional need.

I give up. I don't debate things when emotion is put above reason. Nevermind the users who must enter commands that the default behavior doesn't allow them to. 
just hit escape if there's already text there.
shift+escape to get to the console, escape to close it. then keymaps make no difference.
ideally you shouldn't be going to the console very frequently anyway.

small note regarding tilde... it should actually be bind ` rather than bind ~, as the actual key is backtick rather than tilde.
note that this clearly leaves the console inaccessible with that keymap because backtick requires shift to get at it, and thus shift+escape to get at the console starts to sound so very much better.

the issue is also present on german keymaps, in a different form.

and wasd key layouts on french azerty keymaps just do not work. :P

and laptops... *shudder* 
How often does that really happen? In my case, it's almost never.

I imagine that lots of players are in the habit of toggling the console to cancel a command. Even if you offer a alternative, there's a cost to breaking a habit.

That's not to say that we should leave players with non-US keyboard layouts stranded, but having a fix behind a cvar which defaults to vanilla behaviour is probably the best of a bad bunch of options. 
QS handles WASD on AZERTY (and other non-qwerty layouts) by making in-game keys always use a US layout. The logic is that ingame you're not doing text entry, but using the keyboard like a joystick. Source engine does the same thing, so hopefully it's a sane approach.

IMHO changing the behaviour of the US layout is not acceptable because we are trying to keep the original feel, people got used to the nuances of how the ~ key behaves over the years.

There are various hacks possible, like we could probably disable the key-under-Esc as the toggleconsole key under some conditions (only use it if they key is "`"/"~" on your keyboard layout?) That seems ugly though. Still, having the Alt key suppress the console toggle in case you want to type that character seems most elegant atm.

I'm assuming people on non-US layouts actually like the fact that QS uses your native layout for text entry in the console? 
I'm used to toggling the console with "tilde" and certainly wouldn't want to get used to another system. And this is despite the fact that in QS it's already broken on a German keyboard layout where closing the console with the "tilde" key causes it to print a ^ character the next time you open it which then has to be deleted in order to type the command. To avoid it from happening the console has to be closed with ESC which I already consider a hassle.

Just had me thinking whether some sort of alias script could fix it as a workaround. But meh. 
Do Whatever You Want 
just as long as you provide a way to bring it back to stock. *you* may think your new way is awesome, but not everyone else does.
and yes, i fucking hate the dp console. i also hate any console that doesn't auto complete q+tab to quit. i don't care is there is a command higher up in the alphabetical order. 
Alias q quit 
Already have that for toggle entities. ;) 
I am so with you on the q<completion> hate. FTEQW does the same iirc. 
Different Styles 
How often does that really happen? In my case, it's almost never.
There are countless examples of console text being incomplete. Try creating RTLIGHT files for DP and see how often you need to work with the console. Checking for commands, trying to find out options and modifying fog parameters. It can take a while to tweak fog for a map and then there is trigger volume fog for AD!

I think you have to appreciate as a coder you are using the engine different to a level designer. It may not seem obvious, but the console is used a lot during development and testing of a map. 
I agree with him, i use it like crazy too, for getting fog right, doing good info_intermissions, checking coords in general with showpos, the various developer messages that get displayed during testing and you don't godmode and need to read them later...
Also, Negke, i feel you...^ 
there is trigger volume fog for AD!


also, setting up rtlights via console sucks, would be nice to have some sort of editor ui... 
Killpixel, did you even play it? Just kidding, ad_crucial shows it well, the fog triggers are ace, right?

Perfect for changing the mood when entering a lavacave or an area high up, it really does compliment the lighting and all..

Swampy uses them too, more subtle though. 
fog triggers in quake is not something I ever thought I would see so it never really registered... another reason to play through again! 
^ Bug 
finally tracked down what is going on.. I think it's a bug in SDL2.

We switch SDL2's "text input mode" on when the console is open and off when it closes. What's happening is, accent keys pressed when text input mode is OFF are still having an effect when we go into text input mode.
will look into this further and see if there's any fix possible.. 
I'm trying to play co-op with a friend from over the Atlantic, and we can't find any command to enable client side movement and firing prediction. This makes it very difficult for him to play. Darkplaces has it, (cl_movement), and of course ezquake does. Problem is that those clients aren't compatible with a lot of maps.

Is there one? If not, I'm requesting it for future version.

Ooh, very nice client, I'm running into issues with it too though. Teleports that should take me to another map are just restarting the map for me. It's working well for my friend on linux though. I guess I'll take this elsewhere though as it's not related to Quakespasm. Thanks. 
Samelevel 0 
(cvar is used only by the gamecode - even vanilla, so applies to quakespasm too. you probably have that issue due to some dodgy third-party qw deathmatch-only config.) 
Thank you very much. :) 
Latest windows dev build has the fix for ^ getting inserted in the console on German keyboard layouts: 
could you please fix also the OSX version? 
I haven't seen this bug on OS X.

IIRC, I tested the latest stable build, 0.91.0, SDL2 version. OSX 10.11. German keyboard layout.

What configuration is it happening with for you? 
EricW ... You Are Right! 
I�ve just added --> bind "^" "toggle console" in the config.cfg and it works .. sorry for that! 
I'm adding some functionality to Quakespasm for qexpo, I have some questions regarding the engine. Is your email in the your profile here correct? Can I hit you up with some questions there? 
Yep, Sure 
Mousewheel Weapon Switching Bug? 
For some reason I can only switch forward, but not back -- i.e. rolling the mousewheel forward will e.g. switch from shotgun to super shotgun, but rolling it backwards does nothing.

Oddly, this does not happen when playing Arcane Dimensions. In AD, I can switch in both directions. In id1, though, I can only switch in one direction.

I'm on Linux, running QS 0.91.0. 
This is a mod issue, some mods do not support the impulse that cycles backwards through the weapons. It's not actually an engine feature! 
This shouldn't happen with clean and up to date id1 though. 
Err, how do I know if my id1 is up to date? 
Thanks for the responses, by the way.

metlslime, I'm not sure if I understand your reply correctly, but I didn't mean that it was an issue I was encountering when playing with mods (unless one counts id1 as a mod). I just added the bit about AD because I thought it might be relevant that it does work under AD.

I was under the impression that cycling through weapons in both directions should be possible when playing in standard id1 (as dwere's response seems to imply as well).

But now I'm a little confused... 
total_newbie, I think either you don't have quake patched to 1.06, or the mousewheel down isn't bound in your id1/config.cfg.

Under id1, try "impulse 12" in the console, then close the console. If it doesn't switch to the previous weapon, then you must be missing the 1.06 patch.

The patch is here but it's DOS-only unfortunately: 
Thanks for the response, ericw.

Turns out I am using an out-of-date set of pak files, but I can't get the linked patch to work.

Would it not suffice to download an up-to-date pak0.pak (i.e. the shareware pak) and replace mine with it? The readme from the patch you linked to suggests that it's just the pak0.pak that gets updated anyway:

Step 2: Run the file 'patch.exe' from your Quake directory, which will alter
your quakeid1pak0.pak file.

Or does it do something to the pak1.pak too? 
That Last Sentence Wasn't Supposed To Be A Quote. 
try updating pak0.pak. Is there a zip on quaddicted? I guess this should be covered on: which currently doesn't say anything about patching.

(hmm, weird my pak0.pak - from Steam, I think - doesn't match the md5 sum listed there. the pak1.pak does though.) 
Found it here via a google search:

Haven't checked to see if Quaddicted has it too.

Anyway, that seems to have worked. :) Here's hoping I haven't inadvertently broken something. 
Just checked and both my pak files have md5sums matching the ones on Quaddicted. So I seem to be up to date -- finally. :)

Thanks for all your help. 
Optimization On Raspberry Pi 
The quakespasm engine does not seem to work nicely on the raspberry pi. It has slow framerates and broken geometry. Oddly, the more demanding darkplaces engine works smoothly. Any clue why this is happening? 
QS needs desktop OpenGL, whereas DP is able to use OpenGL ES.

It sounds like desktop OpenGL has been software emulated only until recently, see:

Do you have a Pi2? Try enabling the experimental hw-accelereated OpenGL option. 
Already Did That 
The experimental drivers do help with qs, but effects like dynamic lights slow it down, and some other factors I haven't pinpointed yet. Would it be hard to allow OpenGL ES with qs? 
Ok, Interesting 
adding full GLES support is possible, but relatively a lot of work.

there may be some simple tweaks to the lightmap format that would fix slowdowns with dynamic lights.. but we need some developer with a RPi to do it. 
Would it be hard to allow OpenGL ES with qs?

It would need a rewrite of much of the renderer because it still uses a lot of glBegin/glEnd calls which don't even exist in ES. BSPs and MDLs IIRC use vertex arrays/VBOs but they're the easy ones to port. 
It would probably be worth it on the long run but sacrifice compatibility for some ancient hardware maybe? 
The network drivers for vanilla have this class-like structure with function pointers that are filled with the proper functions for a specific net driver. I don't currently see a reason why we couldn't use such a mechanism to incorporate multiple rendering engines. (id Tech 2, the engine for Quake II, actually uses that).

Also, if you're interested, I had to implement ES on the iOS VR target of my port... might guve you some useful pointers :) 
GLES1 pretty much just requires using vertex arrays instead of glBegin. The rest is basically just omissions. It should be easy enough to update quakespasm to use this, but you'll probably want to handle batching properly to compensate for the batch-merging work desktop drivers do with small glbegin batches.

GLES2 requires glsl too, which is a little bit more messy, but also offers significant speedups.

GLES3 is a strict superset of GLES2, thankfully.

FTE's gl renderer dates back to when glsl was still new (and slower). as a result it still copes just fine with glsl on some times and not others (also, yay q3 shaders).
tbh the only significant difference is whether glsl is available or not. There's a few extra limitations from using GLES, but tbh those things should probably be avoided even on desktop GL, so its not a huge problem really.
Of course, this is assuming you're willing to have gl1.1 as a minimum requirement - this may mean you need to use a quake3 minidriver instead of an older one, so I don't personally see this as a serious issue, even for those old cards. 
Just Buy A Pi 
If you need to develop on one, they are like 35$ dude. I have no idea on your linux ability, but it shouldn't take long to learn how to code on one. Seriously, the OS comes with gcc and g++, it's super easy to compile anything. 
Just Buy A Pi 
If you need to develop on one, they are like 35$ dude. I have no idea on your linux ability, but it shouldn't take long to learn how to code on one. Seriously, the OS comes with gcc and g++, it's super easy to compile anything. 
Got A Duped Post, Please Remove Post 2048 
All developers have their own interests and own things they are interested in contributing to a free project.

ericw may or may not be interested in this task.

It sounded like he was inviting someone else to step up the plate and pursue this item of interest.

Everyone likes to armchair manage what someone else "needs to do", but really free projects depend on new volunteers.

/One opinion, my opinions are often wrong. 
I Have A Pi 
and I really have no idea how to bloody use it. I'm sure if I struggle hard enough I could offer up some testing... 
Seriously, the OS comes with gcc and g++, it's super easy to compile anything.

Yeah, type "make" and you can compile anything.


Let's get serious. Compiling stuff is the single most basic part of the build process. It's expected to be easy and it's expected to work. So the part of the toolchain that's supposed to be easy is easy? Big swinging mickey. Gimme decent debug tools and we can start talking. 
I wish compiling on OS X was easy. My other poject is a pita on El Capitan which i'll have to solve some time soon. They symlink gcc to freaking clang! and have separated the command line tools from Xcode in some mess i have to resolve. Mebee it's not too hard. 
Xcode is good. Xcode is your friend. Accept the Xcode. Let it flow through you.</spooky> 
You'll get the command-line tools if you install Xcode.

You can also get the command-line tools by running "xcode-select --install". In fact you should do that even if you've installed Xcode, since that command will also set up some default Unix/Linux-y paths for the linker and preprocessor (like paying attention to /usr/local/lib and /usr/local/include by default). 
Mouse Stuttering? 
Since an arm injury a few years ago I've only been able to play with a controller.

Today, feeling good, I thought I'd try a mouse in QS again in anticipation for the new Arcane Dimensions.

Sadly, I found that mouse movement 'jerked' or 'stuttered' every few frames or so. This doesn't happen when I use a controller.

Looking around I found some threads pertaining to other games having the same issue. It seems to be an SDL thing.

Is there a way to set raw mouse input in QS?
Does anyone else have this issue?

I have a Logitech g700s mouse on a Win 7 x64 PC with GTX 780 and i7 4770k.

And, no, it's not lag because my mouse is wireless! The mouse is as smooth as butter in other games. :) 
Are you using quakespasm.exe or quakespasm-sdl2.exe? (or the dev builds from ?)

Try the -sdl2.exe one, it should use raw mouse input.

Another thing to try is setting "host_maxfps 60".

(I have this problem on OS X, where mouse events only arrive at 60Hz, and there is no raw mouse input in SDL1/2 on OS X.) 
Thanks :) 
I always use the most up to date dev builds (in this case 1308 and 1310).

Setting "host_maxfps 60" seems to have done the trick though. I had host maxfps set to 72. I presumed, having a 144Hz monitor that half the refresh rate would result in a more solid performance than 60Hz. You live and learn, I suppose.

By the way, while looking around for this issue I found that you're using an older version of the SDL2.dll. Is there any reason for that? Just curious. :) 
I usually set my host_maxfps to 150. 
Problem with variable host_maxfps in single-player Quake is that so much of the engine is FPS-dependent, and often in ways that are gameplay-breaking. 
Ok, glad to hear host_maxfps 60 helped. That suggests QS is only getting data from your mouse at 60Hz which is weird :-(. Try host_maxfps 150 as Fifth mentioned too, although I'm not sure how much physics starts to mess up at 150?

I found that you're using an older version of the SDL2.dll
It's a custom build by szo, made from the latest release (2.0.4) + some patches, details here.

MH - yeah, trying your Inside3d tutorial on decoupling the server / client FPS is on my wishlist. 
Not noticed physics messing up at 150. I find Quake literally unplayable below my monitor refresh rate of 144. I get headaches and nausea. 
I need to get a 144Hz monitor! 
Anything Greater Than 60 
I have a monitor that goes to 100Hz, and even that is a night/day difference. Highly recommended! 
MH - yeah, trying your Inside3d tutorial on decoupling the server / client FPS is on my wishlist.

I've better code since, unreleased but if you're ever looking at this I can give you a code dump. 
In DirectQ, which had client/server decoupling if you turned left or right using the keyboard while moving forward you had jerky movement, like a mild stutter.

DarkPlaces and the QW clients don't, was something I wanted to get to the bottom of.

In 2014, I spent some time trying to implement client/server independence before ultimately moving it to the back of the list because that would have just been a piece of a more ambitious goal like implementing DPP7 or some sort of predictive protocol for better coop.

(Which itself is quite a laundry list -- delta compression, server timestamps, baseline, acks, etc. etc. and of course implementing IPv6 and connectionless connections.)

Merely implementing client/server independence DirectQ style is no small task :( Timing nuances are everywhere, even in a few places they have no reasonable place existing.

Spike takes timing to even more of an extreme by creating a separate thread for the server.

/Pandora's box 
But yeah, when I made a run at it, I had all of mh's notes from insideqc I could find on-screen for reference. 
I'd say multiple controller support and splitscreen in a decent engine is more important ;) 
its DP that can run the server on a different thread. the real issue with running the server on a different thread is that of cvars and commands. cvar_set would require a full-blown sync to ensure the other thread isn't reading cvars that are about to go away, while commands also need some sort of sync - which is not what you want with +forward etc.
on the other hand, running the server in an entirely different process skips over ALL of that, with more understandable behaviour for the user. much fewer mutexes, much less likely to break other stuff, but more annoying to configure.

either way your client needs to be able to properly cope with dropped/delayed packets. 
In DirectQ, which had client/server decoupling if you turned left or right using the keyboard while moving forward you had jerky movement, like a mild stutter.

Part of the problem there was that I'd made a huge mess of the timer code well before then. In earlier versions you can timescale down and see how atrociously jerky it really is, and it took me a long time and many revisions to get things back to something that even approached correct. I don't think I was ever 100% successful either, and I didn't really understand the subtleties of the timer code at the time. 
Latest Version Bug? 
prev weapon bind does not seem to work for some reason. Anyone else getting this? 
Prev weapon is controlled by QuakeC and QuakeC only. Some mods don't support the prev weapon impulse, one example is Duke of Ontranto and I think another example is Castle of Koohoo.

(Mark V uses the Requiem engine cheat to make prev weapon available in about any mod, but it isn't 100% fullproof and at least one mod --- Neruins --- it doesn't work "right" at all) 
N64 Style Rumble Support? 
I really, really appreciate the Xinput controller support added to recent builds of QS but I was wondering if it would at all be possible to add rumble support?

My first foray into Quake was on the good old N64. Two things I really miss from that version is centred message text (though I don't think you're interested in adding that option) and the other is the Rumble Pak.

It adds some real heft to the weapon fire. 
Splitscreen Support 
please... please please please......

(obvs you'd need to have support for more than 1 pad) 
This has come up quite a few times, and I think Spike has given some good discussions on what's involved, but one thing to realise is that this:

(obvs you'd need to have support for more than 1 pad)

Isn't true.

You need a hell of a lot more.

You need to recode the engine to be able to support 2 or more clients, running concurrently, in the same process. 
And considering how there are more global variables in the Quake engine than atoms in our solar system, that is going to be a huuuge, collosal task.

I wonder, if that's the case, if we should consider instead recoding the engine completely, from scratch. And while we're at it, doing away with the hardcoded engine limits. 
@Izhido Re:Limits 
Raised limits have long been standardized -- and mostly don't present a problem in modern times.

What Quakespasm uses as limits is essentially the standard. Those limits are ...

1) BSP2 for map limits
2) For non-map limits, the limits are nearly unchanged from FitzQuake 0.85 (with 2 small modifications, if I recall, max packet size and visedicts)

Protocol 666 --- written by metlslime in FitzQuake 0.85 in 2009. Supercedes protocol 15. If there were awards in Quake, metlslime would have won something like "Best Modification of The Decade" or something. --- comparing the FitzQuake 0.85 vs. FitzQuake 0.80 source codes. (summary of protocol 666 changes)

BSP2 --- written by MH in 2011 or 2012. Similarly outstanding like protocol 666.

Spike made a BSP2 patch of Mark V, which was used to easily port BSP2 to Quakespasm ... <--- changes for BSP2

... and later probably the basis of BSP2 support in other engines like Super8 and Qrack, if I recall correctly. DarkPlaces and FTE support BSP2 as well. BSP2 was written by mh for the RemakeQuake engine. 
Requiem Impulse 12 Hack 
I was able to get prev weap to work with ne_ruins a while ago based on reQuiem. It may require omission of quaketest compatibility or similar to obtain this result. 
The Requiem impulse 12 hack will crash neruins. Give yourself all weapons and ammo, then use impulse 12 a whole bunch. *boom* 
neruins doesn't need a impulse 12 hack. It has impulse 12 support for prev weapon in the progs. Nevertheless, the Requiem impulse 12 hack explodes on neruins. 
ne_ruins is a strange release. It's the only mod that screws with my movement speed settings, maybe except total conversions like Malice.

No, wait, I think I caught OpenQuartz doing something similar. 
Impulse 12... 
try "give all" instead.. maybe this works.. though.. 
What's wrong with cycle reverse in ne_ruins? I always use 1.6 progs which has the reverse cycle function. 
Nothing is wrong with ne_ruins. The Requiem impulse 12 hack has a certain method of trying to determine whether or not a mod supports impulse 12 previous weapon and some it depends on QuakeC function names.

In the case of ne_ruins, it (falsely) concludes that ne_ruins doesn't have impulse 12 support and then does forced progs hacky kung-fu that explodes.

The only thing remarkable about ne_ruins is that it is first known mainstream mod that the impulse 12 hack doesn't play nice with.

Mark V has a cvar named "sv_fix_no_impulse12_exceptions" and the value is "ne_ruins" (supports comma delimited list i.e. "ne_ruins,kinns_new_sp" would work) --- so as you can imagine ne_ruins doesn't crash Mark V any more. 
interesting. maybe because i refactored a lot of the impulse handling and renamed the W_WeaponFrame method to player_processInput?
what do you check for to determine that there isn't support? 
a) It looks for an ImpulseCommands function. If it cannot find one, assumes there is impulse 12 support.

b) Found an ImpulseCommands function. Check for a statement that checks to see if self.impulse == 12. If found one, assumes there is impulse 12 support, otherwise assumes there is not impulse 12 support.

ne_ruins apparently has an ImpulseCommands function but doesn't check for impulse 12 there. 
"sv_fix_no_impulse12_exceptions" drips off the tounge like "r_nolerp_list", but could the approach be a whitelist instead of a blacklist? That is, a list of the old classic maps that need it.

The reQuiem impulse 12 hack is missing a 'default' fall-through during switch. The prev weap crash seems to be solved by coding the default to axe. But now next weap will fail... because it's not really an axe, it's a book or something... 
Well, there have to be a finite number of single player mods without impulse 12 support.

And in theory, if someone had the entire Quaddicted archive, could code an engine to switch gamedir to each gamedir and if impulse 12 support was not detected, write it to a log along with maybe ...

a) the CRC16 (what Quake uses), the filesize in bytes and maybe throw in a MD5 (because GitHub uses MD5 for file comparison and Linus Torvalds seems to how versioning down to a science)
b) and the file date and time from the archive.

1) Koohoo
2) Stuff using CustEnts like about all of Fat Controller's stuff
3) Probably a few random ones where the author could write QuakeC but used a bad progs base

Then you have to determine what dumb progs exist like Quake Progs 1.01 --- or is it 1.02? --- but catch the ones that aren't 1.06.

So yeah, whitelisting would work very well --- eventually. And would be the best solution long term. 
Ok, I see, instead of checking is self.impulse == 12, i assigned self.impulse to a local float _impulse and then check that instead. :(

void() ImpulseCommands =
local float _impulse;

_impulse = self.impulse;

if (_impulse >= 1 && _impulse <= 8 || _impulse == 250)
W_ChangeWeapon ();

else if (_impulse == 9)
CheatCommand ();
else if (_impulse == 10)
CycleWeaponCommand ();
else if (_impulse == 11)
ServerflagsCommand ();
else if (_impulse == 12)
CycleWeaponReverseCommand ();
Stumbled on a strange glitch while testing a new palette.

Re-entering the map didn't change anything, but after restarting the game everything was back to normal. Only the torches, flames and hanging zombies seemed to be affected.

The way the zombies looked like random lumps of gore, twitching and extending their "tendrils" in semi-random directions, actually was pretty cool.

I think it's an interesting idea for a new decoration, or an environmental hazard. Only if properly executed, of course.

Version 0.91.0, non-SDL2. Nothing suspicious in stdout. 
Weird, I haven't seen that since the new mdl renderer was still being ironed out.

If you find a way to reproduce it that would be great, but I assume it's an unlikely combination of conditions to trigger the bug. 
Hipnotic Decals... 
Is there a way to turn them off? I think that those 1 hole decals are super ugly and don't look right in any way shape of form, so if there is a way to turn them off, that would be nice to know. (And if not, it would maybe be nice to include a way, though it might be a bit of a niche request) 
I agree that the SoA decals look rougher than a badger's behind, but they are purely QC-based so the only way to turn them off would be for someone to create a modified progs.dat 
or you could stamp over the sprite by making an invisible sprite with the same name, and putting in (for example) pak1.pak in the hipnotic folder 
That might actually be worth a shot. Good idea. 
Just did a quick replacement and it works like a charm. Here is a zip with the PAK for anyone who wants it. 
Nice One 
Quakespasm 0.92.0 Released 
Very Nice Release 
And thank you very much for your support in providing compatibility with oms3. I know its old news by now, but I appreciate all the steps you took to make it work. :) 
Couple of quick questions.

I'm trying to decide if I should add my IRC code to this version to release for QExpo rather than version 0.91.0.

Does it offer anything in the way of stability or bugfixes beyond what is stated in the notes?

Are you planning on releasing this for QExpo, and if so, do you want me to delay the official release of my code? 
The changelog is pretty much it: no other notable differences between 0.91.0 and 0.92.0. As for the qexpo thing, I have no interest in that. 
Controller Support Woes 
Hello, the latest quakespasm appears to be totally unresponsive to my controller.

Controller is a bog standard official "XBox 360 Controller for Windows", with up-to-date drivers. It also works fine on other games I use it for.

I have also done what it says in the readme and downloaded the gamecontrollerdb.txt file to the quake folder, but it does not help.

Any idea how I could troubleshoot this problem? 
@Kinn make sure to run quakespasm-sdl2.exe, only that .exe has controller support.

I have the same controller (wired version), tested it on Windows 10 and OS X so far.

Also, check for any "joystick missing controller mappings" or "failed to open controller" messages in the console. 
Cheers - that's it - mea culpa :}

Btw it's AWESOME - default sensitivities etc. are pretty much spot on - now I can sit back in a comfy chair and play quake and its the bestest thing in the world ever :D 
Great :) 
Kinn U Make Me Crie. 
ur just jelli u don't have the gamepad skillz. 
Doom was released not long after I got my first computer and it was one of the first PC games I played. Before it came out all I had on the PC was flight simulators and space combat game, so for the first year I played Doom I used a Thrustmaster joystick as the controller. 
Lol U Guys 
Honestly, after 20+ years of playing console games I don't find controllers awkward to use in any way. I prefer them to mouse & keyboard because the level of comfort is incomparable. The only time I'd want to use a mouse & kb is for games that have complex controls like mmo games or rts or whatever. 
Controller Support 
in QS and other engines has been lacking for quite a while. As superior as KB+M is there is still a problem with that setup for playing games on a couch in front of the telly box.

Also, wheres my splitscreen (yes, I am a pestering bastard but I fully intend on using this with my friends) 
Rip Kinn_sp3 
Rip Kinn_sp3

you know when there's a band you like, and then they do nothing for over a decade, but then suddenly you hear they've got a new single coming out, and ur all like "omg holy shit that band i like is back" and everyones excited and then the single comes out and you buy it and you listen to it and first you're not sure what to think of it and you look at your friend and he also has the same "i'm not sure what to make of this" look on his face and you listen to it again, and you sort of pretend to like it this time but deep down you're kinda thinking "what the fuck is this".

Just sayin. 
Fuck Off Dude 
I don't really have anything to add to that comment so instead here's a gif of a pig taking a cat for a walk: 
I mean, I kinda enjoyed Kinn during my teenage rebellion phase. But nowadays it's just lost its appeal... 
Minor Buglet 
I seem to 100% of the time get a black screen when I start up the sdl2 version. To fix it, I alt-tab to desktop, then alt-tab into the game again.

Doesn't happen with the non-sdl2 version.

Anyone else getting this?

Windows 10
NVIDIA GeForce GTX 765M 
Anyone else getting this?

I'm guessing that you have an Optimus laptop from the "M" in your GPU model number.

I was able to 100% reproduce this on a similar system, but only when running under the Intel graphics card. When running under the NVIDIA (either by right-clicking and selecting "Run with graphics processor" or by creating a profile in the NV control panel) it behaved properly. 
Whoa That's It 
Holy shit - I had no idea I was running it all this time on my crappy intel card thing. Whoa. Cheers! 
On Windows the NvOptimusEnablement (there's an AMD equivalent too) export can be set to fix this:

Only thing is, for some rendering workloads the Intel is actually the faster GPU in this kind of configuration - especially if it's a HD4000 or better. Quake falls into this category; what happens is that Optimus with the NV must transfer the framebuffer to the Intel for presenting, but Quake rendering is so lightweight that doing the transfer takes longer than just doing everything on the Intel. 
Feature Request 
Not sure if this has already been requested, but it'd be a real time saver I think.

Predictive text for commands. Just like on swyftkey or similar, you type a letter and behind it the engine fills in, in grey, any possible command pertaining to that letter.

If you hit enter then it completes the command in text, if not then you carry on typing as normal.

Adding custom keybinds is all very well... but if prediction was a base feature then it'd remove a lot of this piddling about for most if not all users.

Just a thought. 
it exists, start typing something then press tab 
Not exactly what I meant though - I know what the commands are already. 
keep hitting tab and you won't have to type the rest 
ijed is learning about tab completion in 2016?

fte does exactly what ijed is talking about with the show the command before you type it thing.

In theory it sounds great.
In practice it is a horror.

It doesn't know what you are going to type and instead annoys the F out of you autocompleting something random you aren't looking for --- and in doing so --- ruining your train of thought. 
(Hehe, I should have softened that up a bit and wordsmithed it a little before clicking submit.

The effort to write that feature is great, but the way an advanced engine will have 1000 cvars and commands and most of them are things an average user is never looking for --- this causes the end result to be undesirable.

In my opinion ;-) ... 
Feature Request : Random Map Command 
I'm still requesting this feature for Quakespasm : the ability to quick load a random map from the whole list by typing a simple command in the console.

Please, I need this, built-in ! 
Open host_cmd.c in the Quakespasm source and find Host_Map_f --- there is a list called "extralevels" and you could make it pick a random one from that list if you type "map random" in the console.

So edit it to do that and then recompile Quakespasm and you are all set. 
Fair Dos 
The Swyftkey thing I mentioned is a downloadable keyboard for mobile which manages not to be annoying.

But yeah, not exactly top of my christmas list :) 
I'd Forgotten About Barnak 
Why this meprisable attitude ?

As a player of Quake, I'm simply asking for a usefull feature, so what's wrong with my request ? 
R_shadows 1 
I recently discovered that it actually looks pretty nice. But maybe the shadows should be one-sided? Since they're supposed to fall on the floor, I see no reason for them to be visible from below. It only contributes to the amount of situations when they look weird. 
Just saw this...

Axel Gneiting, a programmer at id Software, has ported Quakespasm to Vulkan:

QuakeSpasm Shows Me Just A Screen Full Of Grey On Any Map 
Whole screen grey, except for the status bar. any map, even e.g. dm4. Does not happen in fitzquake. Any idea? 
Argh.. :(

Would you mind launching with the "-condebug" flag and uploading the generated "qconsole.log" file?

You can disable some rendering code changes with "-noglsl" (alias models, gamma correction) or "-novbo" (new world renderer), one of those may help. 
emailed you the log. neither option appears to change the situation. 
So what generation of graphics cards does one have to be using to get the benefits of Vulkan - or does it not work like that? 
its not meant to work like that.
its meant to be that if vulkan works on your gpu, then your cpu can skip a whole lot of work. your gpu might take a bit longer, but it's probably going to be idle anyway, and with vulkan its supposed to be much harder to inadvertantly cause the cpu+gpu to sync up.

in practise, there's a number of overheads due to the system compositor, and nvidia (at least) is doing a terrible job at overcoming those.
this results in double the framerate at low resolutions (yay!), and half the framerate at high resolutions (oh noes!).
however, I'm also using quake as a benchmark (few other games expect to achieve 3000fps) so take what I'm saying with a pinch of salt, at least when applied to other games.
Games with a lot more 'things' moving around are the ones that will benefit most, so it really depends how dynamic your various scenes are.

personally, the nicest thing about vulkan is not having to worry about falling back to gl1.1 :) 
Thanks, nothing obvious in the log.
The only other thing that comes to mind is try both quakespasm.exe (SDL 1.2) and quakespasm-sdl2.exe. Also might be worth backing up and deleting id1/config.cfg. 
Vulkan has little to offer Quake because a typical Quake workload just isn't heavy enough to benefit from what Vulkan does offer. It looks more like it's just a fun project for the guy at id: a way for him to learn Vulkan and give something cool to the community.

While it is true that most Quake engines (those based on/similar to the original renderer) are CPU-bound, that's because of the way the API is being used, not the API being used. Lots of small draw calls with glBegin/glEnd, sync points all over the place, animating on the CPU then pushing data to the GPU every frame; it's all a combination of the worst possible things you can do on 2004+ hardware. Try to do the same under Vulkan and you'll probably end up even worse. On the other hand, fix the way the API is used and Quake is no longer CPU-bound so Vulkan is unnecessary. 
Colored Dead Bodies In QS 
Dead Bodies 
That's a long standing GLQuake bug.

In summary: entity slot 0 is reserved for the world. Entity slots 1 to 16 are for players. Entity slots 17 onwards are for everything else.

When a player is killed, they move from one of the player slots to one of the "everything else" slots. Their old player slot then becomes free for them to respawn into (or for another player to join into, I guess). That way the player slots don't get filled up very quickly with dead bodies.

How GLQuake colours a player model is that it checks what entity slot number it's in. If it's in one of the player slots (1 to 16) it will apply colormapping to a copy of the player model texture, re-upload that to the GPU, then use it instead of the regular player texture.

And that's how it happens: the entity moves outside of the player slots, so GLQuake no longer colours it.

IIRC this is fixable but if an engine still uses the old colormapping code there may be some more extensive rewriting needed to make it run well. 
Quakespasm could be modified to do so borrowing Mark V code which has had the dead bodies colored for nearly 4 years.

The changes to do this are located in this source code and marked "#ifdef SUPPORTS_COLORMAPPING_EVERYTHING" the source. Mostly touches cl_parse.c, cl_main.c and gl_model.c are where the main changes are.

Would be a pretty straightforward code grab and the code has essentially remained unchanged for a very long time (one change since was a simple 1-liner if I recall for mods that set an invalid skin #, which I think ericw pointed out).

The remedy to fix the GLQuake "bug" is to watch for any model or colormap change in cl_parse.c for all entities.

If one happens, color up a skin for the model + color combo and store it off. On new level or gamedir change, clear the skins queue. 
sometimes I think the cure isn't any better, with spies in TF changing their appearance mid-game, having one of their dead bodies in your base makes it trivial to figure out what they now look like. 
sometimes I think the cure isn't any better, with spies in TF changing their appearance mid-game, having one of their dead bodies in your base makes it trivial to figure out what they now look like.

I can't remember if the same would happen in software Quake or not.

Either way, this is one of those issues where gameplay in a mod depends on what is clearly an engine bug. Should a fix to an engine bug be allowed to break (or otherwise have a lesser impact on) a mod? Or should it be fixed in the mod code instead? And given that the engine code change is client-side, is it even appropriate for the mod to have been depending on the bug in the first place?

Questions, questions. 
disconnect, change team, etc, all those corpses change colours too, which is weeeeird.
That said, its also weeeeird for corpses to change simply because the player respawned then.

if .colormap carried the top+bottom colours explicitly then that would solve the issue for nq.
You can work around that using DP_SV_CLIENTCOLORS and DP_ENT_CUSTOMCOLORMAP, eg:
That said, this won't help with qw skins or richer colours (unless you wanted to send a whole lot of extra data).
Of course, because mods use .colormap, and its part of every single quake protocol, there'll always be somewhere that is still b0rked - even if you did network the skin names for every single entity. 
Aren't legacy data formats exciting? 
First of all, I did not do vkQuake because I wanted to "learn Vulkan". I already did the Doom port before, which of course was much more involved.

Also you are wrong about the CPU overhead. This is exactly the kind of stuff that is much faster with Vulkan - not that it matters for Quake.

vkQuake serves as an example of how to properly write Vulkan applications. Even with something as simple as Quake there are basics which are not trivial. 
vkQuake serves as an example of how to properly write Vulkan applications
you're not using texture arrays at all nor descriptor arrays, you've no tripplebuffering, you're using an entire descriptor set for each texture of each material, you still have each texture in its own allocation.
its that last one especially that makes it look like an engine that someone's learning from (or they're just lazy, like me).
either way, I'd suggest fixing those before claiming that its 'properly written'.
Sorry, but that irked me enough that I felt I had to say something.
additionally, if you really want to make something that is useful for other people to learn from, then use a friggin license that they *CAN* use. The GPL sucks. Keeping your code separate from quakespasm's code and under a different license should do it.

Also you are wrong about the CPU overhead. This is exactly the kind of stuff that is much faster with Vulkan - not that it matters for Quake.
when running fullscreen at 1920*1080, quakespasm is about 10% faster than vkquake for me.
FTEQW's vk renderer gets about 1200 fps vs gl's 1800 vs d3d9's 3000 fps, when running at that same resolution and a single preset that doesn't have stuff that one of those renderers doesn't support (I'm not going to give numbers for vkquake here because I don't really want to start a pissing contest over engines, yet...).
(small note, this is fullscreen rather than at 640*480, so its subject to whatever excessive buffer copying nvidia are doing behind the scenes. hopefully this will be less of an issue when nvidia actually get their act together)
So yes, switching API will indeed increase your framerate!... but not by switching to vulkan for most users right now. At the same time, rewriting how the API is used will increase the framerate significantly.
I knocked up some crappy opengl renderer a while back when I was trying to familiarise myself with more recent opengl extensions without having to care about older gpus: (jam6_daya)
obviously that specific example has no entities nor server logic etc, a pure renderer. trying to match settings I can push fte's gl2 renderer to 2200fps, fte's vulkan renderer can reach 2600fps (this doesn't conflict with the gl vs vk comparison thanks to 640*480 not suffering so much from nvidia's deficiencies). comparitively vkquake does indeed get a noticably higher framerate than quakespasm but its still severely CPU limited because neither are actually making the most of their rendering API.
Imho, mh's comment about the CPU overhead is perfectly valid. Just switching APIs *can* help, but actually properly using the API you already have will still be a bigger and more reliable boost (unless you do both, but then you have the above issues with nvidia's tripple-copy inefficiencies).
Who cares when you're already pulling more than 200fps, right?

put simply, if you want high framerates, go with d3d. even on nvidia. you can call that the microsoft tax if you want, but for me linux wasn't actually any different - even just enabling bloom in linux+vulkan dropped the framerate into the hundreds (which is barely felt on windows).
vulkan might be the future, but its certainly not the present - yet.
here's hoping the drivers stop being shit some time soon.

(I'd have started on a d3d12 renderer already if it had not meant opening myself up to all the win10 malware, iiuc the drivers are more mature so shouldn't have the defects I've been talking about). 
Obviously this is not done yet. 
Also you are not allowed to change the license. The original Quake was released under GPL, so QuakeSpasm *HAS* to be GPL and also vkQuake *HAS* to be GPL.

If I used BSD I would be in direct violation with that.

I'm not going to argue with you about the other stuff. 
Unless... You somehow managed to do a full engine rewrite with not one single line copied from the original one.

And I'm not convinced it wouldn't be possible... Except for the most trivial examples, there are many many many ways to write similar software... 
It's obviously not the scope of vkQuake to rewrite Quake. 
I have to admit that when I first looked over the code what I saw led me to think that it was being used for learning. Since that's evidently not the case that was clearly my own misunderstanding.

That aside, and squabbles about API aside (which are interesting to discuss nonetheless), I still think this is cool. It's fantastic to have something where you can go in, look at a bunch of GL code and see the Vulkan code needed for the very same thing side-by-side.

I'm not sure if that's the intention, but intended or not it's cool that it exists.

Learning from code is obviously different to copy/pasting it. I've no objections to GPL on that count, but would note that since id own the original Quake code a new release of the original code under a different license should have been possible. Of course such a release would have missed out on the years of bugfixing and features added...

It's also fair to say that the state of Quake's renderer is such that any attempt to properly use an API is effectively going to be a rewrite. At which stage being able to do a direct comparison between GL and Vulkan code becomes rather more difficult. 
Quakespasm Thread: Dick-Waving Edition 
For a limited time only - enjoy 100% more condescending sneering, with extra egotistical squabbling thrown in for free!

Find out who's code is the best code! Fight! Fight! Fight!... 
Ooh Ooh 
my code is the worst.... miiiine.

wait, we were fighting over whose was the best... fuck. 
I think the fight was supposed to be over who's code. Or something. 
I think the discussion is interesting.

Much of the discussion in this thread does relate to engine coding. Always has.

If seeing engine coders argue/explain/hyperbole technical details --- you haven't read any of the rest of this thread.

It's uncommon to see the kind of technical discussion of a recent technology (Vulkcan) by people who actually can code in it. 
Well, here's one non technical question about the engine code...

Given the current state of things, who's the actual owner of the Quake copyrights? id? Zenimax? Bethesda? How should one write a copyright notice for it? 
you want to make a commercial game using the engine? 
You don't need a permission to make a commercial game. What you need a permission for is a closed-source game. 
It Was Meant As A Literal Question... 
Who owns Quake today? 
Quakespasm thread. Not "ask anything you like thread". 
Stop being condescending. This is a perfectly fine design for something as simple as Quake.

The command buffers and swap chains are double buffered to get minimal latency, which is probably the most important thing for Quake instead of getting 6000+ FPS in a meaningless benchmark. Btw. this is also recommended by AMD.

I use multiple descriptor sets because otherwise I would have to dynamically create them on the lightmap/texture permutations. In a real engine the descriptor sets would be bigger, but you probably would still want to bind multiple ones to avoid thousands of permutations.

If you want to tell me I should index into a big descriptor set: I have been specifically told not to do this, because it's slower on their hardware. On DX12 they even *always* pay this cost. Yes you read that right. Texture arrays have problems with different texture sizes and formats.

You are wrong about DirectX 12 in general. E.g. on AMD this goes through almost the same driver, there is some thin abstraction layer on top of it for DX12/Vulkan. Additionally there is no render passes which can actually also speed up desktop chips. The swap chain is fucked up on NVIDIA right now. This will be fixed very soon.

On top of that this was code for a 0.20 release. I already fixed the memory pooling for textures.

I'm really annoyed by behavior like this. You get something to free and all you can talk about how much better you are than everybody else. Meanwhile I actually try to do something for a community.

Have a nice day, maybe you learn to have some manners some day. 
"Stop Being Condescending" At MH 
Yup this will happen. 
What's weird is that I'm not the one who actually said those things. I guess that Axel just made an honest mistake there.

But I reckon OTP is just so full of hate and spite that that wouldn't matter much anyway, eh? 
Go Play Some Quoth Fam. 
mh: It's fantastic to have something where you can go in, look at a bunch of GL code and see the Vulkan code needed.

I agree with that. I think Axel made a very awesome contribution. And I've seen similar appreciative comments about the Vulkan API port on several different web sites. 
You are right, I was partly confusing Spike's post with yours. I'm sorry about that.

Doesn't change my point though, no matter who said things. 
Also about the GPL situation: Zenimax does own the rights to the original Quake source code. I do not. I can't just go ahead and randomly change licenses because I would want to. I'm also pretty sure even asking would be pointless. 
Help Mac Quakespasm! 
Never heard of this before as I'm not a MacOs Quakespasm user.
This really big map of mine which uses the "-heapsize 160000" makes my map run under WindowsXp but not on a MacOs.

Just a reaction of a player that don't know where mac periphericals go with QuakeSpasm_0.92.0

What can I say? 
You know Quakespasm defaults 256 MB by default, right?

(which is more than your crusty command line example which is asking for 160 MB or so) 
wait, I'm not the one who's asking.
It is someone on this MacOs Quakespasm that asks me advice.
I tried to reconstruckt the failure and the maps runs fine for me with the "-heapsize 160000" option.
It is his quaestion from him to me how to load a map that size on MacOS.

I know nothing of macs and apples. 
I think that's normal.. QuakeSpasm on OS X is probably running as 64-bit, and more heap space is needed to load the same content when the engine is 64-bit. Anyway, just dropping the -heapsize argument should be fine since it defaults to 256MB now. 
I understand, I'm just nudging you to not use --- nor suggest --- the -heapsize commandline argument.

It's archaic at this point except in exceptionally odd circumstances. 
I am the person trying to run LXSU4 on MacOS with QuakeSpasm.

It is telling me couldn't spawn map. I'm using the supplied command line:
-heapsize 160000 -game lxsu4 +map lxsu4

I also tried every other combination and method I know.

LXSU4 is created by MadFox and featured on the Quake Expo 2016 site: 
The zip file is LSXU4, not LXSU4, so try -game lsxu4 +map lxsu4. 
You can type "game lsxu4; map lsxu4" in the console.

Both gamedirs and map names autocomplete in the console if you press tab.

No more typos 
LXSU4: Zip File Wrong Name 
Ok, it works. Thanks! The zip file / game folder was supposed to be named LXSU4, but it isn't. 
Watch Out 
for elexis ufour! 
This Bothers Me 
The original game displayed the view weapons slightly differently depending on the view pitch. I don't know if it was a feature or an oddity (it also strangely depended on the screen size), but I know enough games that do similar things deliberately (so it wouldn't look like the weapon is glued to the player's chin).

Looks like this effect was lost somewhere along the way. What I'd like to ask is why. 
Oh, and apparently I misremembered Fitzquake exhibiting the old behavior - I just checked and it doesn't. So it's not a Quakespasm change. 
There's a car to display weapons like winquake at least in markv 
My Fault Aftershock.., 
Just saw it now, I packed it with the wrong name. 
There's a car to display weapons like winquake

Yeah, it looks really cool! Rocket launcher example
Quick Question. Uh, Make That Two. 
Hey guys, I think I've read about it somewhere but I can't seem to remember or find the page again, so please clear something up for me: there's no RTlights support in QS, is there? And while we're at it, I'm looking for something similar to DP Pretty Water for QS. Do I have any chance of getting lucky? 
As I understand it, QS is more about improving the engine within an acceptably Quakey aesthetic - stuff like RT lights and hi-res fresnel FX on water don't really mesh with the grungy pixel art look that was established in the original game. 
Eric is away this weekend, but he's working on a map with me ATM. 
Uhh... With all due respect, I don't condone this kind of backward thinking. Nostalgia is fine (I still play Quake, don't I?) but please don't be an ayatollah about it. Quake was no pixel art, it was downgraded art to circumvent hardware limitations of the time - like the sounds being limited to distorted 22kHz. I'm perfectly fine with pixel art and I've played great games that make use of it, but Quake being a highly immersive experience, it undoubtedly benefits from looking better. Take a look at the player model for example, it is very sketchy with parts of the texture shifting and trembling like jello in a decidedly unnatural way. That's not pixel art in any way whatsoever and I for once am very glad that HD content exists nowadays.

Oh well, at least I can still use hi-res textures and .lits... I just wanted to make QS as pretty as DP for the mods that I have trouble running in DP.

@Veyron, the link returns an error 502. 
Use DarkPlaces Then 
QuakeSpasm is for those who want the original look and feel as much as possible. 
Problem With Dp 
Is that it's no longer supported like the poster says. I'm sure other engines have added features like rt lights? 
please don't be an ayatollah about it.

Lol, with "all due respect" I just gave a simple answer to your question. Not sure why you think I'm being all preachy about this. Then again we all love a bit of salty beef on these forums - keeps it interesting doesn't it?

I don't personally have anything to do with QS's development, but it is my preferred engine, and indeed the FitzQuake/QS/MarkV line of engines are overwhelmingly the engines of choice for the mappers and players on these forums. Not bad for such a "backward thinking" approach I guess. 
Part 2 
HD content will always look terrible in Quake unless all the art assets - including the detail of the level geometry - are upgraded to a consistent fidelity.

2048 pixel texture on a 300-poly monster? Looks like shite. Hi-res bump-mapped textures on ultra-low poly quake level brushwork? Looks like shite. etc. etc.

There has been no attempt to remake Quake in entirely HD content, but what you do get are quarter-arsed efforts that are essentially the quake equivalent of this: 
Quake being a highly immersive experience, it undoubtedly benefits from looking better.

Anything would benefit from looking better. But whether HD content and new effects make classic games look better is arguable.

In short, it's about the balance of elements. When you improve textures, they make the geometry look simpler. When you improve skins, you should also improve models (which is something I'm yet to see). And when the character models will be up to modern standarts, if will suddenly be discovered that the whole animation system needs to be reworked just to make them look natural.

Some people don't notice all of this, but some people do. I would really like seeing a modern-yet-faithful Quake reimagining, but I think it should be a standalone project on a new engine, or a very deep reworking of the whole game, which will most likely mean dropping mod support.

Special effects like real-time lighting are less harmful though. In this case I'm only concerned with the fact that the quality of static lighting improved considerably in the last few years, and I'm not sure that real-time rendering can do it justice. 
And let's not forget about the actual quality of the HD art assets that the fans produce. I think it got better with time, but it's still not exactly at the professional level. 
Well, talking about Quake (or any 20-year-old game for that matter) as, ahem, "pixel art" and saying stuff like "an acceptably Quakey aesthetic" sounds pretty preachy and rigid-minded to me. You know, "this must be that way and any divergence is intolerable". Words you can hear in the mouths of zealots and dictators. Just sayin'.

As for the discrepancy between the simplicity of the geometry and the level of detail of hi-res textures, that's a matter of taste. A nice texture will always look better to me on a simple surface than a mess of blocky pixels. I thought they looked like crap 20 years ago and I still do now, luckily now I can get rid of those. And normal maps help a lot in fooling the eye into thinking that what it sees is more than a flat wall. Sure, normals can look a little weird sometimes depending on the viewing angle, but most of the time they do their job very well. As for low-poly models, you're aware that they can be replaced with hi-poly versions, right? If you haven't seen Fredrikh's awesome shambler or those shader animated ammo boxes (the nailgun boxes for example have each individual nail modeled) you're in for a real treat! 
Yeah, a modern reinterpretation of the game would rock all kinds of awesome! Sadly, each and every TC nowadays seems to stall after a while. If we're lucky we can get one entire episode, like Classic Doom, but these projects never see completion anymore. Have you tried Shambler's Castle for Doom 3? It's quite short but it's most definitely a must-play. 
Shambler's Castle 
I have, and yes, while it has its problems, it's the direction I was talking about.

A nice texture will always look better to me on a simple surface than a mess of blocky pixels.
Again with the "good vs. low-res" attitude. Low-res can be good too, even if you don't understand it. 
Dis Gunn Be Good. 
Jesus Fucking Christ 
I do understand low-res when it's real pixel art and not due to hardware limitations like Quake. Wadjet Eye productions, games like Minecraft or Eldritch are prime examples. Eldritch even emulates by geometry the broken lines of the textures in early 3D games! Quake's pixels and muddy palette were only the best approximations id could offer at the time and it makes sense to update them when technology has caught up.

Anyway, as I said it's a matter of taste and neither option is wrong, contrary to Kinn's absurd claim. We're not gonna dwell on it forever, this is not the place for this discussion. I originally asked a simple question and never intended it to escalate into a full-blown argument. But what do you know, vanilla vs. enhanced seems to be a touchy subject for a certain kind of people...

I'm gonna finish with something I wasn't able to add earlier because of connection troubles: you may not be aware of it but the monsters from Shambler's Castle (vore, scrag, fiend) have indeed been ported to Quake. Check also Fredrikh's shambler as mentioned above, it's really a sight to behold - first time I saw it I went "holy shit!" You can find both types of knights, grunts, dogs, Ranger, there's a great model for Tabun's enforcer and more. There's even a hi-poly tarbaby! Plenty of detailed models to complement the fancy textures and lighting effects. Not to mention a fix for the shambler's lightning that makes it finally come out of his hands as it should instead of his belly. 
Pixel art exists due to hardware limitations of the past as well. So?

Then again, I'm one of those misguided individuals who still produce art that's neither pixel art nor "good" art. My motives in this conversation are pretty obvious. 
Just A Comment 
I did not grow up playing Quake DOS and the first time I did play Quake was the N64 version. I started messing with Quake PC last November and used the Epsilon mod. I originally enjoyed the flashy visuals and weather effects but eventually I transitioned to Quakespasm and never looked back. I am just putting this here as someone who isn't specifically biased to old school quake...ness.

Anyway, I would love to see weather effects in quakespasm/maps. I'd make every flipping one of my maps rain because I love rain in games. 
Sitting next to his partner Kevin Cloud, [Adrian Carmack] clicks his lightpen all day long, making minuscule adjustments, one pixel at a time, to countless texture tiles: lichened stone, pitted wood, corroded metal, viny corpuscular stuff. - Wired


Quake was no pixel art, it was downgraded art to circumvent hardware limitations of the time - some fucking rando

Who do I trust?? 
Technically, Quake has little to no pixel art. Pixel art (in the modern sense at least) requires you to work with the palette colors directly, and 256 colors is a bit too much to handle efficiently.

Still, this kind of art (when it's done well) shares some traits with pixel art, such as a high level of precision when small details are concerned. It's kind of a necessity when you only have so many pixels to convey an idea. 
Mugwump, if you want rtlighting in quake, you need one of FTE, DP, or Tenebrae. They each have different featuresets and their own compatibility quirks too, hurrah.

I personally tend to use vanilla content more often than not. Its at least more consistent with itself, and imho replacement models tend to have goofy animations that I can't stand. Maybe I just don't like change. 
No one has to like amateur HD content. More often than not it's just weak.

Today I looked inside QRP_map_textures_v.1.00.pk3 that I happen to have. One of the first textures I clicked on was this little gem:

This is a texture of the "bodies" series. Guess what's missing: (this is the original)

I know drawing is hard, but come on. It's supposed to be an improvement. Although, FWIW, if they'd actually draw the contents of the texture properly, it would still look awkward on a flat 2D surface. You can barely get away with such "macro" detailing on a pixelated texture, let alone a high-res one. 
I like the low res art style. It's kind of funny, back in the old days I used to have a 3dfx card coupled with a Matrox 2d card and often I would prefer to play in software mode. The only time I jumped to the 3dfx card was if I was play Q2 and beyond. 
There's Something Magical About Low Res / Pixel Art 
Because of the lack of space for information, pixel artists have a somewhat impressionistic approach. The result, to me, kinda causes you to "fill in the gaps" with your imagination, giving the world a real sense of depth and interest. This works well with quake's otherworldly setting.

I love high fidelity art as well. But that's a different beast all together and puts a whole different set of demands on the artist.

In my experience, HD content for quake may be "good" in isolation, but in the context of other assets and game geometry it often comes off as inconsistent, out of place and amateurish.

A true HD quake would have to be a total remake with a focused and coherent vision from the ground up. 
Sieg Heil 
Words you can hear in the mouths of zealots and dictators

Cool, so I'm essentially Quake Hitler for simply pointing out why QuakeSpasm does not support the features you describe. Again, I'll repeat that I personally have no say over what features QS does or does not have. I'm just an end user. I happen to agree with the QS design philosophy though, as do I think most people on this forum.

We're not gonna dwell on it forever, this is not the place for this discussion

Hey, you dropped this turd on the carpet, don't think you're getting away without having a good sniff of it.

Quake was no pixel art, it was downgraded art to circumvent hardware limitations of the time

It's pixel art. There was no "downgrading" of existing higher colour or higher resolution artwork. The artists literally sat in front of Deluxe Paint with the Quake palette loaded and painted stuff precisely at the pixel level. Maybe you're using a different definition of "pixel art", in which case this is just a retarded argument over semantics and I haven't really got the time for that.

I'm not quite sure how someone could fire up id.wad in TexMex and look at arch textures like "church7" or things like "window030", "adoor01_2", "enter01", any of the stained glass windows, hell, pick almost any texture in the wad that's not just a plain stone surface...and then claim the artist wasn't precisely and purposely laying down palette colours at the pixel level... 
Literally Quake Hitler 
Making all those references to the not shooting Hitler bit from The Office has finally taken its toll. 
Actually, it's precisely the stone surface textures that make me really doubt that each pixel was done in a controlled way. You just don't do that. It's slow. Have you seen the amount of colors used?

While there wasn't any conversion from true color to indexed, it's pretty clear that some "dirty" tricks were still involved. But it really is a pointless argument, because being/not being pixel art doesn't make the assets good or bad automatically. 
I'll Write Something Relevant To The Thread For A Change 
Since the engine supports colored static lighting, are there any plans to add some colored dynamic lighting functionality? Right now all dynamic lights are white. 
Have you seen the amount of colors used

It's a very manageable amount actually because the contrast of the textures is very low compared to the range of the colour ramps used - so the number of colours used from each ramp is low, and taken from the darker end of the ramp.

The light colours in the palette only get seen in the game once the lighting engine does its thing.

Trust me, I am currently creating my own quake texture wad by working directly with the palette colours and ramps, using a bespoke pixelling program I wrote for a company I worked at (which was inspired by pixel apps like DPaint and Pro Motion).

Here is a just one example of one of my textures. I don't pretend to be an amazing artist but the aim is to at least be consistent with the style and quality of quake's original textures. The number of colours used is really really low, simply a handful of colours from the lower end of about 3 of the ramps was used in this one, and this texture look literally minutes to bash out: 
Do you know how DarkPlaces does colored dynamic lights?

(Hint: it's not pretty) 
that looks great 
And what I mean, let's say you want a fireball to be orange lighting?

How do you tell DarkPlaces to make a fireball's dyanmic light orange?

(It's an uglier hack than a tour inside a hotdog factory) 
Well, the stock textures are typically more smooth, and also occasionaly more "chaotic" in the sense that you can spot pixels that don't really belong color-wise. Some of these cases are clear mistakes that would've been hard to commit when picking colors manually.

In some cases you can clearly see that they blended two or more materials together. Quake even has some textures that are derived from Doom textures that were made of toy photos. And it's an efficient way of doing things. Although if you really made that texture in only a few minutes, I can only applaud your skill. 
I take it a cleaner solution doesn't exist?

Adding colors to old content retroactively isn't really necessary. I was thinking more along the lines of giving modders a way to assign colors in new mods. Like reading a certain entity field (if it is defined in QC), for example. 
From My Experience 
Dynamic colored lighting does not go well with static baked-in lighting at all. :( 
From My Experience 
Dynamic colored lighting does not go well with static baked-in lighting at all. :( 
I think color for the built-in dynamic lights would be a good addition. There are not that entities that move and give off light. Would it really be difficult to add?

(Lava balls
Magic bullets
Vore balls

What else?

Now, if somebody wanted moving light sourced from specific textures on doors, func_trains, and such, then I can see that being more of a problem. 
Well -- First 
But a cleaner solution than what?

I asked if you knew how DarkPlaces does it. And clearly, you don't.

One would naturally conclude:

- You have so little interest in the feature that you never have used it for yourself in DarkPlaces. 
My only interest in colored dynamic light is from a mapping point of view. It just looks very weird to see the fireballs, rising from deep orange-red lit lava, giving off pure white light.

The others I mentioned would be nice, rockets etc., but beyond that I don't see it as all that necessary for Quake. 
But a cleaner solution than what?
Than a solution used in Darkplaces, which you clearly see as ugly. I trust your opinion.

You have so little interest in the feature that you never have used it for yourself in DarkPlaces.
I have little interest in Darkplaces.

But it's pretty clear from your reaction that this is an unwanted conversation for you. 
Coloured Dlights 
Like the rather icky r_noshadow_list stuff, could we just not whack a great big string into the config file that maps modelnames to colours?

It's ugly but we already have a precedent for doing things that way...


That particular texture was really quick because it's just quick splotchy strokes with a bit of shade and highlight. Doing precise metalwork shapes and stone carving decor and whatnot is a bit slower obviously. 
Maybe if you educated yourself to understand what it is you think you want, you might see why it is unlikely to happen.

But instead, all your bring to the table is
- a lack of knowledge
- can't even be bothered to try it in DarkPlaces
- ignorance of not knowing what you are asking for

I think it is a bit rude to ask the Quakespasm guys for something you don't even know what it is, nor how it should work. 
To Anybody Who Cares To Read This Rant. 
On adding too much to the engine...

"Like reading a certain entity field (if it is defined in QC), for example. "

I'm pretty sure that is the kind of hackiness that baker was talking about. Modding in the engine is counter to what the philosophy of mods is to begin with.

Mods are programmed within the framework of what they're allowed to access / execute. Not only does it add bloat, but it also has the potential to break that mod for other engines. As soon as you bypass the vanilla framework you might as well just hard code the progs into the executable.

These features can be added, but where do you draw the line? I think the QS (and beyound that fitzquake) developers have done a great job at keeping engine bloat to a minimum.

I honestly think that quakespasm is not suited to visual enhancing features like darkplaces and co.

But you know what I did when I wanted IRC support in quakespasm? I learned some C and forked it myself. I wholeheartedly recommend that if you really want a feature added, then this is the way to go, not only do you learn a new skill, but you also get the feature that you want.

/rant over. 
Directq And RMQ 
I think had this and different colour coronas too, I'm sure they looked good because I stuck with those engines for a while 
Let me get this straight. Before I request a feature in an engine I'm interested in I need to:

- Be a programmer myself;
- Try the feature in an engine I'm not interested in;
- Understand that the feature is hopeless crap using my programmer knowledge;
- Never ask for it, because it's crap.

Did I miss anything? 
Posting in this thread is like playing Dark Souls; at first you'll find it cruel and unforgiving, but after many days, weeks and months of practice you'll intricately understand the attack patterns of the various mobs that lurk here, and be able to parry and counter their posts effectively. 
before you request a feature you need to:

- Prepare yourself for the possibility that the developers don't want to implement it.
- Not get salty when you don't get the answer you want. 
By not getting the answer I want you mean stumbling on an edgelord that I'm not even sure is one of the developers? 
That's One Approach 
Baker is weird. But he knows what he's talking about when it comes to Quake engines. 
Is certainly more articulate than Madfox, and provides far more polished content (ProQuake, Fitz V, etc) but god damn if their thought processes aren't equal. 
I kinda get that he knows things. That's why I said that I trust his opinion. 
I mean rather than arguing with them after they say no.

Perhaps instead saying to yourself:

"Maybe that's fair. That probably is a lot of effort for the developers who do this without any pay"


"well I really want this feature, maybe I should teach myself some programming and see if I can implement it myself" 
Developers saying no is not a problem. 
No, no, your opinion is wrong. Or in your ass, at least. 
"Hey, you dropped this turd on the carpet, don't think you're getting away without having a good sniff of it." No, I ONLY ASKED A SIMPLE DAMN QUESTION! You guys jumped on my back like a pack of hungry wolves on a pile of bloody meat. I'm not responsible for your behavior and I won't take any of that shit. Learn some manners.

"Mugwump, if you want rtlighting in quake, you need one of FTE, DP, or Tenebrae." You think I don't know that? Like I said earlier, I asked specifically because of those mods among my favorites that have trouble running in DP and whose readme recommends QS or Fitz.

"The artists literally sat in front of Deluxe Paint with the Quake palette loaded and painted stuff precisely at the pixel level." So they chose to add blue to... wooden planks? I remember reading a discussion about it among visibly knowledgeable people saying that the non-standard palette id chose caused weird artifacts like that.

"Anyway, I would love to see weather effects in quakespasm/maps." THIS. Weather effects, like dynamic lights, benefit greatly to immersion.

Dwere, you didn't think that the missing body from the texture was because the body was supposed to be rendered in 3D? Tsk-tsk... 
At least my ass isn't located where my mouth should be. Opinions are subjective, therefore can be neither right nor wrong. 
Nope Your Opinion Is Wrong. 
I laughed, thanks. 
Sure, whatever floats your boat, pal... 
Keep Sniffing, Mugchump. 
Bet that hi-res bump-mapped dung smells gooood, man. 
Oh, Grow Up 
Why do you feel the need to act like a jerk? 
Sleepy Was Right 
this is good stuff here. 
Learn some manners.

Says the guy who posted #2194 in response to #2191. lolbiscuits.

So they chose to add blue to... wooden planks?

Hehehe, just because you can find a few dodgy counter examples..hell, like another guy said, I'm sure you can find little elements that were photosourced if you dig hard doesn't change the fact that 95% of this shit was basically pixel pushed. I'm really not sure why this is such a tough thing to believe. 
This Thread Delivers 
Func_ Is The School Of Hard Knocks 
when it comes to dealing with trolls... 
Like Seriously, Mugwump 
Come the fuck on, dude.

and don't even get me started on the Rogue textures... 
Unlike some of your and others' comments, #2194 wasn't intended to be mean, aggressive or insulting, it was a depiction of your attitude towards graphical enhancements. You gotta admit you DO sound like a bit of a zealot about it. I'm sorry if you felt offended, I know I can be blunt sometimes but it wasn't an attack. Can we please get past this once and for all?

I'm not saying they didn't do a hard job or didn't spend countless hours lovingly crafting their game, but putting it all on intent and disregarding technicalities is delusional. IMHO. With due respect. Do you think they would have gone with blocky pixels if they had a choice about it? 
If is a word god uses when he wants to have a laugh. 
God remains to be proven real. 
Hey Im Here And Posting 
should be enough of a proof. 
Hello, God 
Ha ha, nice one! You sure do create awesome worlds. Do you do that in seven days too? 
It Took 6 
you infidel. even i need some rest. 
A supposedly omnipotent being needing some rest? Doesn't sound legit. 
Yes, It Is Legit. Worlds Are Hard. 
troll elsewhere, leave this thread for engine-related topics please. 
Since when off-topic=troll, exactly? But agreed, this whole discussion should've been taken elsewhere. I did say so myself a few posts ago. I was just making tongue-in-cheek responses to your humoristic comments. Mugwump out. 
Just Leave This Place 
else is idc 
Dwere, you didn't think that the missing body from the texture was because the body was supposed to be rendered in 3D? Tsk-tsk...
Before you leave this thread, I'd like to see a screenshot of this body rendered in 3D, or a link to a mod that enables that.

I'm assuming other textures with similar detailing preserved, but merely stretched/filtered, were always made specifically for such a mod, so you're not supposed to see the lazy parts.

I'm really not sure why this is such a tough thing to believe.
There's a saying about thirteen strikes of the clock. I've clearly seen the assets that weren't made using pixel art techniques, so I find it logical to believe that such methods were used on a regular basis. Why not, if it can make your life easier?

I admit that I don't know the exact capabilities of the tool that id used at the time (Deluxe Paint?), but I've heard it had some advanced features like blurring, even though it wasn't a true color image manipulation program.

Do you think they would have gone with blocky pixels if they had a choice about it?
Again, you could say the same about early pixel art examples. This is irrelevant to the question of how aesthetically pleasing is the art itself, or if the technique used should be abandoned.

Low-res paletted art generally takes less time to create than high-res true color art despite the former's limitations, so it still has its applications in non-commercial works where your resources are very limited.

Even a "retro" project is hard to pull off with an acceptable level of quality, so it's no wonder that "modern" amateur projects are so rare (and typically look worse than their technical level allows). 
Mugspunk Is Right About One Thing Tho. 
MFX needs to go map...

OTOH. Yes, if you redid everything in Quake, including all hi-poly models, increased the brushwork tenfold, etc etc, then sure hi-res textures and bump-mapping and shit would look good in.

At the moment, it is simply a matter of objective scientific fact that pushing some graphical aspects very far forward whilst other graphical aspects lag behind makes the game look like ass.

(Conversely, some graphical aspects - coloured lighting, fog, transparency, particles etc - can be pushed a bit and still be perfectly harmonious with the basic graphics when used well. Why is this? Who knows, just another immutable law of the universe).

This doesn't mean the potential isn't there, but the whole lot has to be over-hauled in harmony, not disharmony. 
I remember reading about this. If memory serves, QRP was originally a much more ambitious project designed to replace all textures AND all models in the game. After a while, they dropped the models part to focus on the retexturing. So the body was never actually made and the texture was "forgotten" and left as is. However, there is a fix for it: a hi-res body was added to the texture by someone else. You won't find it in QRP and I don't remember exactly who did it and where you can find it. Maybe in SMC but I'm really not sure. 
"Scientific Fact." Oboy... 
I Am Not Sure If I Prefer A New Kinn Map 
or new kinn posts. He has been on fire lately. 
A New Map. 
But using his own custom textures all of which are made from the text of his recent posts, and of course are fully hi-res, hi-definition, bump-mapped, specular-mapped and generally fucked up beyond all comprehension. 
With A Secret Room 
with walls textured in his Quake Hitler pose. 
Quakespasm 0.92.1 Released 
Version 0.92.1 of QuakeSpasm is released: This is a minor bug-fix release.
Changes since the previous version:

* Fixed large menu scale factors (was broken in 0.92.0).
* Fixed PAUSE key (was broken in 0.92.0).
* Updated some of the third-party libraries. 
In Defense Of Vagueness 
I remember reading about this. If memory serves, QRP was originally a much more ambitious project designed to replace all textures AND all models in the game.

What about remaking all the maps to have the high levels of detail that would justify the replacement textures and models? 3200 poly monsters in 400 polygon worlds look just as out of place.

But it's all academic anyway, Quake's vagueness is part and parcel of the deal now, and you can't upgrade your way out of it without disappointing a certain proportion of the player base. For example, this ogre replacement has been objected to on the grounds that he's holding the chainsaw in a hand, rather than it being grafted onto his arm. To some that was a limitation required in 1996, to others the body-horror was part of the appeal (this may explain why Edie is part-ogre rather than part-human).

Similar debates have raged on this board over whether Shamblers have fur or ragged pale skin, whether Fiends have eyes, and whether the Vore has a feminine physique or not (note to func_ regulars: please resist the natural temptation to reignite all of these below). The more you define the detail, the fewer people will agree with your interpretation. Best to let people's imaginations fill in the gaps, like a good book spared an imperfect film adaption. 
Oh And To #2276 
Thanks OZ! 
really preaches it. 
Feature Request 
Support for colored text in centerprint messages. I'm wanting to use them as headers on different bools that you read in this one map mine. They look fine in Darkplaces but have ^7 characters showing in QSPSM. 
@Veyron - my build server is back up now

re: rtlights and water shaders, I also don't think these fit in QS (both code wise, and engine focus). I think it's good for the Quake ecosystem to have multiple engines with different specialties, QS shouldn't have every possible feature.

IMO, if you run in to a map that FTE and/or DP have compatibility issues with, you should make a detailed bug report explaining the problem. 
Weird Ramps, Hidden Steps 
Getting stuck on what feels like tiny brushes. Ramps in general are pretty sticky to traverse in this engine. Maybe I'm missing something, same problem occurs no matter what the fps. Here's a screenshot
That can happen when three or more different planes intersect along the same line. In this case the floor, the ramp, and the near wall of the room. Is that a map you made or just one you're playing? 
That's good to know thanks. Nope, it's e1m1. [= 
Leave host_maxfps at 72, otherwise it'll mess with the physics. 
It happens even with host_maxfps 72 though. 
Quake has 2 colors for text --- gray and "bronze". With some QuakeC compilers like FrikQCC you can add do "/bThis is bronze text/b"

Of course, FTEQCC is the go to compiler these days and I can't remember if FTEQCC supports that (at one time it didn't), but it is still possible by pasting in text from a Quake text maker like:

This method does not need any compiler support, you should be able to put that text even in map titles and such. 
I did notice the funky physics when playing on 250. Knocking it down to 144 keeps it fluid and fixes the bobbing around on descending lifts. Will probably end up playing on 72 if I run into anything worse. 
My light.exe also processes "\bThis is bronze text\b" anywhere in the map file so you can easily use it in trigger messages, etc.

re: e1m1, I can get stuck walking towards the ramp from the e1m1 exit slipgate with winquake.exe (and in QS as well).
So at least it's not a new bug. :-/ 
@Qmaster. A 2nd option ...

Make your own conchars and distribute it with your map.

Then the "bronzed text" can be whatever color you edit the conchars to be. 
@ericw -- pretty cool (although I won't ask why the light.exe is what would do that instead of the bsp compiler, haha) 
"you can't upgrade your way out of it without disappointing a certain proportion of the player base"

Why the fuck should that certain proportion of the player base care about how I upgrade MY Quake? They're not playing on my setup, are they? I came to this thread with a simple engine-related question and got bullied for even daring to ask it. There's conservatism and then there's fanaticism. One I can understand, the other not so much. 
Why are you asking Preach for permission to upgrade your Quake?

Idea: Upgrade your Quake without Preach's permission? 
I came to this thread with a simple engine-related question and got bullied for even daring to ask it.

Please stop trying to rewrite the history. The only reason you got bullied is because you started accusing people of fanatism and backwards thinking out of the blue. People don't like such arrogance no matter how "delicately" you express it. 
Hobby Engines 
Writing engines is a hobby, so it's about the author's vision for what the engine should do. If you want them to add a feature for you, then you're talking about something larger than yourself. 
Baker, I don't ask him permission, I'm replying to his last message to me.

Preach, I don't recall asking anyone to add that feature, I just asked if it existed.

Dwere, who's rewriting history here? Comments like "acceptably Quakey aesthetic", "your opinion is wrong" and other bullshit like that ARE fanaticism and THESE are the arrogant attitude, certainly not calling people out on it. People may not like having their shit shoved in their faces but the shit is theirs, not mine. 
is this discussion seriously ongoing? 
Your Opinion 
Continues to be is wrong. 
The "Second Wind" 
...a bit like post-mortem flatulence. 
Never Disappoint Kinn. 
"Acceptably Quakey" is a valid term when talking about an engine that's supposed to improve on the original aesthetic without replacing it with something else. If you got set off by such a vague (and most likely unintentional) hint at superiority, then perhaps you shouldn't be surprised that your own sermon about what's "better" led to unpleasantness. 
The Trolls Have Awoken 
How surprising...

@Shamblernaut When people talk to me, I reply to them. That's how communication usually works. Preach talked to me (see post #2277), so I replied. A bit late, I admit, but I've been busy mapping and playing Quake.

@Kinn I bet you know all about flatulences with that potty mouth of yours... 
AFAIK, I've never stated my opinion of what's better as an undisputable fact. On the contrary, I've underlined that it was my personal preference. 
Too Little, Too Late 
Actually No. 
You argued that Quake's art is not pixel art, despite the fact that it obviously is. The result of 2+2 is not a matter of taste, it's always 4. 
It's not as obvious as you think. 
Pixel Art 
Ah, glad to see you decided to ease up on the trolling, OTP. Pixel art is a modern style designed to emulate the look of early textured 3D games. Though id carefully crafted their art direction, it was not what is called pixel art. Yes, it was art and yes, they used pixels, but the comparison stops there. 
Pixel art is a modern style designed to emulate the look of early textured 3D games

It's like he's not even trying anymore. 
Who's Not Trying What? 
One True Pairing 
Mugwump and OTP are my OTP. 
"early textured 3D games" Please read "oldschool pixellated games" instead. Though I mentioned Wadjet Eye earlier, here I overlooked the fact that the term is also used for these 2D games that emulate the look of the 8/16 bit generations. 
Well yes, 2D productions a la Wadjet Eye and 3D productions a la Minecraft are both called pixel art. 
Let's put it like this: it's the 3D games I'd use "also" for.


I can clearly see the use of soft brushes on the background. Looks like you tolerate "mixed style" games after all. 
I would also like to add that even though the term "pixel art" seems to be a relatively recent invention (correct me if I'm wrong), it still applies to older games retroactively. 
Did I ever say otherwise? After all, I do use hi-res textures on simple 20-year-old geometry. Question: how do you infer the use of 3D brushes from a fixed image? 
I wasn't aware of that. I've never heard the term used for these old games. If that's true, I stand corrected. 
I always wondered why the building blocks used for mapping in Quake-like engines are called this way. It kinda makes sense (because laying them is sorta like laying brush strokes), but not really. 
Whats Going On In He... 

*backs away* 
Yeah, 3D editing vocabulary is often puzzling me too. I've looked at your example picture again and I think you may be wrong. You're talking about the reflections on the facade of the building, right? Look again: the perspective of the reflected building right to center is wrong, it should be reversed with the side visible on the left, not right. 
No, I'm talking about soft brushes.

Brush is a thing you paint with. It's also an appropriately named tool in image manipulation programs (because you paint with it). 
Ah, this kind of brushes... I was wondering what you meant by soft. What's the mixed style you were referring to, then? I thought you were talking about the use of 3D brushes in a 2D game. 
Pixel art combined with not pixel art. 
Oh, right, in the sense that pixel art is made pixel by pixel whereas brush work is not. I have no idea how you can spot which technique was used in the final image. 
It can be argued that 256 colors are okay to pixel things. 16777216, on the other hand, is a bit excessive. 
I was certain I read somewhere that a lot of the textures in Quake were painted and then down-ressed. I suspect that many of them were touched-up afterwards in some pixel pushing software (as well as some made entirely pixel-by-pixel) 
I didn't know this game used 24-bit coloring. Is this their latest production? The last Wadjet Eye game I played was The Shivah, which still looked 8-bit to me. It seems the definition of pixel art has broadened. 
They Look Waaay Too Good For Scaled Art 
So yeah. There was a lot of precise work involved, this much I can say. 
Blah Bla Blah...use "bronzed"....Blah Blah Blah 
Ok thanks I'll stick with bronze text for both, didnt realize it was dependant on compiler...thought the engine had to be able to recognize the \b characters.

Carry on with your mindless stylistic vs realistic debate. 
Doesn't Look 8-bit To Me 
Dropping This Bomb In Here On My Way Out: GL Blur Isn't An Improvement 
That was me in the comment above BTW, I hadn't noticed I was logged out.

@Fifth Yeah, I remember reading that too. That's the source of my "downgraded art to circumvent hardware limitations" comment from the other day. 
Kosher Edition 
Unless it was redrawn or something. Its page mentions something like that.

The earliest game on the site seems to feature pixel backgrounds. 
It would seem that the debate had moved on. Not sure if it's a good idea to reignite it with arbitrary statements like "GL Blur Isn't An Improvement", which is a matter of opinion. Of course, it works better with hi-res textures, but some people do prefer blurry vs. blocky, even on low-res textures. 
Granted, this particular image looks a bit lush for 256 colors. Other screens in the game look less "refined". 
They all feature true color backgrounds with pixel art characters (excluding portraits). 
Thinking about it, I have to admit that The Shivah effectively looks more 16-bit than 8-bit. I don't know how many colors they actually used but it looks like a Megadrive/SNES game. 
You should be more careful when mixing processor bits with color depth bits in the same conversation, but whatever. 
Well as you probably have guessed I'm no expert on the subject, but you gotta admit that it's a bit confusing when they use the same term to describe different things. Like "brush". 
Scaled Art 
Like I said I'm sure it was traditionally painted, like oil painted, and scaled down. Then it was tweaked using pixel pushing techniques afterwards 
The Doom monsters started as scanned in photos of actual models. 
Which is probably why they looked so coherent from all sides. 
Is MugWump now allowed to just trash this thread into smithreens?

He's not house trained, where is a moderator?

This is the Quakespasm engine thread, not his personal litter box. 
The Fucking Bullshit Pixel Art Drama Thread 
Hey, I came back here to reply to Preach. Like I said, when someone talks to me I respond, that's the basic principle of communication. People then commented on that reply, etc etc... and I wasn't expecting the discussion with dwere to be this long. Next time I'll move it to general abuse, but between you and me you should work on your people skills. You know I'm new to this site and right now, you're making me feel very unwelcome. Not cool. Mugwump out. 
You trashed up this thread.

I don't care how you feel, you are the wrong-doer

An apology would be nice. 
Make Up Your Mind 
You want me to shut up or you want me to apologize? Maybe you should ask all the people who kept me talking - including you, how ironic! - to apologize too, they're just as responsible for making the off-topic linger on. But you won't do that, will you? Mugwump out. Again. 
The Beauty Of Hindsight 
Maybe you should ask all the people who kept me talking...

Yeah I agree that it was a mistake engaging in conversation with you in the first place. I imagine not many of us on this forum will bother doing that again. 
Yeah let's all pick on the new guy. Provides coherent arguments and all you do is whine about how this is the wrong thread. Boo hoo. Reminds me why nothing decent ever comes from this community, just circle jerking over a 20 yo game. 
Spitting obvious nonsense and/or insults is the lowest form of trolling. 
But This Is The Wrong Thread. 
not for the initial discussion, but certainly for what it evolved into. 
Yes Dwere 
I'm sure there's an argument in that statement somewhere, whether or not it is real. Right? 
Switching Mood Settings During Gameplay? 
Is it possible to switch different fog color or overall settings which support different moods? Yes I was thinking of Quoth when it comes to logic gates yet sending console commands during gameplay, but personally I wanted get back into AD modding too. I guess this hasn't to do much with the engine in this case, but it should support these features I know or might not know yet. 
AD lets you change fog colors. 
SolidClass base(TrigOFF,Targetname,Target) flags(Angle)
= trigger_fog : "Trigger Fog" [
speed(integer) : "Time to fade (-1=Instant)"
wait(choices) : "Wait before reset" = [
-1 : "Trigger Once"
0 : "Always reset"
2 : "Default"
fog_density(integer) : "Fog Density (def=0.1)"
fog_colour(string) : "Fog Colour (0.1 0.1 0.1)"
Fog In Quoth 
Quoth doesn't have a dedicated fog entity (yet), but you can use a trigger_command or trigger_command_contact to send a new fog command to the console and change the color that way. 
Feature Request 
Is there a way for an entity to be marked by QC so that QuakeSpasm does not included it in demo's or MP/Coop traffic?

A new key, an existing flag, something that can be set via QC so that an entity is never sent, transmitted or recorded and remains client side only. I really want this for the QC sprite particle system so players can enjoy the visuals and not create monster demo files or drown network connections for coop. Thanks. 
Thanks, that answered to my question* 
Fog, Just To Wanting To Make Sure 
So I can use these trigger_fog brushes, and inside of it will be specific fog I set up. If I put next to each other almost the same duplicates of the original, but I only change color a little bit.. or maybe changing it to totally different color like from blue to orange/yellow.

It that is possible, has any maps done this in the past? 
Is there a way for an entity to be marked by QC so that QuakeSpasm does not included it in demo's or MP/Coop traffic?
Its called the remove builtin... just check that deathmatch or coop are set first...

regarding demos there's not much you can practically do. The recording is clientside rather than serverside, so csqc's access to that sort of thing is going to be limited whatever happens. I guess an engine could add a some cvar that gets set when its recording/not (which would only work for local servers), or it could send a clientcmd (which qs mods would then be unable to parse anyway).
the client just dumps the entire data that it receives, so a serverside flag would do nothing to prevent demo bulk (unless the client was rewritten to be muuuuch more selective about what it writes).

one alternative would be to write a tool that just strips entities out of the demo based upon their modelindex, after the demo has already been recorded.
alternatively at least one server includes gib filters, which can be used to disable sending of entities based upon their model/frame. for instance a serverside gibfiltr.cfg file in fte with 'model firstframe lastframe' lines, which can be enabled on a per-(qw-)client basis with 'setinfo nogib 1'. obviously different engines, different rules, and I have no idea about eg qrack. looks like baker added some flags into proquake that a mod can set too (which naturally conflicts with dp extensions). the catch is that absolutely none of this is automatic, so whatever happens you'll have to get the user to manually switch stuff off to avoid huge demos.

one way to reduce bandwidth would be to pre-spawn your various particles/entities with the right frame/modelindex/colormap/skin/angles/scale/alpha already set.
then use only those entities for your particles.
this will reduce wasted bandwidth from resending the modelindex etc with every single packet.
qw/fte/dp are not so wasteful, so you won't gain much from that with those protocols.

anyway, pick your poison, give it a little momentum and someone will probably implement something eventually.
or just live with the user being explicit about it. 
NewHouse - Re: Fog 
When different trigger_fog brushes touch each other, the fog will actually flow from one brush to the other, through the joining faces, until the fog is equalised - so for example if one fog brush is full of red fog, and it touches a blue fog brush, the fog will mix until both brushes contain a purple fog. czg's Honey uses this extensively to get the smooth transitions between fog colors - different colored fog brushes are dropped onto invisible func_trains - the trains then move them around to collide with each other - when they collide, the fog mixes and you see a colour change. 
Ayy Lmao 
Thanks, that sounds so neat. I only can assume it can be used many other ways too. Maybe finally I can create that resembles doom's sector lighting even - but in form of fog. 
what* resembles doom's sector lighting.. 
Yes, it makes for a very flexible system with loads of different applications. 
ayy lmao kinda explained that poorly.
trigger_fog is NOT the same thing as eg q3's fog volumes.
the client can only use one set of fog at any time, which is applied to the entire map...
the trigger_fog brushes just change that client-wide setting once the player bumps into them, and its is applied smoothly over a short duration.
for practical purposes you're pretty much limited to one sort of fog per room, and transitions from one room to the next have to be handled really carefully to avoid the psychadelic world-changing-colour effect, typically by having small half-way rooms/corridors to keep the player distracted.
the smooth transitions mess up teleporters too.
they can be used for decent enough effects though, just remember that they're global and affect both near and far walls. 
Wishful Thinking 
anyway, pick your poison, give it a little momentum and someone will probably implement something eventually

Thanks spike for your reply. I was hoping that some kind of entity filtering happened when client demo's are recorded and another exception could be added to a list somewhere. I use the particle system built into DP/FTE so they produce better demo sizes.

There are so many new features I would love to be added to QuakeSpasm, but I do understand why they are not. Its just frustrating from a QC/MOD point of view as so many modern features (ie. global fog) are just hacks in QC to get them working. 
Would rock 
I will keep that in mind, I need to experiment a bit of it, after all my map will consist a lot of hallways, but I assume even elevator would work as a mood changer. 
Weather There Will End Up Being Weather 
I took a very quick shot at generating rain/snow and deconstructing the method used for Qrack's gl_rain.

Qrack gl_rain

Qrack uses for gl_rain video ... look at 13 seconds in to see gl_rain.

1. Take the sky surfaces.
2. In GLQuake, the sky is subdivided. (FitzQuake/Quakespasm it isn't and it would need a fake subdivision added in to have these rain or snow points.)
3. Average out the vertex positions in each sky polygon.
4. Emit rain from around those areas.
5. .. With a bit of randomness in origin
6. .. Some randomness in direction

End result is very easy rain.

But the fine tuning may be important ...
7. Appears to generate particles even out of view, which would be important if entering a new area.
8. But this means a ton of sky in a map is going to use a lot of particles.
9. But the particles at least "as-is" don't check for collision with the map or map entities (retractable bridge) and it would really need to. I can find indoor areas where rain comes through because outside a sky brush is over that structure.
10. Qrack does not appear to have rain in water, but I don't know if this is just because the particles don't last long (possible) or if I didn't find the code that killed off a particle that touches water.

Snow is would be easy to generate but possibly hard to fine tune.

Seven's DarkPlaces rain/snow

Video | Code + info

Another alternative would be the approach Seven used for DarkPlaces .

But Seven's DarkPlaces approach requires snow or rain emitting brushes in a map (func_snow or something?) -- which makes sense because QuakeC very likely has no way to know where sky brushes are.

Qrack's automatically identifying sky points method is vastly superior and easier on someone wanting to use it.

But there'd be a ton of fine tuning required.

I know because I took a quick shot at it screenshot.
1. Edit glpoly_t structure to add a vec3_t midpoint field and offset field.
2. Add a "rain think" in CL_RunParticles
3. Use -particles 8000 in cmdline // Default 2048
4. Pretty much take QMB_LetItRain from Qrack but adapting it to be just normal particles.
5. Some messing with Mod_PolyForUnlitSurface to pick vertex coordinates for snow/rain points. Would need some sort of fake polygon subdivision added back in to get it right.

(*) Seven's actual code appears to not use CSQC (client-side QuakeC), which would be better and required to avoid all of the problems with QuakeC rain (each rain drop particle is an entity, each entity saves in demos and has to go from server to client ... majorly big problems there). 
Note: The above is detailed notes for the benefit of whomever.

I took some time to chart it out, thought it would be good to record the info and make some notes.

But I don't really have time for engine coding--- especially something that would involve a lot of time intensive fine-tuning --- and don't want to create some sort of false expectation here.

On the plus side ... Spike seems intrigued by the idea of adding FTE's particle system to Quakespasm in the General Abuse thread.

If he would actually be willing to do something like that, that would be right avenue ;-) 
I have to say, I'm not sure I agree with this statement:

"Qrack's automatically identifying sky points method is vastly superior and easier on someone wanting to use it."

Unless there was some other way to limit which sky sections snow/rain could fall from, it would be a rather unfriendly situation to work with. Obviously the majority of cases it would be perfectly fine to have the particles fall from any sky surface, and it would certainly save on a few brushes, I can't think of a situation where it was better not to have as much fine-grained control as possible in content creation.

Just my 2 cents, of course. 
We'd still want the option of just spawning from all sky though - to suit the 90% of users who'd want to do it like that.

We'd certainly also want the ability to trigger sky rain on/off and change the density of it etc. midgame (like we do with fog triggers in AD and whatnot). 
Holy Shit Baker! 
That is some awesome info collation / analysis.

Best option (IMO) would be to use a particle based system from a func_weather/rain/snow brush. This way it could be triggered on or off, disabled in multiplayer, chosen where to implement and could allow flexibility in properties.

Style: snow, rain, acid-rain, etc
Density: distance apart.
Speed: speed.
Angle: straight down or xy

Am I going to implement this myself? Fuck no, I have enough shit on my plate already =P 
If You Did Do Sky Brush Emmission 
It could be blocked with skip brushes or skip the engine supported it which it should since particles should be blocked by geometry. 
*or Skip Should Read Or Skip Func_togglewall 
baker, if you're using points rather than triangles/polys, you're doing it the lame way.
you can find the correct(afaict) maths for an even distribution in eg fte's R_Clutter_Insert function. no need to subdivide that way, and you don't get particles spawning within walls either (excluding fpu precision, anyway).

the idea of quakespasm with effects like (please excuse the bugged gloss, that's an ooold video) and yet no texture replacements kinda makes me laugh.
at the same time, the idea of a load of cubes or quads or circles or whatever doesn't fill me with confidence either.

regarding csqc, the idea of that without any other qc extensions nor replacement textures is also a bit of a joke, at least for everyone but the guy trying to use it, who would get too frustrated to produce anything worthwhile.

really though, if you want an engine with a decent particle system and decent csqc etc, then just use an engine that already has that stuff.
in all seriousness, a low-res weather system is imho just going to look as goofy as eg the gloss in that youtube clip. sure, its interesting to do for the sake of doing, but I'm skeptical about the results and repercussions. 
in all seriousness, a low-res weather system is imho just going to look as goofy as eg the gloss in that youtube clip

What I had in mind visually, was something that follows the same kind of aesthetic as sock's particle stuff. It's totes quakey. Just simple pixelley spritey things. 
@Spike -- interesting points ... of course my attempt to was to chart out existing bodies of work --- I was curious as to R00k's method of picking rain origin points.

Snow? I was thinking a bit subtle along the lines of Nehahra snow.

... but adapted to look a little more like Seven's DarkPlaces snow.

I'm in the school of thought that map effects in this game should add very gently to the content they appear in. Versus the idea of the effects being the center of the attention.

/Which may be largely academic, lack of time and all that ... 
Baker, that video almost perfectly describes what I was thinking in terms of weather effect quality. 
"I'm in the school of thought that map effects in this game should add very gently to the content they appear in. Versus the idea of the effects being the center of the attention. "

Wins the thread.

Also that video is nice and subtle, yeah. Works well. 
Yes That's The Stuff 
Nice and inoffensively quakesque. 
Pixellated Snow/rain 
is perfectly fine for those engines aiming for a "classic" feel. Anything else would be jarring. 
Looking at the neh snow video, it's striking how something so simple adds so much life to an otherwise static scene. A Good Addition To Quake. 
The same way as Sock and other top modern mappers use fog and coloured lighting. 
Custom Resolutions 
So, is it possible to use a custom screen resolution in full screen mode? Setting vid_height, vid_width in the config appears to do nothing unless it fits one of the standard resolutions available in the in-game menu. 
The menu should list all the video modes that your driver says it can support, so probably not, unless the list is incomplete. 
Bah Humbug 
Well, I'm trying to set it to 960x540 on my 1920x1080 laptop lcd (so, exactly half-resolution).

960x540 doesn't appear in the menu :{

Reason I'm trying this is because I think quake looks best at around 480 vertical resolution. I figured if I could set it to exactly half-resolution of my LCD it might minimise the shitty blurring that happens when LCDs try to display lower than native res. 
Play It Windowed At 1280x960 
that is 2x scaling

nice and simple. 
Well, I'm trying to set it to 960x540 on my 1920x1080 laptop lcd (so, exactly half-resolution).

I tried exactly that a few days ago with no luck :( I thought I was just doing something wrong, guess not... 
I'm trying to get a low-resolution display of the game blown up on the screen so I can see da pixels nice and chunky.

Anything in windowed mode isn't going to be blown up - unless I'm missing a trick here?

Also, I still kinda want it fullscreen and using the same aspect ratio as my monitor.... 
I always felt you had impeccable taste. 
Me Too 
Uh, Run In Dosbox With Dosquake? 
might have more luck

-width 960 -height 540 -fullscreen quakespasm in linux just defaults to 720p with a black border 
also, i assume you've run vid_describemodes in the console? 
Uh, Run In Dosbox With Dosquake?

Nah, that sounds like a rubbish way to play QuakeSpasm. 
Ah Gotcha 
so install windows in dosbox then install and play quakespasm 
also, i assume you've run vid_describemodes in the console?

Yes, hence:

960x540 doesn't appear in the menu

Anyway, if my laptop just can't display 960x540, then I guess I'm out of luck. Stupid laptop. 
What kind of GPU is in the laptop? On this computer (Geforce 210) the Nvidia control panel seems to think it can set a custom resolution not supported by the monitor (LCD 27" 1920x1020"), but by default only lists the standard resolutions down to 800x600. I've never tried it though. 
GeForce GTX 765M 
Creating Work For Other People 
This is my attempt at getting some of the things that annoy me about quakespasm resolved, as well as some stuff that I think people like Sock would want to use if they could.
1 patch
1 readme
1 qsextensions.qc file
1 win32 binary (without deps)
some source files (without libraries)
1 copy of the gpl license...

Check the readme for the actual changes.
I'll probably update it a bit when people find all my bugs, or if someone I respect critisies me for not bothering adding something I was too lazy to bother with or didn't think of. Or other weasel phrases that get me out of any obligations both expressed or implied... 
Spike makes it sound boring. Has some very, very serious Kung Fu in the patch.

/Laughs are strlcat/strlcpy inclusion, I can't stand to see code that doesn't use those BSD originated functions. 
goddamn, just seeing QC file access stuff is almost enough to get me modding again. I haven't even read the rest of the readme! 
what is "bsp introspection"? 
Bsp Introspection 
@Kinn, posh words for DP_QC_GETSURFACE (which is handy for figuring out textures, or weird particle effects or whatever, I've used it to align csqc UIs to walls in the past, but meh). AD uses it to fix solid-sky issues with vanilla maps. smc uses it for figuring out footsteps, etc.

@Baker, strlcat+strlcpy were already in there. I just included ALL the .c+.h files from the 'Quake' subdir, because I'm lazy. I only two new .c files, but they're both bigger than any of quakespasm's existing c files...
check the patch for the actual changes, and good luck trying to isolate the parts that you're interested in. 
Pretty Cool ... Best Stuff Is Easily Seen In Readme 

Spike adds the (float) type cast.
But in C, variadic parameters of float are converted to double.

/Just a jokey comment.

Misc Noticed #1 ...

#define TEDP_PARTICLERAIN 55 // [vector] min [vector] max [vector] dir [short] count [byte] color
#define TEDP_PARTICLESNOW 56 // [vector] min [vector] max [vector] dir [short] count [byte] color

Misc Noticed #2


eliminate pink edges on sprites, etc.
operates in place on 32bit data

spike -- small note that would be better to use premultiplied alpha to completely eliminate these skirts without the possibility of misbehaving.

Misc Noticed #3

Spike does something with SZ_Clear and SZ_GetSpace, probably fixing a bug. Looks like buf->overflowed was set to true, then nuked. However, the buf->overflowed=false was removed in SZ_Clear and SZ_Clear is called all over the place. (Mistake?? Too engine rusty but looks like a possible mistake. And what bug was it fixing? I believe there is a bug it was trying to fix)

Misc #4

Looks like Spike made MAX_MTU work on packets (it never worked in Fitz 0.85) and then implemented something to allow multiple ones. (Wondering, is backwards compatible? I would guess no. And backwards compatibility probably shouldn't be important in this case.)

Misc #5


#define NUMQUAKECOMMANDS (sizeof(quakebindnames)/sizeof(quakebindnames[0]))

I hate it when people don't do that, haha.

Misc #6


"spike -- this is actually a pointless waste of memory.
//its not like this data will actually be used beyond this function in any gl renderer.
//this makes copying it pointless"

memcpy ( tx+1, mt+1, pixels);

@Spike: In Mark V, I use that data to allow real-time toggling on/off of external textures. And if I recall right, I use that data to quickly reupload textures if a video resolution change occurs that doesn't let GL context be reused without re-reading it from disk.

Misc Note #7

Some great comments in net_dgrm.c


Anyways, it's all some very nice and incredible stuff in there! 
Spike - cheers - sounds very cool :)

oh wow the particle system sounds great :o 
Any Chance Of A Translation? 
Not everyone on func_ is a programmer/wizard/jesus... what's all the excitement about? 
There's a readme in the download. Kinn has rummaged through it.

I didn't reveal hardly any of huge surprises. 
@FifthElephant, sorry, I suck at explaining, so I left it kinda raw.

basically, there's:
1) a load of boring uninteresting stuff that mods might use. eg, you can imperfectly run smc (check the readme for the issues I know of). smc itself isn't the aim, but the lack of any extensions in fitzquake-derivatives is why we can't have nice things like string concatenation or traceboxes in the mods that really should be using them instead of crappy hacks.
2) some networking fixes/tweaks that if nothing else should make coop significantly easier to get going, just open a udp port, set your server as public, and people should be able to find you.
3) particle system that can be used by mappers to emit custom particles from surfaces based upon their texture names, like rain, snow, sparks, etc. I should give a proper example of this.
You can also use particle configs made for either fte or dp, just so long as they didn't use jpg or png textures, but that wasn't the real aim here, mostly for rain/snow/sparks/emittance/smoke vents/etc.
4) some other stuff. ramble ramble. modders blah blah. *continues to make uninteresting noises*
there's not really meant to be anything fundamentally new here (if there was then I'd have added it to FTE first, thereby making it not new). Really its just a version of quakespasm that tries to NOT be crippleware for modders, as well as fixing some networking/connectivity issues.
it still has no csqc nor replacement texture support. :P

The thought of people doing non-quakey things with the particle system is a worry, but hopefully the community and that continued lack of replacement textures will keep those people grounded somewhat.

#2) alpha testing with a reference value of 0.666 will probably kill skirts well enough, but with linear sampling you get weird curved shapes to it. when blending, premultiplied alpha is much better, especially with mipmapping. I was trying to tread lightly and I'm lazy so I just left it as a comment rather than making any actual changes there.

#3) few things use allowoverflow, and thus few things can actually have the overflowed flag set. really its just unreliables, and those only check the overflowed flag when there is actual data inside them. that change just makes things a bit cleaner in that case.

#4) really I just reduced the mtu size of reliables back down to 1450, from 32000. nq always fragmented reliables, but it used the same value for reliables and unreliables. unreliables are still unfragmented and I didn't change any limits there, so there's nothing 'new' here. reliables now fragment much more frequently, this will have increased latency and made (non-local) load times worse, but should keep packet sizes below ethernet thresholds, preventing 100% packet loss and the inability to connect properly.
the protocol itself is identical, the receiver is in no way harmed by this change, but its still above 1024 and thus will still be an issue for vanilla clients.

#5) I have a countof macro in fte.

#6) I stopped copying the extra mips (because only fte would dare trying to use those in a gl renderer), but it still copies+preserves mip0 because of paranoia (I couldn't be arsed to read through the entirety of gl_texmgr.c to make sure it was safe).
And yes, I can be quite harsh with my wording even when I don't follow it myself, sometimes its just easier to not bother fixing it - I'd say it was nice to know what you could be fixing, but frankly its more a reminder of how many things you cba to fix... Lets just say that the comment was for a rainy day.

#7) well... I'm glad someone got something out of it at least. 
Awesome Stuff Spike 
some stuff that I think people like Sock would want to use if they could
Wow this is just awesome, QS + DP/FTE particle effects! Spike you are coding genius! Really nice to see all my DP particles flying around! :D

So I manually load the effectinfo.txt file (with the QC you specify in the readme file) and AD starts to use the new effects. For some reason I am getting 'backup Past 0' constantly spammed to the console when I load a map. I tried out ad_test10 and I get the following visual issues. Not sure how to fix this, any clues? 
backup past 0 is a traceline/tracebox thing (I think I included a note about how the vanilla code was stupid, but didn't dare fixing it due to probable precission differences and resulting minor incompatibilities).
the particle system does quite a lot of traces against the world and brush entities, so I guess I ought to try to rewrite that, even it it ends up behind a cvar.
or maybe I should just make a specific version for the particle system, where precision doesn't matter so much.

the diagonal Os look like a REALLY big copy of the particle font... I have no idea what's going on there.
the lines in the middle are something else, and the bit on the left is utterly bizzare, I've no idea what they're from either.
Hurrah for making sure I retested everything!... or not!...
only things I can think of is a NAN (possibly from uninitialised memory, a degenerate triangle, or even qc (read: division by 0). note that this could also explain the 'backup past 0' spam).

also I suspect I broke weather effects by trying to get decals working, it might be related. shows how much I test things...
I'll be sure to test ad_test10 to see if I can reproduce it.

try setting r_particle_tracelimit to 0, that should stop it from spamming traces (which will also disable blood decals).

Sock, just so you know, I also snuck in a 'cl_recordingdemo' cvar which will contain the filename, use cvar_string to read it or something. :) 
the glitches appear to be from decals.
it doesn't seem to happen in debug builds, so its probably something that I left uninitialised somehow.
I don't get the 'backup past 0' spam. 
cheers, this looks crazy!

Speaking of coop, I tried to run ad_swampy.bsp in coop last week, with QS svn.

The unreliable message limit of DATAGRAM_MTU = 1400 for nonlocal clients (here) was making it unplayable, was getting lots of "Packet overflow!" and most entities were not visible. Everything seemed OK once I uncapped that to MAX_DATAGRAM (32000).

Does it sound reasonable to remove that 1400 cap for nonlocal unreliables, maybe only use it if a cvar/cmdline flag is set?
I understand that large UDP packets are frowned upon and more likely to be delayed or dropped.. but not handling large maps/mods at all is worse. (I assume there is no way to break up the SV_SendClientDatagram message into multiple udp packets without changing the protocol?) 
re: "backup past 0" spam, it only happens with "developer 1" 
reliables larger than the mtu = server keeps trying to resend, blocking delivery of all later reliables. this especially includes the serverinfo, making it fatal even on tiny maps.
datagrams larger than the mtu = game packet gets dropped. when whatever activity goes away (ie: gibs fade out, the other players stop spamming shotgun effects, etc) then the game recovers.

nack networking (namely, fte's replacement-deltas protocol extension) was one of the things that I was considering adding, and would fix the huge unreliables issue, by splitting up huge updates into multiple frames.
the client parts border somewhat on trivial (at least if you're familiar with 666 etc), but the server side can get messy with logs and flags and resends and figuring out what consitutes a nack.
in contrast ack protocols like qw just spam everything every packet until acked, and are actually quite expensive on ram on the server.

remember that there are two protocols here.
if you're unwilling to change the nq protocol, you might be more willing to change the 'netchan' (ie: net_dgrm.c) to split+reassemble.
there's a limit to fragmentation though. bursting more than 4 fragments will generally result in the extra ones getting fragmented, so if you were to fragment that way, I'd suggest to have each unreliable fragment be complete in itself, so that they can still be reassembled even if there are gaps.
large unreliables will break the vanilla client anyway. so yeah, its important to know what you're trying to talk to.

I guess I ought to try to do the nack deltas thing, huh.

and yeah, I forgot about developer 1. :/ 
Just give it FTE's QW protocol support with map/model download so people can actually coop, throw in minimum CSQC so Sock's particles live on the client.

Why add another bandage to NQ's primitive protocol -- when you have insane skill levels which are fairly incomprehensible to even most of the rest of the engine coders?

(I mean, you spent how much time on this? A week? And there is other stuff in there too like IPv6 support no one has said anything about ... )

Then get a book deal.

"John Carmack Started Quake; Spike Finished It!"

/This update has a rather eye-popping feature set already. When I opened your download and looked I was like "WHAT?!?!?" 
Feature Request: Flood Fill Exception 
I've got a small request relating to model rendering. Quakespasm has the same code from Fitzquake which flood-fills the "background" of a skin with black. This is to remove the bright blue background of some vanilla model skins, which can show on seams.

The flood filling locates the background by assuming it starts at coordinate (0,0). Imagine one of the simplest models possible, 2 triangles forming a rectangle, with a rectangular skinmap that fills the entire skin, and the entire skin flood-filled with white. This model's skin gets turned entirely black by the feature, because the skin is no-background, all-foreground.

There are workarounds, like making sure that the pixel at (0,0) is differently coloured to her neighbours. However, this still compromises the model somewhat, because that pixel is still visible on the model, and must be black in colour in these engines.

My proposed fix is modest: if a model has a UV coordinate of (0,0) for any vertex, then don't apply the flood fill code. None of the original models the code is trying to fix have this coordinate, so it still does its job there. Any model which has a UV there clearly doesn't want flood filling to occur, because the point you want to start filling from is part of the skin, not the background. It even allows for an "opt-out" hack where an isolated vertex is added to models at that coordinate to disable the flood-fill even if the model doesn't use that pixel. 
Take 2.

decals seem fixed (sorry for not spotting it earlier). I've also replaced the particle traceline code with my optimised version to mute spam.
I added an example 'weather' particle config too, for people to experiment with.

@preach, doesn't sound too unreasonable, frankly that flood-fill stuff is just annoying. personally I'd probably just fill it only if it was that specific colour...

@baker, ipv6 is easy really, mostly just a copy+paste with the address families switched over, some different structs+field names, and a slightly different 'broadcast' mechanism where its the receiver that decides if its willing to receive broadcasts rather than the sender. simple stuff really. Besides, I'm not all that great a coder, I just know quake well.
regarding protocols, if you want FTE's full protocols, just use FTE. FTE's 'PEXT2_REPLACEMENTDELTAS' extension (catchy name that) should prevent the need for huge unreliables as well as providing a whole load of extra entity state that probably noone cares about. The client parts shouldn't be too bad, but the server parts would spawn lots of bugs, so if did port that stuff over, it would be as a separate patch.
That combined with voip.
I wouldn't know where to stop with 'minimal' csqc...

if you want qw protocols in an nq engine done the lame way, read 
This is all super badass. A possible future feature that I've thought would be mega useful would be QuakeC functions to draw textures to the HUD.

Once you can control the drawing of the HUD from QC, this really opens up a ton of stuff for modders (custom inventory displays, map name it) 
Take 2 
All the Backup spam is gone, decals works fine for me, but they seem really bright (colour wise). DP always made decals really dark, not sure why but all the decals look like they are glowing full bright.

I get spam on the console about not caching particles, but I have loaded the "effectinfo.txt" file so all of the particles should be setup. I am sure DP was doing the particle cache when the effects file was loaded, unless the message means something else.

I have updaded my world.qc with the new engine detection conditions (FTE_SV_POINTPARTICLES and FTE_PART_NAMESPACE_EFFECTINFO) and everything seems to switch over perfectly.

For some reason "traileffectnum" is missing so I don't have custom particle trails on plasma projectiles. Is it possible to check for this being missing? So I can fall back to the QS particle trails system instead. I know there is "trailparticles" but that is useless for traveling projectiles because you have to keep drawing the trail start and end positions all the time in QC. 

I wish this feature was available 20 years ago. Setting half the bindings via configs in complex mods was so clumsy. 
QS-Spike Particles 
@Spike, I am getting some strange particle emitters under the world geo and I am not sure why.

The size of the decals seems wrong, DP vs QS-Spike blood decals feels like a paintball game.

The size of particles in general seems to be larger with DP vs QS-Spike being very different. I tweaked all the DP effects to be a certain size and now everything feels too large. 
My Gawd 
particle system that can be used by mappers to emit custom particles from surfaces based upon their texture names, like rain, snow, sparks, etc. I should give a proper example of this.

Spike this is incredible stuff man, thank you for your efforts! I would love to see an example :O 
QS-Spike Particle Scale 
@Spike, the engine scaling of particles seems to be affecting everything. Here is an example of the floor circle effect to show the difference of the scaling between DP and QS-Spike engines. 
@kinn, you mean csqc? :P
rmqe has some simple csqc support that could possibly be used for huds or menus, but I don't think anyone really tried it.
if you want ssqc, then fte has 'tei_showlmp2' which allows adding/removing various persistent stuff relative to various parts of the screen. even dp has an svc_showlmp feature that nehahra used, but its only relative to the top-left of the screen. either form is really annoying to use.

@dwere, fte has had that for a long time. :P
kinda needs various cvar settings too though.

@Bloughsburgh, there's a weather example in the r2 zip. put the cfg in the right dir, use some console command or add a worldspawn key, restart the map, check the results.

@sock, precaches:
dp implicitly uses the effectinfo file to define the effect numbers, with both the client and server parsing the files themselves. this means that the excrement hits the extraction device if they differ. It also sucks big-time if you have multiple different particlesets loaded at once, or in other words DP has no user choice.
I could have QS parse that file server-side and auto-generate precaches that way, but that would mean two things: 1) the protocol is unconditionally changed even if the mod doesn't use pointparticles (the built-in effect names would need to be pre-assigned). 2) there's a whole load of redundant precaches if the mod uses the "effectinfo." prefix thing.

particle scales: clearly I don't use DP enough, I'll need to look in to that.
dlight scales: I assume rockets give off different dlight sizes in both engines too, without any extra particle system. at least I assume that's what the floor circle effect screenshot was meant to be showing.
looks like 4-fold scaling with decals, maybe 2-fold with particles.

emitters: o.O near the origin, too, but also far too regular.

traileffectnum: this is mentioned in my readme as not supported, because its actually part of the entity state rather than a simple addition via a new svc. if I add the replacement-deltas protocol extension then I'd be sure to include this then, but I want to ensure everything else works before I screw everything else over (assuming I ever do).
until then, you can make a particles/trails.cfg (loaded the same way you're loading effectinfo) that contains "r_trail progs/foobar.mdl effectinfo.tr_foobar" lines.
ideally you'd use r_effect (and using count instead of countextra and its framerate-dependancies) for static entity emitters like torches or items, but I can understand you wanting closer dp compat. 
kinn, you mean csqc?

God knows. I haven't done any quake modding since 2005 so this may as well all be new to me :) 
Snow Video Using QS-Spiked-R2 
Yeah... the snow is well done. tehspiderman1 ! :)

Thanks for Spike's stuff :) 
Xmas Jam 
Better happen 
Is sv_protocol 999 supported now too? 
QS 0.92.0 added support for 999, not me. 
My bad, I thought 0.91 was latest. Manifestation page doesn't specify.

Now I can test the rest of my test map. 
Branches Page Should Be Updated 
Fog Distance Versus Density 
Is there any option for a fog starting distance?

Also is there any option for a max fog density? Currently density is only based on a distance from the player view origin and anything at vast 999 protocol distances is put at max density. I would like to be able to set the max density to something like 0.2, have a density of 0 for like 1024 units or so, then gradually transition fog in from 1024 out to 8192.

Yeesh Qmaster whats next!?! a defined multiple fitted density curve??? 
Mark V has a "fogex command" with start and end.

fogex <fade>
fogex <start> <end>
fogex <red> <green> <blue>
fogex <fade> <red> <green> <blue>
fogex <start> <end> <red> <green> <blue>
fogex <start> <end> <red> <green> <blue>

Sock want to play with such a thing, so that's why the feature is there.

Sock toyed with it once a few years back, and I think even Sock couldn't find a compelling use for it.

So you do have an outlet to at least satisfy your curiosity. 
You can't mix distance with density in fixed pipeline fog; it's either one or the other but not both.

If GL_FOG_MODE is GL_LINEAR the start and end parameters (only) are used. Otherwise the density parameter (only) is used.

If you just implement everything in shaders you can supply your own fog equation which does this, but then of course you're raising the minimum hardware requirements.

This is similar to some of the discussions that went on during RMQ work: maximizing hardware coverage and desired features are often contradictory requirements, and you often can't have both. 
Can't Run Spiked R2 
"Application Error"

"The application was unable to start correctly (0xc000007b). Click OK to close the application."

regular Quakespasm works. What am I missing? 
People do not use Voodoo graphic cards anymore 
Found The Issue 
I have to use a 32-bit install of Quakespasm, not the 64-bit. 
Pretty irrelevant, but if you try to start 2 sessions of Quakespasm-spike.exe, you get a "Unable to bind to (already in use)

Too tired right now to satisfy my curiosity and see how/when the sockets are bounds for single player for a non-listen server.

/Total non-issue anyway, but unspiked Quakespasm doesn't do it. 
Super Important Feature 
Is there an way of enabling no filtering (i.e. crunchy pixels) on the particle textures? If not, can this be added? (Oh god please say yes) 
surely it obeys gl_texturemode, right? 
Amen To That Kinn, Pixelly Goodness! 
surely it obeys gl_texturemode, right?

it's probably a 1 line of code change to add that, so no biggie.

I have to use a 32-bit install of Quakespasm, not the 64-bit.
The only issues I've had with the 64-bit QS were conflicting dll's, IIRC you can't have 32 and 64 bit QS installed in the same directory. 
its all part of spike's evil plan to stop people from using nearest-filtering!...
that or I was just trying to get DP's effects to match, as well as fte's existing particle configs too. high-res stuff (unlike vailla quake) imho looks better with linear.
mix-n-match stuff stops it from being a 1-line change.
probably I'll add some 'nearesttexture' command for it in the particle configs.
side note: the classic particles don't respect gl_texturemode either.

and yeah, the build that I provided is a win32 build, so you'll need the 32bit dependancies.
I could provide both binaries, but for me its easier to focus on a single arch (yes, I'm that lazy).

I have fixes for sock's issues, but I got distracted by the huge deltas... and I now have to fix a load of code, and finish writing a load more. :s 
true, but you can make classic particles square using another cvar, which i think is good enough.

Good point on the high-res content, but then, I'm not sure which is the best way to mix low-res quake textures with high-res effect images, there is an inherent clash of styles there. But if someone wants to make a quakey-looking low-res raindrop, they should be able to make that nearest-filtered. 
Which cvar is that for making the standard particles square? 
r_particles 2 
Cannot Compile On Linux 
In file included from progs.h:27:0,
from quakedef.h:226,
from gl_refrag.c:24:
progdefs.h:25:23: fatal error: progdefs.q1: No such file or directory 
Cannot Compile On Linux 
The code from, that is. 
Grab the progsdef.q1 from:

To solve your immediate problem. 
Miscellaneous Behavior Difference 
type map i_dont_have_this_map

Quakespasm 0.92: Console: couldn't spawn server maps/i_dont_have_this_map.bsp
Quakespasm Spiked: Fatal error dialog: "Quake Error: SV_ModelIndex model progs/player.mdl not precached

Maybe some sort of missing model support similar to DarkPlaces and presumably FTE.

But not having the map will kick you out of Quakespasm as it is a "Quake error" that terminates Quake. 
Uh Oh 
Host_Error: Mod_LoadLeafs: 121741 leafs exceeds limit of 70000.

So..why is there this concept of a limit anyway. Why can't we just keep allocating more memory as needed and just use more RAM until we run out.

On a related note, why not just precache the entirety of the progs and sound folder at start and forget about precache warnings. Just use more RAM. 
Is the map sealed?
If it's leaking, seal it and the number of leafs should go down by half or more.

No hard limit on leafs is a thing on my wishlist.

Just precaching everything: I guess it would make loading slower, cause issues on old/slow computers, and content depending on that feature would not work in other engines. 
Precache All Could Be A Cvar 
cl_precache_progs 1
cl_precache_sound 1
cl_precache_all 1

Or maybe something like heapsize would be better:
-precache 3 (1 = folder only, 2 = sound, 3 = all)

That way there would still be compatibility with old hardware such as only 1GB ram. 
Quoth has a method to automatically precache custom sounds and models in entities in a map. AD very likely has this too.

Might tell the people in the mapping help what you are trying to do. The solution via QuakeC probably already exists. 
small note: fteqcc's new #merge feature allows 'merging' new code into an existing progs. Combined with the __wrap keyword, you can change existing functions and stuff rather than just adding.
it would be worthwhile even if it was only ever used to add something like misc_model into every mod.
The feature is still a little raw and a little wasteful, and maybe a little too permissive as well, but should otherwise work without needing to decompile anything (and without all the resulting breakages of decompiling). 

That way there would still be compatibility with old hardware such as only 1GB ram

A full Quake install is about 80 mb... 
The idea of precaching all available models is flawed anyway. Health and ammo boxes are .bsp models.

Are you going to precache all the maps in the map folder? No. And there isn't a non-hacky way to distinguish between .bsp that is an ammo box vs. one that is a an actual map.

/Although Mark V actually cracks open the .bsp models and looks for an info_player_start and if it doesn't find one, assumes it is a health box or ammo box or non-playable .bsp

All of this is skipping that to record a demo in anything resembling standard Quake, you have to have the model precaches known in advance. So then you would have to add protocol modifications too.

You would also need to add DarkPlaces missing model support for the feature to work right, because since you aren't using precaches a client has no idea of what it actually needs to play the game.

/Quoth and probably AD already have misc_model support and some sort of equivalent for sound. The right tool for the job already exists. 
I only mean progs folder and sound folder, not the maps folder.

I'm merely curious from a technical perspective why the precaches are even needed. If, let's say, a mod were to precache each and every model and sound in world.qc then no further precaches would be needed any and all info_notnull hacks would work fine as an example benefit (also modders wouldn't need to care about adding those ugly precache lines that are so easy to forget about).

So why not just precache each file in those two folders in a for loop whenever worldspawn is first called. Seems like a pretty neat feature to me.

I don't follow what you mean by demos requiring precache or even what the protocol has to do with it. If its all precached its precached. Mind you I'm only coming at it from a qc perspective. 
Because it isn't compatible with standard Quake.

And that's always been the goal with conservative engines like FitzQuake and Quakespasm.

DarkPlaces is the engine you are looking for. Doesn't DarkPlaces give you a haughty warning like "You didn't precache this, precaching anyway".

That's LordHavoc saying "You are not doing it right". 
In fact, I think it used to say "Model is not precached. Fix you mod. Precaching anyway". 
More Explanation 
Precache everything ...

DarkPlaces has client/server download of maps, models, sounds, etc.

Someone does a coop game, the client asks for a list of maps and models from the server.

The precache everything idea would cause a client to download a whole ton of stuff off a server, whether or not it was needed. 
Benefits Of The Precache System ... 
In the case of DarkPlaces, map + model + sound +etc download ...

The server load the progs. If there are no Shamblers in the map, there is no precache of the shambler model, the shambler head, the shambler sounds.

Same if there are no Vores. Etc, etc.

This allows the server to offer the bare minimum of required assets to client.

See this:

void() monster_shambler =
if (deathmatch)
precache_model ("progs/shambler.mdl");
precache_model ("progs/s_light.mdl");
precache_model ("progs/h_shams.mdl");
precache_model ("progs/bolt.mdl");

precache_sound ("shambler/sattck1.wav");
precache_sound ("shambler/sboom.wav");
precache_sound ("shambler/sdeath.wav");
precache_sound ("shambler/shurt2.wav");
precache_sound ("shambler/sidle.wav");
precache_sound ("shambler/ssight.wav");
precache_sound ("shambler/melee1.wav");
precache_sound ("shambler/melee2.wav");
precache_sound ("shambler/smack.wav");

self.solid = SOLID_SLIDEBOX;
self.movetype = MOVETYPE_STEP;
setmodel (self, "progs/shambler.mdl");

setsize (self, VEC_HULL2_MIN, VEC_HULL2_MAX); = 600;

self.th_stand = sham_stand1;
self.th_walk = sham_walk1;
self.th_run = sham_run1;
self.th_die = sham_die;
self.th_melee = sham_melee;
self.th_missile = sham_magic1;
self.th_pain = sham_pain;


If there are no Shamblers in a map --- i.e. no monster_shambler --- it doesn't get precached, the server never has to offer any of that stuff to the client --- in the case of a client offering download like DarkPlaces.

In the case of even a standard Quake client in single player, these do not need loaded into memory. 
no precaches = no name->index->name network compression = omghowmuchdatadoesthisgameneedtosend.

precaching everything = oh look you have more than 256 models that were auto-downloaded from that server you forgot about 10 years ago, so I'm just going to crash now.

that first thing is the real benefit here. if you don't bother precaching then there are issues and lag between when the signal to precache and the model change happens. the second, combined with horrendous loading times, is what prevents the server from scanning+precaching (although if you really wanted that you could always use the search_* builtins from ssqc).

Late-caching (as I'm going to refer to it here), like in DP,FTE,QS'S', is fine for the most part, but there are still some significant gotchas...
Essentually, precache updates are generally sent over the reliable channel, and reliables are 'slow' - they can only be delivered if the prior reliable was already acked. So, if you do a precache_sound("foo");sound("foo"); pair (or the precache is implicit), it is very likely that the sound event will arrive before the precache. The client will then not know what the heck the server is talking about, and the client will be forced to ignore that first call.
This is why engines still have a hissy fit about implicit late-caches. The correct way to use it is to still do it ahead of time. When a client first connects in the case of their player model+sounds for instance, before other players are likely to see their model, or need their sounds.
late-caching an mdl is generally safe, the client should start to display the model once the precache does finally arrive. however, csqc may have issues with it if it can't figure out the model names.
late-caching a bsp is probably problematic because its likely that the client won't rebuild all the lightmaps.
late-caching a sound is likely to result in sound events within a short period just getting lost. The same applies to particles if the engine isn't automatically making up some random precaches on your behalf.

The clients in question are fully within their rights to only actually load the model/sounds once they're needed (vanilla quake's flush command will actually purge mdls and wavs from memory and reload as needed, thanks to its cache mechanism to run on only 8mb ram).

So yeah, precache things properly but not wastefully. If your precaches are dynamic then be sure to leave a delay between the initial precache and when the resource is used. And if you're lazy, at least admit that by putting the 'precache' right next to your setmodel call in a way that should feel as icky to the quakec coder as the resulting behaviour is to the engine).

Otherwise yeah, what Baker said. 
Scratches Head... 
Aren't precaches done locally? If it's server-side does the server send the client a list of models used? Does it matter how long the list is?

So if Mr.Modder, thinking he will save himself the trouble of all those pesky precache warnings (Insert a "Stop all the warnings!" meme here teehee)creates a mod where all 300 custom models and all 654 sounds are precached from the progs and sound folders inside his mod's pak0 file and all these "wasteful" precaches are done in the worldspawn function at game start...what would happen? Crash? Or would it only cause problems for multiplayers joining his game and demo creation? 
The server does send the client a list of models/sounds needed to connect, there is a limit but it is fairly large. DarkPlaces shows this as a bar at the bottom of screen even in single player, Quakeworld clients do it as well.

Other stuff: try it. Start up DarkPlaces twice and have one connect to the other. See what the loading/downloading time is, keeping in mind the internet is way, way slower than LAN or same computer. 
I Don't Use Darkplaces Anymore, I Only Use This Awesome Quakespasm 
Quakespasm Review By Gunter 
I talked Gunter into doing a review of Quakespasm.

He's a very detail oriented guy who plays a coop mod online:

Quakespasm Review by Gunter 

Uses fte's replacement-deltas protocol extension by default. helm18 is actually playable for me now (the 10k knights map). The limit is now the renderer+server logic now.
Disable with eg: sv_protocol -666, but leaving it enabled won't hurt existing 666 clients.

Don't expect more big changes any time soon, although I'm still open to bugfixes for the things I broke in the hope that this gets stuff finds its way into the official quakespasm.

Why do I constantly feel like there's something I've forgotten to do?.. Feel free to remind me so I can get annoyed about it anew.
Ooo, maybe its multiple things! 
Minor questions for you whenever you have the time ...

I've tried seed at least fundamental information and examples including looking through engine code some ...

1. Is there a way to specify a particle effect should generate even if the particle would not be in view?

I know in the hands of someone who doesn't understand the mechanics this would be undesirable, but unlike deathmatch (Quakeworld uses of a particle system) where particle effects are primarily used for weapons blasts the uses in single player would be more for persistent weather.

If every time you look at the window, it has to restart the rain from nothing that is undesirable.

2. Is there is a method to see what the current particle count is?

So a mapper can measure the effect burden and make sure the author isn't creating situations where the particle count continually increases because the rate of creation exceeds the rate of destruction (die time, etc.)

3. What "attribute" would kill a particle if it hits a liquid?

4. It looks like models emitting effects is disabled in the particle system (like ability for a pent to emit stardust or what not --- I've seen this effect in DarkPlaces)? I could see that be used to make broken panels that emit sparks in a base map, for instance.

Was there a certain reason that you felt that was undesirable in an engine like Quakespasm or would it have introduced a code burden?

5. What method controls the particles count cap? How do you set that limit?


Very awesome feature set Spike! 
1. surface emittence is based on the distance from the view rather than frustum. so keep emitters away from teleporters and use short-lived particles you should be fine. snow will always be problematic in that regard.

2. r_partinfo

3. you can only do it on initial spawn. overwater or notoverwater will filter that effect. use the +foo stuff if you want the particle system to spawn one sort above water and one underwater.

4. using countextra/countabsolute for static effects on trails or emitters is evil and framerate dependant. that makes it undesirable. use r_effect if you want something to emit particles constantly. use r_trail if you want it to emit particles as it moves.
the previous build lacked any protocol extensions for entity fields. the replacement deltas stuff fixes that in r3, so you can resume using flawed stuff for compat with dp.

5. r_part_maxparticles or r_part_maxdecals. Changes to these cvars should take effect on map changes. 
Random stuff:

1. The delta compression should be a big help for coop.
2. Looks like you added makestatic so someone could, for example, make deadbodies from monsters into static entities.

(Is there a way in QuakeC to know if a monster's dead body is in on a lift (i.e. died on a brush entity, not worldmodel)? Specifically to not makestatic those particular dead bodies?)

3. In a previous reply to ericw, you had talked about implementing a mechanism to send multiple packets in the event they exceed 1542 +/- bytes for coop --- is that implemented? I can't tell from the readme if that was implemented.

4. DP_QC_GETSURFACE, so broken vanilla skies stop being broken -- raises this question --- what is a broken vanilla sky?

5. SOLID_CORPSE. Memory block, even reading the DarkPlaces description of SOLID_CORPSE, I can't recall the main use of the feature -- even though I remember it is useful.

6. Sprite groups. spritegroups will now animate properly - this was a vanilla glquake bug Are you aware of an existing mod that used sprite groups? Hipnotic? Rogue? 
(No one will care except Spike but I meant to type 1442, not 1542) 
View Dependant Particles 
Could particles be cached in their current state (i.e. paused/frozen), when out of view and then resumed when in view? 
2. makestatic was a vanilla thing. I've not touched it. I probably should do for extra fields, but that would mean that I'd have to actually add support for that.
either way, if the corpse isn't moving then the protocol changes mean that it'll only be retransmitted when it first appears/disappears, there's actually little need for makestatic now.

use tracebox to see if its sitting on a lift or something. or failing that a traceline. or just check thecorpse.groundentity

3. that's in this build, it probably ought to stick to a single packet due to burst, but I didn't include any prioritisation for players and skipping the player every other packet would make it a bit too jerky without better lerping, so it just spams.

4. those solid skys that give particle effects when shot, that affects some percentage of the vanilla maps.

5. so one tracelines and projectiles will hit corpses and yet monsters and players will just walk through them.

6. dpmod is one such mod. go on, get it to run in markv or something. 
"Why do I constantly feel like there's something I've forgotten to do?"

Everyone forgets to add support for 4 players and splitscreen... (FTE doesn't count cause I cant get it to work properly) 
I asked Gunter if he'd be willing to give your Spikespasm a test drive as a replacement for ProQuake server on his coop mod server

I explained the benefits like the automatic server browser.

Something that immediately occurred to me, though ...

1) Quakespasm can't actually serve a protocol 15 game (i.e. standard Quake). The sign-on packet wrongly busts the standard Quake limit, causing the client to immediately disconnect.

2) Gunter asked if it would have ProQuake rcon. I said I'd bring that up.

/I could probably easily obtain more server operator volunteers, but Gunter has run a server for a while and he's already getting familiar with Quakespasm. ;-) 
I didn't make it clear: He said he'd be willing

I explained the single port server advantage, the ipv6 support, and automatic server heartbeat advantages.

(Although Polarite is the one actually in control of the server. I haven't talked to Polarite yet.) 
RCON: What It Is ... 

* To anyone that doesn't know what RCON is, if someone has a server, the owner can connect to the server and do "rcon changelevel e1m3" from the client.

It is a way to give yourself the ability to issue console commands to the server like change the map. 
.Alpha {fence Textures Bug 
I had the idea to make low lying fog using a skip-textured 32 unit high brush whose top surface was textured with a circular fuzzy edged {fogtexture (using pink transparency index), setting this brush to be func_illusionary, and topping it off with a .alpha value of like 0.2 or 0.3 for subtlety.

This looks somewhat passable at 0.7 even, however there is a bug. I can't set .alpha lower than 0.67 or else it doesn't draw the face at all.

@FifthElephant, as much as I enjoy encouraging people to use fte, this probably isn't the right topic. poke me on irc or give a proper bug report in the afterquake topic or something.

@Baker, it'd be good to get it to use vanilla-compatible packet sizes, at least where practical. The signon buffer size can trivially be reduced to 8000 now thanks to baselines being splurged over multiple packets too, but iirc there's issues when recording demos mid-map due to clientside assumptions someone made, and I'm too lazy to re-splurge the data back out there too (so I just left it using large signons despite it being trivial to split it, to try to sidestep the issue), either way I suspect its not just quakespasm that would have an issue with that.
iirc, vanilla needs 1024-byte unreliables too, which is more of an issue without proper deltas, though I suppose if you're trying to use vanilla protocols then you get what you deserve. Obviously none of these limitations need apply to qs[s] clients connecting to the same server... Can we not just get everyone to upgrade?.. :P
The master thing is kinda irrelevant as not many clients will bother to check it at this time anyway, so he'll still need to manually get it added to whatever server listings proquake etc currently use.

@Qmaster, the engine sets up the alphatest value once and then forgets about it:
glAlphaFunc(GL_GREATER, 0.666);
that line needs to scale by the entity's alpha value in each place where its actually needed, which is probably quite a few places. 
>Can we not just get everyone to upgrade?.. :P

Protocol 15 is what DarkPlaces, Qrack, Super 8 and everything else can speak. And your single port server means that no client --- not even GLQuake will have NAT issues.

It was my thought to get the server real live tested, since few people (or even anywhere) here seem to coop even on a LAN.

And then after that works, push for a "Spikespasm coop server" that exclusively uses the new client.

/That was my line of thinking. 
(Anyway, I wasn't trying to get you to do anything of substance. I made Mark V support protocol 15 with just a couple of tweaks, I wasn't aware that getting "Spikespasm" to support protocol 15 would be difficult.) 
Wish There Was Edit But There Isn't 
( When I made Mark V support protocol 15 -- which FitzQuake 0.85 never quite did --- I just kept track of the protocol upon map start and set a global. I adjusted the signon buffer and then the packet size.
Particle Issue 
haze.cfg --- assigned the te_quad_sparkfan effect to progs/quaddama.mdl

Loaded dm3

When I pull up the console. The effect spams continually. Obvious the "die" time cannot happen when the console is up. But new particles shouldn't spawn.

Oddly this does not seem to happen with rain/snow. So far only te_quad_sparkfan seems to have this problem. 
Baker, protocol 15 might be the only commonality between all engines, but if you ignore vanilla, all the other engines have boosted what their engines are willing to receive to at least ethernet's limits.
requiring everyone to upgrade basically includes to every single notable engine with the exceptions of vanilla and proquake. One of which you(baker) can fix with a new revision.
The alternative is to cripple dp,qrack,fitzquake,markv,etc clients that give no way to identify what they support.
These clients would also need to be limited to 600 entities too, etc.
Its not that its a big change, its more that its really limiting. 
I think what've you done here is incredible as is.

Spike: you(baker) can fix with a new revision.

Heheheheh. Should the day ever come when I have time, hehe ;) Probably won't be within the next 12 months.

No one expected to get particles because you seemed down on it. The stuff on top of the particles was unexpected and a bonus.

The particle stuff by itself is quite the enhancement and I hope it gets put to good use by Sock and possibly others. 
if I'm not critical of something, I can't easily spot the flaws in it.
At the end of the day, if someone does something stupid with the particle system then that's their own damn fault, and not something that should hold back eg Sock.

Regarding protocol 15, if clients can tell the server that its not crippleware, then its only the crippleware engines that will suffer from being crippleware.
I made some tweaks, and r4 will (bug-willing) do protocol 15 properly. I even made it reduce the number of usable sounds/models if the serverinfo packet is too big, which seemed to get AD going with a proquake client, although it did feel a little empty with half the entities missing (like I said, limiting)...
I guess I also ought to do something about makestatic too now though. Stupid cans of worms... :(
Also got the server part of proquake-compatible-rcon working, although I wouldn't personally recommend using it because the password is still sent as plain text, which sucks.
Also found a nice reliable way to crash proquake servers. Hurrah.

yay polish?.. 

I don't understand your objection to the FitzQuake "game travail" or "game warp -quoth"

Is it because it doesn't use gamedir like Quakeworld and DarkPlaces and JoeQuake? I used to dislike the slightly different naming, but I've gone from disliking it to prefering it because I type it in the console a lot for single player.

Is your dislike just because the name? Or is there something else I'm not seeing?

/Slightly surprised you decided to do the protocol 15 thing, I did look through all the mega-tons of changes you did and I can see your POV. rcon on the other hand is barely a cut and paste, relatively speaking ... even easy stuff is slight PITA. 
until some rcon command crashes the server and fails to even tell the (rcon) user what happened. Blind copy+paste is never a good idea.
no feedback on errors = bad
plain text passwords = bad
client only supporting one rcon command at a time even when its just a single packet = bad
modifying the system-specific code for something common to all = bad
willingness to exceed proquake's own mtu resulting in 'bad read' errors instead of results = bad
not giving any feedback at all when the server is a listen server = bad
copy+paste = bad. :)

I dislike 'game' because it differs from the command name that id themselves used with quakeworld. that said, quake2 used 'game' so I can't really justify that much further (although q2 used a cvar, which has its own set of issues, which an engine that also supports q2 needs to be able to deal with).
What I really *really* hate about it is the '-quoth' part, which limits it to only a few base-mods that are hardcoded into the engine. This also affects the choice of hud, and even the network protocol. Each of those 3 things are unacceptable to me.
So yeah, I feel justified in disliking it, even if I ignore that qw+fte even existed.
The deltas stuff deals with the protocol change. The hud lumps can be auto-detected. The hardcoded list of 'permitted' mission-packs is just plain stupid. Oh, and quakespasm doesn't support more than those 2(+id1) either.
But yes, I should do something about the server announcing the correct gamedir to use, but probably I'll just leave that until someone else wants to actually fix up the 'game' mess and add auto-downloads and deal with the versioning fallout resulting from that. 
Mulitiple Gamedir Support Is 5 Alarm Nightmare Anyway 

Someone is using DarkPlaces as a listen server.
They decide to coop.
They use multi-game dir for replacement content.

(1) So does the client need to download all of that person's replacement content when connecting?
(2) Make sure content are the right models with CRC check etc? How do you do that when the loaded model is a replacement model?
(3) Download doesn't download the replacement textures that the replacement content needs to look right.

Multiple gamedir support is mostly a mechanism for using replacement content.

Within that context --- the support for a small set of mods (rogue, hipnotic, quoth, possibly -ad in the future) is not much of a problem.

And is probably a major benefit. I don't know how many single player users require the Quake Injector to play a custom map, but its probably no small number.

When I first wanted to try custom single player, I was not used to the installation instructions or using -game in the command line. Figuring out where things go and the startup procedure is a big challenge to most people.

Shorter version: I think a finite list of double gamedir like "game -quoth" is fine, Preach knows what's he's doing, Sock knows what he's doing ... other than Preach and Sock and some of the power mappers that really know their stuff (czg, necros, tronyn, etc.) --- there aren't a lot of people that are going to be making an expansion pack level add-on for immersive content.

When DarkPlaces added double-gamedir support, the thought wasn't of "hey, make sure feature is properly architected and well designed" but rather for modder convenience. 
IIRC the only reason for -quoth is to allow it to support the Hipnotic HUD, together with Quoth content, together with an (optional) additional gamedir for a mod which requires Quoth.

-quoth is just a hack, in other words. But it's a hack that the community has come to accept and expect.

This is clearly a "survival of the unfittest" situation. A simple-to-implement, adequately robust, but not necessarily full featured solution will always win over an elegant, extensible, more correct solution but that is significantly more difficult to implement. 
@spike Re:EF_STARDUST 
EF_STARDUST in the DarkPlaces source looks nearly identical to EF_FLAME, except that it uses pt_static instead of pt_flame.

Is EF_STARDUST needed for a model to emit, say, sparks?

Is or EF_STARDUST redundant because the same effect can already be achieved through other means? Hence its non-inclusion in "Spikespasm".

/I'm looking at smc and thinking about extracting an effect or of it for a tutorial later in the week or on the weekend. 
its either '-quoth' in an engine that hardcoded a specific mod, or '-hipnotic -game quoth' for vanilla, but yeah iiuc its just for the hud.
DP didn't add 'double-gamedirs', it has multiple gamedirs, because limits suck. As does FTE. of course, when you have more than one, order matters. I handled 'game foo -quoth' by parsing the list twice and then re-ordering. And if you want to mess everything up for everyone, all you have to do is to put a space in the subdirectory name! yay!

EF_STARDUST is what exactly?.. Its a specific effect that you wouldn't have a clue what it really looks like until you've actually used it so that you can see. I don't see the point of it because its a specific effect. Its just not significant compared to the more generic stuff like r_effect or traileffectnum.
Iiuc, it predates custom effects and stuff, dating back to the time of hardcoded effects. Same with all the extra TE_ effects.
Yeah, it might be simple enough to rename it to 'ef_customeffect1' or something lame, but that's just lame.
So yeah, you might want it for compatibility, but moving beyond that its probably not very useful, so I didn't see the point of implementing it. 
If I remember correctly, it's an effect used on slipgates that displays star-like sparkles floating upwards. I don't think it would do for, say, electric sparks coming from a broken panel. 
That's what I thought! (It's obsolete, artifact from more primitive days). Thanks!

@mugwump - the particle system lets you set the origin and the velocity and other things. the originoffset could be instead of above it could be to the side and instead of sparkles, sparks. It's just an emitter. 
Myst, Sparkle, Smoke, Decal, Trail, Model Light 
Simple effect videos

1) Sparkle:
2) Smoke:
3) Flame:
4) Myst:
5) Rocket Trail:
6) Decal:
7) Model Light:

To be followed up maybe this weekend by tutorials. 
Classic Weapon Offset? 
Hey there,
I recently dug around a bit trying to find out how to get some popular source ports including Quakespasm to look as close to the original DOS Quake as possible. Changing texturemode, particles, lerpmove, lerpmodels, etc. one can get Quakespasm to look nearly identical, but the weapon offset is still problematic, it's just too low. Using scr_ofsx gets you somewhat closer, but it's not ideal. I've seen that Tarvis/bangstk made some effort here earlier this year to change that with an unofficial fork, but I guess that wouldn't work for the most recent release. Or can that somehow still be included without official support?

Otherwise, is there any way to change the weapon offset to really get the original look, or isn't that possible right now? And if it isn't, can anybody give me some insight into why exactly that change is there in the first place?
Thanks :) 
There's a comment in the source explaining this removal:

//johnfitz -- removed all gun position fudging code (was used to keep gun from getting covered by sbar)

I believe that Baker's FitzQuake Mark V fork restores that code, but QuakeSpasm doesn't. 
Original gun is available as an option in mark v. Default is still the FitzQuake norm that Quakespasm uses but yeah you can go menu ... preferences ... set gun position to classic. 
I'd like a cvar for that.. we had a patch contributed that enables the classic gun position:

It's on my todo list to review and compare to how MarkV implements it. 
You might as well take "fov doesn't affect gun" option too when the time comes. 
Ironically, if I recall, Mark V doesn't have gun fudging code. Original Quake did fudge the gun position. Classic weapon in Mark V calculates the right gun position for the gun to appear on top of the status bar based on FOV and HUD settings and screen aspect ratio. This calculation also has to take into consideration FOVy adjustments for screen aspect ratios.

When you think about the gun fudging code in original Quake, it sounds newbiesauce easy.

But just see what happens when you change the resolution to something with a weird aspect ratio or set an irregularly sized window resolution of 600 x 600 or 400 x 600.

The original weapon position fudging code breaks down terribly in situations deviating far from a 4 x 3 aspect ratio or with enlarging the HUD (hudscale).

(If I recall correctly, it's been a while since I worked on that.) 
Speaking about FOV, I think this option should have a threshold of sorts. Right now it always draws the gun the same, even with a very narrow FOV, which makes zooming very weird. Maybe it should take a value (in degrees) beyond which the gun stops changing. 
Hehe, I noticed that once but thought that I was only the person that actually created such a bind.

You could actually modify your zoom bind.
+zoom "fov 70; r_viewmodel_fov 70; wait; fov 50; r_viewmodel_fov 50"
-zoom "fov 50; r_viewmodel_fov 50; wait; fov_70; r_viewmodel_fov 70; wait; fov 90; r_viewmodel_fov 90" 
Good to know, thanks. 
Question For Dummies 
will Spike's code be integrated into the next Quakespasm release or it is intended to be a stand-alone piece of software? 
Thanks for the explanation about the weapon offset. I hope the patch or another kind of fix finds its way into a release eventually :)

Regarding Mark V, I noticed that it's better there, although unfortunately the beta release of the mark_v.exe crashes on my computer, unlike the latest stable release. However, I've used the WinQuake port of Mark V for playing through Quake the first time only recently and it worked flawlessly :) Now onto Arcane Dimension with Quakespasm. For the time being I'll stick to scr_ofsx -2.8. 
For The Few Mac Users Out There 
Mousewheel weapon switching is broken on macOS 10.12 due to a SDL2 bug:

The SDL1.2 version seems to be unaffected.

Icaro: I'm not sure.. For the time being, it's a fork / branch. 
Hey Guys 
If I were to modify gl_model.c to allow for more animated textures (beyond 10 per surface) would I also need to modify the compilers to save the extra textures (beyond +9) to the bsp file? 
You can add the textures the manual way by including a brush in the void with the desired textures. That's how we used to do it in the old days before compiler did it for you. 
Is this a change that the guys would be willing to see incorporated into the engine? I don't want to fragment the engine ecosystem for such a small change.

Especially with spikes modifications being released too. 
OGG Music Has Stopped Working In Quakespasm 
My music has spontaneously stopped working in quakespasm. I have the tracks as ../ID1/music/trackXX.ogg, which used to work fine. But now I get no music and a message in the console saying

Findfile: can't find music/trackXX.mp3
Findfile: can't find music/trackXX.flac
Findfile: can't find music/trackXX.wav

Any ideas what might have caused this? 
animated textures ... beyond 10 per surface

It is 20 per surface already according to this ...

Which was written by metlslime, hehe. 
Pretty sure that 20 is regular + alternate anims. 
0-9 for regular animations. a-j for alternative animations. the limit is due to the base animations using digits, although the alternative anims could be bumped to 26 chars.
more than 10 (or 26 for alt) requires getting people to agree with a single consistent naming system within the 16-char name limit, and that all gets far too political... 
What I was thinking was expanding the frames by a factor of 10 for the numbers and leaving the alternate animations alone. +00 to +99 is what I was thinking.

If nobody cares for it that's cool too, I won't make this change unless the QS authors are cool with it. Like I said engine ecosystem and all. 
Slimealpha Worldspawn Key Does Not Work In Quakespasm 
slimealpha worldspawn key does not work in Quakespasm

The value seems to never be honored. Unless I'm doing something

Put in worldspawn:

"slimealpha" "1" // Nope, uses r_wateralpha

All the other ones work like "telealpha" and "lavaalpha". 
It's working for me.. tried "slimealpha" "1", as well as "slimealpha" "0.1" in worldspawm.

Does the r_slimealpha cvar work for you? The interaction between the cvar and the worldspawn key is a bit confusing.. when the map loads, if the worldspawn key is set, that gets used until the next time you change the cvar. So the cvars behave like the fog command.

Also if the cvar or worldpsawn key is 0 (the default), that is interpreted as "use r_wateralpha" 
Here is an example of misbehaving, although apparently in different way.

1. Empty Quake folder, just pak0.pak + pak1.pak
2. This start.ent in quake/id1/maps

Mainly featuring ...

"lavaalpha" "0.5"
"telealpha" "0.5"
"slimealpha" "1"
"wateralpha" "0.7"

3. Result: No water transparency but the other 3 settings are used. 
I *think* that might just be un-water-vised transparent water? QS defaults to gl_clear 1 so you get grey tinted instead of a HOM. 
No -- It's Slime Alpha 
I type r_novis 1 in console. Now water is transparent like it should be.

And although I specified slimealpha 1 in the worldspawn, it is not being used.

Slime is transparent but I said 1! (which is not transparent)

Slime is under medium bridge. I typed "fov 10" to magnify.

Test was that start.ent, no config (I deleted every time to make sure it couldn't be config) and just the pak0/pak1. 
Are You Sure There's Slime In Start.bsp? 
under the "normal" bridge? It's not burning if I noclip into it.. 
Major fail on my part.

I suck. Haha. Sorry. 
This one isn't imaginary. :)

I wanted to check out Spike's skyrain in Quakespasm Spiked on E1M1. To make sure it was using the external ent file I changed the name in worldspawn. Never worked.

Tried other engines with external ent support = worked.

The Z fighting fix in quakespasm.pak apparently takes priority over an entity file for those maps like id1\maps\e1m1.ent

Just wanted to point this out. 
@Shamblernaut sorry for not responding earlier. I hate always to be grumpy; but I'm not keen on extending the number of animation frames just for engine fragmentation reasons.

Baker - thanks! Not sure what to do at the moment but that is an unfortunate behaviour. 
Load the quakespasm pak as third ticket in the priority for the id1 folder. 
Priority (for id1 folder):
1) Pak files (pak0.pak, pak1.pak, ..)
2) Free standing files
3) quakespasm.pak

/Mark V just patches the entity string if it passes a "is it right map?" check, but I understand why you guys chose a pak file. 
the path command shows all. first displayed has highest priority. 
Priority (for id1 folder):
1) Pak files (pak0.pak, pak1.pak, ..)
2) Free standing files
3) quakespasm.pak

For standalone ent files on the OS filesystem to take priority,
that order you mentioned needs changing to 3, 1, 2 (using your
numbers.) That may (or may not) have unwanted side effects, and/or
break things, which I don't know at the moment. 
changing to 3, 1, 2 (using your numbers.)

Well, that should be 3,2,1 to be correct. But I _think_ that would mess things. 
continuing from the jam thread..

what's the history behind qs
The QS changelog is the best summary of what was changed versus Fitzquake. Likewise, the Fitzquake changelog summarizes what metl changed versus GLQuake

Also worth mentioning, QS started as a continuation of SleepwalkR's port of fitzquake to SDL (for mac/linux support):
It also shares some code and maintainers with uhexen2 
Thanks for the links, good stuff. Not quite what I meant with my question, though; I'm more in learning about the circumstances behind QS's adoption by the community as a "Standard" engine. Was it just momentum carried forwards from the popularity of fitzquake, or something like that? Mostly just asking because I wasn't around in the community at the time, so it's all a bit of a mystery to me as to how we got to where we are today. 
is there plans to add some of the graphical features shown elsewhere on the forum, about flames rendering and other special effects ?

And what about the OS X version ? 
Pritchard, I'm kind of curious to hear how other folks answer your question, but from my POV... yeah, Fitzquake had established itself as the "better version of GLQuake" that was the standard for making/testing/playing custom Quake maps. Fitzquake stopped development after a while and then Quakespasm sort of carried that torch forward. 
Special FX: Try the Spiked version. It's not the goal of regular QS. 
What is the Spiked version ? Is it available on OS X ? 
Fitzquake Already Was The De Facto Standard 
QuakeSpasm took over because it was more actively developed and cross platform, I would say. 
A fork of QS made by Spike that supports fancy stuff like particles and weather effects. There's a tutorial thread here:
Additionally, here: is an example of effects for E1M1. You'll find the download link for the latest revision either on top of this page or in post #25 of the previous link.

I have no idea if there is a Mac version, though. I'm sure some people here would know. 
QS-Spiked is a version of quakespasm that'll get you drunk faster than you expected...
it still looks+feels the same, unless someone actually uses one of the new features (which is imho why quakespasm is the more accepted / neutral engine).
and annoyingly people focus on only the particles rather than the other things intended to stop it from being crippleware. grr.

there's no prebuilt mac build, no linux build, no win64-specific build. the only prebuilt build is for win32, on account of it being intended as an updated patch rather than an engine in its own right, and me being too lazy to make 4 different builds with all their dependancies and crap.
its still based on sdl, so you should be able to compile your own version if you're determined (but you might need to grab any missing files from vanilla quakespasm).

Heh, well at least there are people interested in your work... 
How To Trigger Spike 
Aren't you also the man behind FTE? Considering that, I find your comment very surprising. At any rate, the people who come to QSS for the pretty-shiny can discover its other features afterwards. 
I'll make a mac build of qs-spiked soon 
Spike is all about the QuakeC. What would really need to happen is some single player modder using the QuakeC extensions available in the modified engine.

Like use the magic ear extension in QuakeC to create a shrine area with different statues and you have to say a magic word like "Klaatu Barada Nicto" to open the entrance to the tomb.

Like those games where the vault combination "4398" or the computer password is scrawled on a wall, possibly an alert player could use it to get a secret item.

Or have computer be able to do different commands like "airlock" to open a door on a base map. 
See? I've just discovered something! I admit that my interest in QSS resides primarily into said pretty-shiny, because I'm a DP fan and "normal" QS looks a bit too vanilla and I want to play maps/mods that have issues with DP but still get the bling, but what I've just read is AWESOME SAUCE! 
The actual extension is KRIMZON_SV_PARSECLIENTCOMMAND and QSS totally has it.

Which let's QuakeC intepret chat knowing what player entity said it and where they are. 
Krimzon? An easter egg referencing King Crimson, perhaps? 
Krimzon was a community member from ancient times. 2001/2002 or so; don't ask me to be any more specific.

Considering that, I find your comment very surprising.

If you use Linux you should be able to compile yourself. If you're not able to compile yourself maybe you shouldn't use Linux. 
Barnak has a Mac which can only run 10.6 (32 bit or something). Spike doesn't have a Mac, gotta have a Mac to compile Mac version because Apple wants it that way and sells hardware. SleepWalkerR has a method to compile for old Mac OS versions, it's obscure as hell and requires frameworks no longer available from Apple. Ericw has those frameworks/files.

Ericw = only guy on planet who can make binaries for Barnak's Mac. 
Krimzon was a community member from ancient times.
Oh, OK. Just asking because Crimson is one of my fav bands.

If you're not able to compile yourself maybe you shouldn't use Linux.
I don't. I tried a S.u.S.E. distro a long time ago but Linux is not user-friendly enough for me. I wasn't talking about the build part but about your jaded/angry tone. 
Barnak's Mac
Heh, that sounds funny. Try repeating it as fast as you can. 
I personally tend to play quake with vanillay setting. Pretty stuff like rtlights is not what I personally favour, which is why I've not gone completely crazy with that stuff. For instance, FTE has a number of presets, and only ONE of them has fullblown rtlights enabled.
Pretty stuff sells (yay screenshots), hence your interest in DP, which is why FTE has the effects that it does, but its not my personal focus. I'm more about letting people do what they want without extra barriers (bug-willing), hence csqc etc.
Note that QSS has a whole load of ssqc extensions, such that mods like SMC can run. I'm not saying that its worth playing SMC with QSS, only that its content-loading limitations that really holds it back (well, okay, a couple of extra things that I didn't bother to network up because I couldn't be bothered to implement the various clientside parts).
The point is that QSS should no longer feel like crippleware to an aspiring ssqc modder.
And hopefully FTE+DP users won't be left with horrible clunky mods that comprise of 60% hacks that were needed to work around QS limitations.
The particle system is useful to mods+maps, in much the same way as fence textures or strcat (though you're likely to need to use the more limited DP-defined effect definitions if you want compat across all 3 engines). My personal justification for including the particle system was because Sock used custom particles in AD, demonstrating a need, but that his particles made the game totally unplayable in coop - using the engine's particle system, this problem goes away.
Anyway, that's my reasoning.

@ericw, I *really* need to get off my arse and do that bugfixes-and-polish-only r5 build, then start harassing you or the other guys to get it merged into vanilla QS... but meh, lazy.

@baker, numberic combinations like 4398 could easily be done with impulses, but yes that would generally imply breaking weapon switching in certain areas.
I'd like if someone made a proper map-scripting language some time, but I'm too lazy myself. 
-Triggers targets when a given magic word has been said
--------- KEYS --------
-message: message to wait for (can start or end with * for wildcards)
-netname: replacement text (by default, no replacement is performed if empty)
-radius: radius in which the player has to be for this to match
-target: all entities with a matching targetname will