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

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

http://quakespasm.sourceforge.net/
First | Previous | Next | Last
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:
http://sf.net/p/quakespasm/news/2014/10/quakespasm-0900/

Downloads:
http://quakespasm.sourceforge.net/download.htm
http://sourceforge.net/projects/quakespasm/files/ 
Two Versions For OS X ? 
What's the diffirence between the "universal" and the SDL2 version for OS X ?

What is SDL2 anyway ? 
Continued 
hey ericw

specs
8gb ram
dx11

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?

>Requests
can ambient sounds be made to always loop even if do not contain a repeat node?

...is 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. 
Barnak 
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.. http://www.libsdl.org

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. 
@mh 
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 http://forums.inside3d.com/viewtopic.php?f=3&t=2983 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..
https://github.com/ericwa/Quakespasm/compare/master...glsl-alias 
@ericw 
Since you're working on MDLs, and if you're interested, here's a better way of evaluating mins and maxs: http://pastebin.com/aCTyXjjm (this just reverses the calculation from modelgen.c)

And here you can recalculate normals (again, based on code from modelgen.c): http://pastebin.com/AMdpeB7Z

The anorms table is just an icosahedron subdivided twice so that can also be calculated in code if you like. 
Thanks 
will check those out! 
@ericw 
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
Host_Init
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
GL_MAX_TEXTURE_UNITS: 8
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
http://tyr.nimad.fi/~fullmoon
3 demo(s) in loop
]gl_info
GL_VENDOR: Intel
GL_RENDERER: Intel(R) HD Graphics 4000
GL_VERSION: 4.0.0 - Build 9.17.10.2963
GL_EXTENSIONS:
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_blend_color
GL_EXT_abgr
GL_EXT_texture3D
GL_EXT_clip_volume_hint
GL_EXT_compiled_vertex_array
GL_SGIS_texture_edge_clamp
GL_SGIS_generate_mipmap
GL_EXT_draw_range_elements
GL_SGIS_texture_lod
GL_EXT_rescale_normal
GL_EXT_packed_pixels
GL_EXT_texture_edge_clamp
GL_EXT_separate_specular_color
GL_ARB_multitexture
GL_EXT_texture_env_combine
GL_EXT_bgra
GL_EXT_blend_func_separate
GL_EXT_secondary_color
GL_EXT_fog_coord
GL_EXT_texture_env_add
GL_ARB_texture_cube_map
GL_ARB_transpose_matrix
GL_ARB_texture_env_add
GL_IBM_texture_mirrored_repeat
GL_EXT_multi_draw_arrays
GL_SUN_multi_draw_arrays
GL_NV_blend_square
GL_ARB_texture_compression
GL_3DFX_texture_compression_FXT1
GL_EXT_texture_filter_anisotropic
GL_ARB_texture_border_clamp
GL_ARB_point_parameters
GL_ARB_texture_env_combine
GL_ARB_texture_env_dot3
GL_ARB_texture_env_crossbar
GL_EXT_Shutting down SDL sound 
@ericw 
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

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

>Requests
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 http://www.wavosaur.com/ 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. 
@necros 
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? 
@eric 
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 http://quakeone.com/proquake/Quakespasm_Steam_Easy_Install.exe
 
Updated 
 
Well that's service! 
Bugs 
>Bugs
*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.

FITZQUAKE 0.85 SERVER (51103 CRC)

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.] 
@ranger 
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. 
Continued 
>Bugs
*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

@mh
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?

@baker
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. 
However... 
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. 
Mh: 
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.

http://imgur.com/Cy8wvUT

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? 
Moreover 
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 quakeone.com 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. 
Doesnt 
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. 
#1360 
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:
http://ezquake.sourceforge.net/docs/?commands#skygroup
maybe. 
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.) 
Whut? 
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. 
IMO 
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. 
Ah 
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! 
Fullbrights 
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. 
Mh: 
i think my suggestion would handle that by rejecting the start.ent (start.bsp would be later in the search path in that case.)

Hmm...

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):

http://quakespasm.ericwa.com/job/quakespasm-alias6/lastSuccessfulBuild/artifact/quakespasm/quakespasm-rbe2d155ae59744afad9faf79e5d9b82e1f54430e.zip

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! 
Continued.. 
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 :) 
Add SDL_WINDOW_BORDERLESS 
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 enough...no 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? 
 
@negke
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...

http://www.quakeforge.net/screenshots.php 
 
I don't see the difference between that and changing the texture mode using gl_texturemode 
Fifth 
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 
@Fifth 
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 https://gaming.stackexchange.com/questions/164991/quake-1-under-linux-using-quakespasm-0-85-9-couldnt-find-a-cdrip-for-track-an

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: http://imgur.com/a/DhAgo 
OTP 
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. 
#1440 
also....models have minlight in software? 
@Kinn 
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:

https://github.com/id-Software/Quake/blob/master/WinQuake/r_main.c#L563
https://github.com/id-Software/Quake/blob/master/WinQuake/r_alias.c#L617
https://github.com/id-Software/Quake/blob/master/WinQuake/r_alias.c#L433

And glquake:
https://github.com/id-Software/Quake/blob/master/WinQuake/gl_rmain.c#L476 
QF 
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. 
Ok 
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:
http://quakespasm.ericwa.com/job/quakespasm-sdl2/146/artifact/quakespasm-r1164.zip

@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. 
Ok 
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? 
Cool 
I will have to try that in gzdoom. yquake2 also has an openal backend: https://github.com/yquake2/yquake2

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. 
Oops 
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. 
Sure 
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:
http://forums.inside3d.com/viewtopic.php?f=3&t=4875&p=44571&hilit=runes#p44558

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. 
@Baker 
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.
Die.

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.

Cause

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.

Fix

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. 
...actually... 
Now that I've read ericw's post, yup, that's a problem... 
Haha 
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? 
@Baker 
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 
Ranger 
When the moving down & up certain ramps/convex geometry, the player gets stuck/stops and can't move forward 
Host_maxfps 
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:
WinQuake
Quakeworld (any GLQuakeWorld, FTEQW, ezQuake, ...)
DarkPlaces
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)];
}
else
{
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. 
 
edit:

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.

http://i.imgur.com/WIAAvmL.png

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. 
Primal 
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:
https://www.dropbox.com/s/z4n1kibgu13qr2i/primal1.jpg?dl=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? http://www.celephais.net/fitzquake/

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.

http://i.imgur.com/7EhYPvi.gifv

(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. 
Yeah 
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 
Thanks for looking at this, EricW. 
Anyone Here Aware Of Quakespasm Rift? 
Yes... 
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:
http://quaketastic.com/files/misc/rendering-testmap2.zip
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:
http://forums.inside3d.com/viewtopic.php?f=12&t=2376

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:

Cons:
- 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.

Pros:
- 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... 
...is 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. 
True 
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 rotate.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...
...is 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:
http://www.quaketastic.com/upload/files/misc/rmqrotate_patch3.zip

It works well in the engine baker attached in #1508, or here is a test build of QS with rotation:
http://quakespasm.ericwa.com/job/quakespasm-ericwa-sdl2/62/artifact/quakespasm/quakespasm-r4daaebe3ea8cf5a23dc5c3530a9abc3f59cbe564.zip

(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 rotate.zip 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:

http://imgur.com/VdnkXE3

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. 
Argh 
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:

http://i.imgur.com/BGel82p.png 
 
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? 
Hack: 
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. 
 
 
clever! 
 
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. 
Nope 
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:
https://dl.dropboxusercontent.com/u/15588722/add_weirdness.zip 
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. https://www.google.com/search?q="Can%27t+suicide+--+allready+dead!" 
 
more important than moving lava imo 
Seems To Have Been A Recurring Problem.. 
Allrighty... 
 
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:
https://www.youtube.com/watch?v=bhwzAxTg99U
https://www.youtube.com/watch?v=_NrHNilIqLo 
 
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. 
Wut? 
But it's even nearest neighbor! 
 
Lol, no it's not. :P 
Demos 
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? 
Derp! 
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 mapjam6.zip, the readme tells us to use jam6/ but is called func_mapjam6_readme.txt.

I hate this job. 
Spirit 
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).

http://i.imgur.com/jZcvxKx.png

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 (quakespasm.ericwa.com):

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. 
Ptoing 
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:

http://i.imgur.com/KKCKjM5.png

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

http://i.imgur.com/4SV5anL.png

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.

http://i.imgur.com/0V6Nxkl.png

Just in case it might be useful for someone in the future. 
IIRC 
-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. 
Intedesting... 
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. 
Haha 
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. 
Hahah 
 
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. 
Thx 
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. 
Path0gen 
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

Requests
--
*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 
 
issues:
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.

requests:
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 
Yeah 
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. 
Metl 
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 
 
"swords" 
 
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. 
Meh 
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. 
Skiffy 
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? 
Willem 
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. 
Skyboxes 
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. 
...or... 
"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.

https://dl.dropboxusercontent.com/u/1849053/Shambler_Wip_02.jpg

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 - http://triptohell.info/moodles/junk/theblimpgun.png 
 
Stock Q1 monsters look like baloon animals.

I'm more worried about the guns - http://triptohell.info/moodles/junk/theblimpgun.png 
#1633 
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. 
Chunkiness 
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. 
Yup 
But now we try to enjoy it with a little more detail... just a little bit. 
Skiffy 
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. 
Adib 
.mdl is about as hard as downloading preach's md3->mdl converter I think.

I may be missing something, so others please jump in. 
Nah 
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

https://tomeofpreach.wordpress.com/2012/11/19/progressive-enhancement/

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. 
Preach 
That is very sensible and sound. I agree. 
@adib 
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...

progs/cultist.mdl
progs/cultist.mdl.md3

...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! 
Hmm 
I really should go back and revisit this chap someday...

https://tomeofpreach.files.wordpress.com/2015/10/cultist.jpg

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. :) 
Nice! 
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 
Curious 
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. 
Kinn 
is right... the software mode would be neat. Also make sure you get the terrible z-plane texture wobbliness. 
Also 
Making the large models (like shambler) just disappear if they get too close to the edges of the screen would be sweeeeet. 
Facepalm... 
Some glitches can be left to the past. 
Outerworld 
You could hack the gamma shader, which postprocesses the entire screen just before displaying it. See:
https://github.com/ericwa/Quakespasm/blob/master/quakespasm/Quake/gl_rmain.c#L146
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. 
Yeah 
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. 
Framerate 
cl_maxfps Doesnt works in Qspasm right ? Any tip to get my quake1 running at more than 70 fps ? 
@nunu 
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.) 
Icon 
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. 
Yeah 
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 
Blava?? 
 
Blue Lava 
rocks ! 
 
Makes sense since light hitting the surface would be reflected upwards and diffused by the ripples. 
Kinn 
Screenshot plz 
Drew 
Meh, it's just a bunch of unfinished brushwork and crap placeholder texturing. 
 
fine. 
 
fine. 
Kinn 
"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:
http://mankrip.tumblr.com/post/120399970810 
OH HECK YES 
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. 
Stencil 
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. 
Eric 
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.
http://www.quaketastic.com/files/misc/fencetest.zip 
Yeap 
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) 
Ahh 
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. 
Mankrip 
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. 
Retroquad 
Besides those screenshots however I can't seem to find more info about it. 
OGkspAz 
(Sorry in advance for hijacking Quakespasm's thread.)

The only place with a good description of Retroquad is my Patreon page:
patreon.com/mankrip

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? :) 
Hmm 
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: http://quakespasm.sourceforge.net/download.htm 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: http://quakespasm.sourceforge.net/music.htm

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. 
Con_centernotify? 
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.) 
Suggestions 
- 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. 
Fifth 
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. 
Ericw 
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 - 
http://www.quaketastic.com/files/screen_shots/enginedrawdifference.jpg

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). 
#1735 
I think it's cool, just a bit of flavor. I have difficulty imagining this being an impediment of any significance to anyone. 
Kinn 
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. 
Also 
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:
http://imgur.com/lx6DV1F
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. 
 
Quickloading...
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. 
Orl 
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. 
Kinn 
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.

bug? 
The Console Says.. 
'Enter 'exec quake.rc' to load new configs 
D'oh 
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. 
However 
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: http://andersmalmgren.github.io/FreePIE/ 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: http://andreasaronsson.com/projects/xboxwasd-in-freepie/ 
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. 
Ericw... 
get that 4 player split-screen support coded in while you're at it ;) 
 
FTE can do split screen.

http://i.imgur.com/ChTAaTM.jpg 
 
why are the players christmas lights 
Baker 
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 
@baker
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.

@kinn
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. 
Spike 
Does FTE splitscreen work with networked multiplayer? IIRC a few years ago it didn't. 
@mankrip 
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. 
Good! 
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 :( 
Wha? 
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? 
Noclip 
I think that's a trigger_monsterjump and the following tutorial I wrote over 3 years back on Inside3D is all you need: http://forums.insideqc.com/viewtopic.php?f=12&t=4946 
Noclip 
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. 
Hmmm 
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. 
Nope 
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. 
Ok 
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. 
Aha! 
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. 
Aha 
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). 
Aho 
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. :) 
@JneeraZ 
That's not actually necessary: the engine should be able to detect when a single player game is being played (if (sv.active && !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. 
@JneeraZ 
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?

http://imgur.com/Ta2CH65 
 
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? 
Lmao 
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! 
@Baker 
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.

http://www.infoworld.com/article/2929732/open-source-software/sourceforge-commits-reputational-suicide.html 
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"

Heh. 
@Tamarisk 
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. 
Huh 
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 
Thanks for the new Quakespasm update. You guys are awesome. 
 
Agreed! 
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.

https://media.giphy.com/media/Jjbb0HlG6KgGA/giphy.gif 
 
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? http://www.quake-1.com/docs/quakesrc.org/144.html 
 
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? 
Quakeisdead 
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: http://sourceforge.net/projects/quakespasm/files/Windows/

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. 
Example. 
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? 
@parubaru 
"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? 
Mh 
Are you thinking like cfgs and stuffcmd/localcmd? 
@necros 
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. 
But 
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. 
Question 
Is fence texture support on .mdl planned? 
Water 
Is there a way to change water color? Underwater everything is beige and in dark corridors I can't see anything. 
Aspokala 
try setting "gl_cshiftpercent 50" in the console (default is 100) 
@ericw 
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. 
Yay 
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 ./QuakeSpasm-0.91.0-beta.app --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... 
Request 
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 :) 
Kinn 
Use "testplayerstart"? 
Mfx 
wassat?

not a command it seems 
Kinn 
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? 
Necros 
well I was hoping there would be a solution that doesn't require the use of a custom mod 
Hmmm 
ok I can abuse the save/load system to reload the world whilst preserving the entity state of everything...

that may do for now :} 
Kinn 
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?) 
Mfx 
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:

See: http://i.imgur.com/UfR6zS9.png

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:

http://i.imgur.com/ogwJcHr.png

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 :( 
Yeah 
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. 
Kinn 
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. 
Opus... 
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. 
Ericw 
Windows defender removes it so I don't have it to hand but the file that this link downloads has the "trojan" apparently:

https://sourceforge.net/projects/quakespasm/files/Windows/quakespasm-0.91.0_win64.zip/download 
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. 
 
wtf? 
@kinn 
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: http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/

Summary:

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. 
O RLY? 
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 https://sourceforge.net/projects/quakespasm/files/Windows/quakespasm-0.91.0_win64.zip/download 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:
https://github.com/ericwa/Quakespasm/archive/0.91.0.zip
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 quakespasm-0.91.0_win64.zip from SF (it is for me.)

My windows defender info is: http://imgur.com/7OBTNJb
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. 
Ericw 
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: http://i.imgur.com/d9mz5h1.png

So yeah it looks like a false positive and Defender's new virus definitions have sorted that shizzle out hopefully. 
Sourceforge 
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. 
Xinput 
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: http://imgur.com/a/7pF6k
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. 
Ericw 
360 input - awesome

Will we have tons of commands where we can fine-tweak deadzones, accelerations, and all that? 
Ericw 
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. 
@barnak 
It was probably RRP's quake.rc with settings put in there. I would expect r_oldwater was in there. 
 
Hello,

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.

https://github.com/bangstk/Quakespasm

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. 
Tarvis 
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)

http://i.imgur.com/4lEopwG.jpg

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

http://i.imgur.com/5HBFA8B.jpg 
Cheers 
Controller support :)
Amazing the amount of stuff Eric is doing.

@Tarvis

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.) 
@tarvis 
"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) 
Tarvis 
Sounds like some nice changes, thanks for contributing!

I'm not sure about http://i.imgur.com/4lEopwG.jpg , 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: http://i.imgur.com/OZ8fWvh.png 
 
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 
Yeah 
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.

Reference

Omicron Bot Mod Download 
Controller Support 
Finally committed this! Windows builds available here ( r1293): http://quakespasm.ericwa.com/job/quakespasm-sdl2/

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

Cvars:
* 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.

Buttons:
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? 
Eric 
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. ;) 
Funsies 
Here's a demo of me playing through Episode 1 with a pad -

http://www.quaketastic.com/files/demos/5thpaddemo.zip

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. 
Fifth 
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. 
Splitscreen... 
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 -

http://spearmint.pw/ 
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. 
Awesome 
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: http://quakespasm.ericwa.com/job/quakespasm-sdl2/lastSuccessfulBuild/artifact/quakespasm-r1294.zip

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 
nload 
Czg - Is That A Thing? 
Ok...any idea why it would only pick on quakespasm downloads? 
@FifthElephant 
Do you mean controllers working w/ splitscreen particularly, or FTE in general?

FTE seems to have controller support: http://www.celephais.net/board/view_thread.php?id=60452&start=1781

...but I haven't tried it myself. 
Johnny 
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. 
 
@fifth
in_xinput 1; in_restart
supposedly. 
 
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: http://www.celephais.net/board/view_thread.php?id=61285 
 
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
ERROR-OUT BEGIN


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. 
Zone 
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. 
Total_newbie 
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? 
Mh 
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 http://quakespasm.sourceforge.net/download.htm 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. 
@Kinn 
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 
Edges 
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? 
Kinn 
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. 
@ericw 
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. 
Haha 
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). 
Hmm 
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." 
@mk 
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. 
Baker 
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 
Exceptions 
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? 
Wait 
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* 
Habitual 
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. 
Sock! 
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... 
LOL 
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. 
:P 
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.. 
Prediction? 
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.

Thanks! 
Fteqw 
 
Nice! 
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.) 
Thanks 
Thank you very much. :) 
 
Latest windows dev build has the fix for ^ getting inserted in the console on German keyboard layouts:
http://quakespasm.ericwa.com/job/quakespasm-sdl2/ 
@ericW 
could you please fix also the OSX version? 
Icaro 
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! 
EricW 
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:
https://www.quaddicted.com/files/idgames/idstuff/quake/q101-106.zip 
 
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. 
 
Yep 
try updating pak0.pak. Is there a zip on quaddicted? I guess this should be covered on:
https://www.quaddicted.com/quake/installation 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: http://community.pcgamingwiki.com/files/file/411-quake-shareware-pak/

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: https://www.raspberrypi.org/blog/another-new-raspbian-release/

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.

Riiiiight.

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. 
F- 
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 http://quakespasm.ericwa.com/job/quakespasm-sdl2/ ?)

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! 
@ericw 
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. 
@ericw 
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 ;) 
@baker 
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) 
Splitscreen 
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.

http://celephais.net/fitzquake --- comparing the FitzQuake 0.85 vs. FitzQuake 0.80 source codes.

http://forums.insideqc.com/viewtopic.php?f=12&t=2450 (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 ...

http://triptohell.info/moodles/junk/markv_bsp2.zip <--- 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. 
@qb 
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.. 
Baker 
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. 
Kinns_new_sp... 
Noted! 
 
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. 
Whitelist? 
"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. 
Baker 
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.

http://i.imgur.com/m38oeEe.png

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.

http://i.imgur.com/R7zye7B.png

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. 
Dwere 
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 
Hmmm 
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.

https://dl.dropboxusercontent.com/u/15588722/post/func_msg/hipnotic_nobulletholes.zip 
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. :) 
@szo 
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? 
@Shamblernaut 
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. 
Ericw 
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. 
 
Czg 
ur just jelli u don't have the gamepad skillz. 
 
>gamepad
>skills 
 
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 
 
Errm 
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: http://i.imgur.com/oneWY9J.gif 
Yeah 
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: http://stackoverflow.com/questions/17458803/amd-equivalent-to-nvoptimusenablement

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. 
Ijed 
it exists, start typing something then press tab 
Ahah 
Thanks! 
Hm 
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 
 
Ijed 
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.

http://i.imgur.com/HDjlEze.png 
 
Agreed 
 
 
Just saw this...

Axel Gneiting, a programmer at id Software, has ported Quakespasm to Vulkan: https://twitter.com/axelgneiting/status/755988244408381443

Code: https://github.com/Novum/vkQuake 
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? 
Aardappel 
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. 
Ericw 
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? 
Vulkan 
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 :) 
@Aardappel2 
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 
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:
self.colormap=1024|self.clientcolors;
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? 
Vulkan 
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. 
@Axel 
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: http://triptohell.info/moodles/junk/youredoingitwrong.png (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? 
Izhido 
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". 
@mh 
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. 
@mh 
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. 
@mh 
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) 
Baker 
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. 
@madfox 
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. 
LXSU4 
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:
https://qexpo2016.com/sins-gorge-for-quake1/ 
 
The zip file is LSXU4, not LXSU4, so try -game lsxu4 +map lxsu4. 
Aftershock 
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? 
Mugwump 
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. 
Kinn 
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? 
Mugwump 
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:

http://i.imgur.com/q3GvKMr.png 
 
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. 
Kinn 
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! 
Dwere 
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

vs

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:

http://i.imgur.com/X0UA87y.png

This is a texture of the "bodies" series. Guess what's missing:

http://i.imgur.com/PSVK70R.png (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. 
Textures 
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:

http://i.imgur.com/YN5DBmG.png 
@dwere 
Do you know how DarkPlaces does colored dynamic lights?

(Hint: it's not pretty) 
Damn 
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) 
Kinn 
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. 
Baker 
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
Lightning
Rockets...)

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. 
@dwere 
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. 
No 
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. 
Shamblernaut 
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 
 
Dwere 
Baker is weird. But he knows what he's talking about when it comes to Quake engines. 
Baker 
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. 
No 
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"

or

"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. 
Mugwump. 
No, no, your opinion is wrong. Or in your ass, at least. 
Jeez... 
"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... 
Shambler 
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. 
 
Kinn 
I laughed, thanks. 
Onetruepurple 
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 enough...it 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... 
Kinn 
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. 
Hmm... 
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. 
Troll? 
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. 
Dwere 
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.

http://quakespasm.sourceforge.net/download.htm
http://sourceforge.net/projects/quakespasm/files/ 
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. 
#2277 
Amen. 
Oh And To #2276 
Thanks OZ! 
Preach 
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. 
@qmaster 
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:

http://www.quaketerminus.com/hosted/oqnm_4_20/oqnm_4_20.htm

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. 
Baker/Qmaster 
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) 
Preach 
"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. 
 
Mugwump 
"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... 
Dwere 
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

Wow. 
WTF 
It's like he's not even trying anymore. 
Who's Not Trying What? 
 
One True Pairing 
Mugwump and OTP are my OTP. 
Correction 
"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. 
Also? 
 
 
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.

Also:
http://www.wadjeteyegames.com/wp-content/uploads/UV-shelter.png

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? 
Retroactive 
I wasn't aware of that. I've never heard the term used for these old games. If that's true, I stand corrected. 
Brushes 
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... 
.
.
oh...

*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. 
Qmaster 
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. 
Dwere 
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 
 
Baker 
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. 
 
Lol 
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. 
FYI 
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. 
Yes 
AD lets you change fog colors. 
Trigger_Fog 
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. 
Qmaster 
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? 
Sock 
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. 
CSQC In QS 
Would rock 
Spike 
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: 
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 ;-) 
Brush/Sky 
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. 
Pritchard 
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 https://www.youtube.com/watch?v=q-rO8haGoh4 (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.

https://www.youtube.com/watch?v=6141F64dB0k

... 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. 
Well. 
"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. 
Innit, 
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. 
Kinn 
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... 
Shambernaut 
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.... 
Killpixel 
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.

http://triptohell.info/moodles/junk/quakespasm-spike-r1.zip
contents:
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... 
Wow! 
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 
sprintf (ver, "QuakeSpasm %1.2f.%d"BUILD_SPECIAL_STR, (float)QUAKESPASM_VERSION, QUAKESPASM_VER_PATCH);

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

===============
TexMgr_AlphaEdgeFix

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

Yay!

#define NUMQUAKECOMMANDS (sizeof(quakebindnames)/sizeof(quakebindnames[0]))

I hate it when people don't do that, haha.

Misc #6

gl_model.c

"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.


@baker,
#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? 
@sock 
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. 
Spike 
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" 
@ericw 
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. 
http://triptohell.info/moodles/junk/quakespasm-spike-r2.zip

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 https://sourceforge.net/p/fteqw/code/HEAD/tree/trunk/fteqtv/net_qtv.h 
 
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 screens...you 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. 
 
bindlist.lst

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. 
Stuff 
@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.

@sock,
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.

@sock,
emitters: o.O near the origin, too, but also far too regular.

@sock,
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 
So... 
Is sv_protocol 999 supported now too? 
 
QS 0.92.0 added support for 999, not me. 
Oh... 
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??? http://scidavis.sourceforge.net/manual/pics/fit-multipeak-2.png 
 
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.

http://celephais.net/board/view_thread.php?id=60831&start=224

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.

https://www.opengl.org/sdk/docs/man2/xhtml/glFog.xml

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 0.0.0.0:26000 (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?

Nope. 
 
Nope.
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!...
*cough*
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. 
Wait 
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 quakespasm-spike-r2.zip, that is. 
 
Grab the progsdef.q1 from:

https://sourceforge.net/p/quakespasm/code/HEAD/tree/trunk/quakespasm/Quake/

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. 
#merge 
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. 
Precaches 
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)
{
remove(self);
return;
}
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);
self.health = 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;

walkmonster_start();
};


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 
R3 
http://triptohell.info/moodles/junk/quakespasm-spike-r3.zip

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) 
@Spike 
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 fvf.servequake.com

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 ... 
RCON

* 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. http://forums.insideqc.com/viewtopic.php?f=3&t=5593
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?.. 
 
Question:

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 
Scenario:

Someone is using DarkPlaces as a listen server.
They decide to coop.
They use multi-game dir for replacement content.

Problems:
(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. 
-quoth 
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. 
Stardust 
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. 
@spike 
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: https://youtu.be/9TWUVe2_T3c
2) Smoke: https://youtu.be/K4iyK6yW8bw
3) Flame: https://youtu.be/ZH9zMBCyRFw
4) Myst: https://youtu.be/YXRx6sr-H4k
5) Rocket Trail: https://youtu.be/mOE71jc0RtI
6) Decal: https://youtu.be/3mRtTRSOKeE
7) Model Light: https://youtu.be/L8QX0TuTLTw

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: https://github.com/bangstk/Quakespasm

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. 
@mh 
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: https://bugzilla.libsdl.org/show_bug.cgi?id=3432

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? 
@snaut 
animated textures ... beyond 10 per surface

It is 20 per surface already according to this ...

http://www.celephais.net/stuff/texturefaq.htm

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... 
So 
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". 
Hmm 
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. 
Mwat2 
 
 
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. 
@Pritchard 
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): http://www.kristianduske.com/fitzquake/
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. 
Ericw 
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. 
Barnak 
Special FX: Try the Spiked version. It's not the goal of regular QS. 
Mugwump 
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. 
Barnak 
A fork of QS made by Spike that supports fancy stuff like particles and weather effects. There's a tutorial thread here: http://www.celephais.net/board/view_thread.php?id=61351
Additionally, here: http://www.celephais.net/board/view_thread.php?id=61359 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).

*shrug* 
 
Heh, well at least there are people interested in your work... 
How To Trigger Spike 
Particles 
Spirkticles! 
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. 
Barnak 
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. 
 
@Mugwump,
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. 
@spike 
-/*QUAKED trigger_magicear (0 0 1) (-8 -8 -8) (8 8 8) IGNORE_SAY IGNORE_TEAMSAY IGNORE_TELL IGNORE_INVALIDTELL REPLACE_WHOLE_MESSAGE REPLACE_OUTSIDE CONTINUE NODECOLORIZE
-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 be triggered.
-target2: all entities with a matching targetname will be triggered.
-target3: all entities with a matching targetname will be triggered.
-target4: all entities with a matching targetname will be triggered.

/Xonotic QuakeC source code 
Baker 
My OS X 10.6 is full 64 bit.

If Quakespasm runs well on it, then it should run well on all newer OS X's. 
 
such that mods like SMC can run
Ooh, I wonder if Seven knows about this...

The more I read about QSS, the more it looks interesting to me beyond the scope of playing maps/mods that DP breaks. I'm an aspiring mapper and one of my main concerns is compatibility with at least the most popular engines. Something that seemed hard to pull of with regular QS vs. DP/FTE, according to a discussion I had a few days ago on the map jam 8 thread.
Lately I had noticed a trend among mappers to only care about QS anymore because having to juggle the different behaviors of engines became a PITA, while a few years ago they often tested their maps in 3 or 4 engines. I was even considering making 2 versions of my maps, one for engines that support graphical enhancements and another for the QS/Fitz family. Hopefully QSS will level the gap between those engines, be adopted en masse by QS users and I won't have to resort to that if I want QS purists to play my maps. 
 
This is going to sound really crazy, while testing my start map for the last jam I realised that blooms or similar would work really well for the streetlights.

Normally I think such features in a game like quake would be OTT (and I do think a lot of the features in DP are OTT). But standing under a streetlight looking up at it, you shouldn't be able to see the texture of the light itself, just brightness.

Anyway, I know this was only sort of tangentially related to the discussion at hand, but I thought it was interesting none the less. 
 
Spike lacks enthusiasm because he isn't being stimulated by an exciting challenge like writing a Vulkan renderer. Spike is in it for the puzzle solving.

So ... Spike here's a challenge you might enjoy thinking about.

Challenge: Take DPMaster source code
1) Implement connect mechanism that the client sends to DP master to tell it that it wants to connect to a server.

Client to DP Master: "I want to connect to 33.44.55.66, I will be using the current IP:port"

DP Master to Quake Server: "9.8.7.6 wants to connect to you with (client ip:port)"

DP Master initiates some STUN/ICE/TURN server action with the client/server to punch a hole.

*BAM* You don't even need to mess with port forwarding on your router any more.

Complete server freedoms for all! Casual player just starts server and it work for all.

/I wonder if Spike has thought of this before. I would guess that he HAS. 
ICE 
I already implemented ICE with fte's xmpp plugin (including STUN, but not TURN because I'm too much of a cheapskate and I'm too lazy to deal with public TURN servers). You can use it for either voip calls (compatible with eg linux versions of pidgin) or for playing quake.
The only real limitations are that it doesn't really show any serverinfo nor ping, just the server's 'nick', and that servers/clients don't auto-join any chatrooms (iirc chatrooms are still kinda awkward to get going, at least compared to one-on-one chats - xmpp isn't like IRC in that regard).

Starting such a connection basically requires that both the client and server use some sort of identifier such that they can resume the connection if their IP changes (notifying the peer of new candidates).

Getting that secure enough to block hijack attacks would require tls or something... in which case dpmaster kinda becomes obsolete.

Either way, there's no way that bloat would get merged into QS, so you'll just need to stick with the existing fte plugin if you want that sort of thing.
Its not going to happen so any more discussion on that subject is kinda offtopic. 
Baker 
... gotta have a Mac to compile Mac version ...
... Ericw = only guy on planet who can make binaries for Barnak's Mac.


None true. I suggest that you look at the cross-compile scripts
in the qs source tree. 
 
@szo -- re: build script contents --- that's very interesting. 
@Baker 
@szo -- re: build script contents --- that's very interesting.

Read them along with the associated makefile.

Setting up the cross-toolchain requires some getting used to,
but once that is done, it becomes heaven on earth. 
There's Also This 
https://github.com/tpoechtrager/osxcross

Never used it myself, though. 
 
Baker, you don't need anything special to build a 10.6+ 32/64 bit Intel .app using the latest macOS and Xcode, just checkout Quakespasm svn,

cd MacOSX
xcodebuild -project QuakeSpasm.xcodeproj

The only Mac configuration of quakespasm that isn't so easy to build is the 10.4 PowerPC one. We have a separate Xcode project in svn that builds on xcode 2.5 on OS X 10.4 so you can actually run and debug on a powerpc mac if you have one. 
A Horrific Texture Problem 
I recently updated my Nvidia graphics drivers to 375.70, Windows 7 64-bit. As a result, Quakespasm 0.92 shows some terrible texture problem that must be seen. https://www.youtube.com/watch?v=ulOeZEYqOk0

As you can see, its like some weird texture overlap on one another, and even weirder is it mostly affects floors, it rarely affects walls or ceilings and models are untouched by it. The problem is present in all texture modes, the one I use is gl_nearest_mipmap_linear.

Obviously the easiest solution is to revert back to older drivers, but is this affecting anyone else? 
 
anistrophy without linear filtering is basically implementation-defined. The driver is free to ignore your attempt to use nearest filtering, or even to only partially obey it, resulting in bluring between mip levels.

you can tell that its anisotropic filtering at fault, because it only really happens on surfaces that are at an angle to the view, as opposed to any surface merely between mip levels.

side note: for the highest texture filtering quality with the lego look, you probably want the minification filter set to linear, the mipmap filter linear, and the magnification filter set to nearest. unfortunatetly most engines do not allow using independant settings for the min+mag filters. this results in aliasing that is visible on maps the width of eg dm4 
 
Hm. I've never seen those black lines through lava at 0:36.

try disabling anisotropy with:
gl_texture_aniostropy 0 
 
unfortunatetly most engines do not allow using independant settings for the min+mag filters.

It's worth noting that this setting is legal in both GL and D3D.

However, GLQuake's gl_texturemode just selects the min and mip filters, then assumes that mag is going to be the same as min.

It's probably worth bouncing around suggestions for how to cleanly handle this without breaking compatibility. Add new filters to the end of the list? Add a separate command to specify mag (and a "revert to default" option)? Accept breaking compatibility and chuck out gl_texturemode, adding new commands for gl_min|mip|magfilter? Some combination of these? Something else? 
Ooops, Double Post... 
However, GLQuake's gl_texturemode just selects the min and mip filters, then assumes that mag is going to be the same as min.

It occurs to me that this may have been a constraint of 3DFX and other contemporary video cards but which is no longer relevant. 
 
the gl_texturemode list currently has 6 enumerated items, i don't think it breaks compatibility to add more at the end.

I think it merely doubles the length of the list to support mismatch of min and mag filter, which isn't that bad. 
Gl_texture_anisotropy 
Well I would love to tell you if this worked, but Quakespasm simply refuses to turn it off. Whether it be through the command line, or the autoexec.cfg, Quakespasm decides gl_texture_anisotropy must always stay at 1. 
 
https://www.opengl.org/registry/specs/EXT/texture_filter_anisotropic.txt

When the texture's value of TEXTURE_MAX_ANISOTROPY_EXT is equal to 1.0, the GL uses an isotropic texture filtering approach as described in this section and Section 3.8.6. However, when the texture's value of TEXTURE_MAX_ANISOTROPY_EXT is greater than 1.0, the GL implementation should use a texture filtering scheme that accounts for a degree of anisotropy up to the smaller of the texture's value of TEXTURE_MAX_ANISOTROPY_EXT or the implementation-defined value of MAX_TEXTURE_MAX_ANISOTROPY_EXT.

A value of 1 is off; unfortunately the stock code contains assumptions that are inconsistent with the spec. 
Orl 
I tried updating my nvidia driver to 375.70 and I don't see anything wrong (tried all the texture modes, gl_texture_anisotropy 1 and 16.) I am on Win 10 64-bit and a GT 650m, so I imagine it's a case of a different hardware generation behaving differently.

Would you mind uploading a full resolution PNG screenshot? The youtube compression makes it a bit difficult to see. 
Certainly 
https://i.sli.mg/tV6enY.png

I am using an Nvidia GTX 970.
I would hate to think its the cause of the newer hardware generation, but hopefully its not a complicated issue. 
 
I'm still on 372.54, so I can't say if I'm having the same issues or not. I can say however that the 9XX series of cards are a real pain for compatability compared to older generations... The example that sticks out to me was NFS Shift 2, which would frequently display black frames that made the game basically unplayable.

You could try rolling back and seeing if that helps, unless you desperately need whatever new game support the latest drivers have... 
 
Even forcing Quakespasm to use no anisotropic filtering through the Nvidia control panel, the issue still persists.

I feel like I really screwed the pooch by updating, but it I haven't in so long and felt it was time to do so. 
Orl 
Have you tried rolling back the driver update? 
Just Did 
Rolling back the driver to version 364.72, dated march, fixes the issue. 
So Now 
You could try the second to most recent drivers and see if the issue is there. Basically once you find where the issue first appears, you need to investigate the patch notes and see if any setting had been added or defaults modified from a previous version.

I don't know, that's the best I can think of when tackling from Nvidia's perspective.

I use a 980ti and I believe I have either the latest or second latest driver and do not encounter this issue using the latest non-spiked QS. 
I'm Almost Certain This Has Been Asked Before 
But why does QS have different strafe jump acceleration to darkplaces, and others? 
 
I'm gonna go out on a limb and suggest that it's darkplaces that has the different-from-quake movement code, and not QS. 
 
I remember hearing that in vanilla quake, "always run" had different (slower) movement than holding Shift, and that QS changed it so "always run" is the same as holding Shift.

I think this is the patch that changed that (while adding QS's feature that pressing Shift while "Always run" is enabled slows you down to walking speed):
https://sourceforge.net/p/quakespasm/code/797/ 
 
edit: load the entire Fitz Mark V thread and search in the page for "always run" - Gunter talks about it.

I'm not 100% sure about any of the above, but it sounds plausible after a quick glance at the code. 
Thanks Ericw 
That was exactly what I was looking for. I plan to expand my quakespasm-irc port to include speed running features, and "fixing" the strafe jump to the accepted standard (by the speed running community) needs to happen for runs made with the engine to be legitimate. 
 
Isn't that just console variable manipulation? 
 
I'm not sure if QS inherited the code from fitzquake. Gunter explains it in post 1149 in that thread.

What I might do is enable caps lock to be used for +speed. That way you don't need to physically hold down the key in order to always run and get the bonus strafe speed. 
@ericw --> 
Dear Ericw,

... I�m converting myself to pixels (read --> gl_texturemode GL_NEAREST_MIPMAP_LINEAR), but on the other hand, I don�t want to delete my collection of HD textures.

My idea is to put all the HD textures in a HD directory.

With DP is then possible to recall the HD texture when needed with a command like: GAMEDIR HD AD.

has QS a similar command line? command line like "-hd -game ad" does not work, while command line like "-quoth -game 5rivers" does ... why?

Ciao 
I'm Not Ericw 
The stock Quake engine only supports -hipnotic and -rogue, and these commands have other effects besides just loading a new game dir - they also change the Status Bar layout, for example.

Quoth requires the Hipnotic status bar layout so many engines add -quoth as another option to allow players to more easily specify this. Otherwise players would need to use -hipnotic, thus creating a dependency on the Hipnotic mission pack being installed, and with a side-effect of making it more difficult to split the Quoth content from a mod that uses it.

The big take-home from this is that a game dir that functions in a manner such as Quoth, Hipnotic or Rogue must be explicitly hard-coded in the engine. You cannot specify "-hd" and expect the "hd" game dir to load, because it's not been hard-coded in the engine.

Multiple game dir support - such as "game hd ad" - is trivial to add to the console but slightly more difficult to add to the command-line. 
 
Otherwise players would need to use -hipnotic, thus creating a dependency on the Hipnotic mission pack being installed, and with a side-effect of making it more difficult to split the Quoth content from a mod that uses it.

You don't need hipnotic to be installed to change the HUD with -hipnotic. You don't even need the directory to exist.

The second point still stands though. 
Thanks ... But Then 
would it be possible to hard-code "-HD" just for textures?

hard-coded in order to allow command lines like:

-hd (for ID1 and/or generic maps)
-hd -hipnotic
-hd -rougue
-hd -quoth (-game 5rivers)
-hd -game ad

..etc.


..etc 
@mh 
The (sloppy) DarkPlaces multi-game dir system that has 3 major flaws also depends on the same system that allows DarkPlaces to crash if you have a start.lit file for a different start.bsp

Quakespasm, on the other hand, has the "Quakespasm content protection" system to prevent that.

Implementing a "hires" folder capability as a separate cvar like "cl_replacementfolder" (name?) would be the right way to do it, but might not be trivial to implement due to the above. It would need to be placed at the end of list.

The (sloppy) DarkPlaces way is not the right way.

If it were, a lot of engines would do it that way --- case in point Quakeworld loves replacement textures --- but ezQuake would never do such a thing because the (sloppy) DarkPlaces way breaks the QuakeC precache system and cannot tell replacement content from the original content.

(Also would happen to mess with physics in a FitzQuake engine in some circumstances due to FitzQuake using the model bounding box instead of -16, -16, -16 to 16, 16, 16 ... so your replacement content could actually affect the in-game play in some situations).

The right solution for people like Icaro is a separate cvar for the use of such a folder, and then maybe adjustments as uncommon problems crop up. 
 
If it were coded as a separate cvar or a command like option like -hd as Icaro suggests, it would be easier to tune and get users to have the right habits.

I've seen notes in Quakespasm Spiked where Spike was at least thinking about the vastly enhanced networking code provide for automatic download for coop (and even the start of commented out prediction code).

Implementing something that separately specified a replacement content folder for the client would be compatible with not breaking such ideas.

(But the DarkPlaces (sloppy) multi-game way would totally break it. ... you would no longer know the user's intent and whether a folder is the game data or if a folder is intended as client-side replacement only.) 
@Baker 
fte has a 'gl_load24bit' cvar that can be set to 0 to disable replacement textures.
it has a similar cvar for alternative model extensions to try to load (screw s_light.<mdl|spr>).

this means that mods can provide one set of content for chunk pixel style stuff, and another set for people that weirdly crave shinies and a lack of clear boundaries...
imho, that's much cleaner than lots of different extra directories all over the place.

the easy way to fix the +/-16 issue is to just have setmodel use +/-16 for ANY model with .mdl as an extension. This fixes md3s replacing ammo boxes or whatever other issues that plague DP's replacement models, and also means dedicated servers don't even need to load all of those .mdl files, giving slightly faster map loading in multiplayer. Really its a win/win situation!

regarding downloads, both gamedir switching and downloading paks/pk3s have issues if not handled properly / explicitly. Which files to use/download/cache/reuse/delete is an entire subject in its own right. Avoiding the transmission of personal or copyrighted data makes things fun, and *which* network protocol to use just makes things that much more political.
So yeah, QSS doesn't do downloads, which saves me a massive headache. Besides, download code is annoying to test. 
@Icaro ... "hdfolder" 
I have a working solution to this problem in a version of Mark V that will be released in the next 30 minutes.

There is a command called "hdfolder" where you can specify the content replacement directory and change it, it saves to config.

So you can have different sets. A fair number of things that have been proven to be good ideas have gone from Mark V to Quakespasm or Quakespasm to Mark V.

/I'll save explaining to Spike why this is a needed feature or how it avoids every downside of DarkPlaces multi-gamedir for some other time. 
Retrojam5_shamblernaut 
Looks Like One Of My Fans Disappeared In The Final Build
... but only in QS... weird.

Weird. what QS version / OS / 32/64-bit, etc? 
Ericw 
I'm a version behind at 0.92.1
I'm running ubuntu 16.04 64bit 
Mouse Acceleration On Windows 
First of all, thank you for great port!

I'm wondering, is it possible to disable mouse acceleration on Windows 10? It looks like sensitivity in game depends on pointer speed in Windows. 
Perlence 
Try quakespasm-sdl2.exe, it should use raw mouse input on Windows. 
Ericw 
Thank you very much, it indeed helped! 
 
What's the reason for having two binaries anyway? 
 
SDL1.2 supports older OSes (back to windows 95? and the mac version, back to 10.4/powerpc), but it's no longer under development.

SDL2 has more features (raw mouse input, borderless fullscreen, better international keyboard support, etc.) but has had more bugs.

At this point I recommend using the SDL2 binary unless you need the old OS support. 
What Is SDL2's Oldest Supported OS? 
 
Win XP / Mac 10.6 
 
Model Loading Glitch 
I recently recorded some Youtube videos for Retro Jam 5, and in the process discovered a glitch with regard to model loading. I'd initially passed it off as an Nvidia driver problem, but I'm not sure. EricW commented on one of my videos to see if I could reproduce it, and he'll be happy to know I've managed to do so:

1.) Running Quakespasm 0.92.1 (I was running 0.92.0 for the videos, but 0.92.1 works the same way) and Nvidia driver 375.95, run quakespasm -game retrojam5, make sure the game is running at 1920x1080.

2.) In the console, load my RJ5 entry with 'map retrojam5_tens'.

3.) Hit Escape, and in Options|Video Options, change the resolution to 1280x720 and Apply Changes.

4.) Load the first map in the pack, 'map retrojam5_breezeep'. You should see two light fixtures at the far end of the room with flames in them, clearly visible, no problems yet.

5.) Drop the console and go back to my map with 'map retrojam5_tens'.

6.) Again in Video Options, switch back to 1920x1080 and Apply Changes.

7.) Load Breezeep's entry with 'map retrojam5_breezeep' and the flames should be invisible.

If you follow the same procedure, but replace retrojam5_breezeep with retrojam5_newhouse, you'll find not only missing flames but invisible enforcers, which makes for a bit of interesting gameplay. Not sure why it only affects some models, or how I might reproduce the glitchy blue polygons you can see in parts of my video for NewHouse's map, I'm sorry.

It's a bit of a convoluted procedure, but in prepping for the video recording I was toying with my settings, going back and forth between maps and changing resolution, so it's no wonder I stumbled over whatever's happening here. 
Possible Func_wall Problem 
Just to keep these two reports clearly separated, I'm using a new post for this one.

Also with regard to Retro Jam 5, and also in Quakespasm 0.92.0/0.92.1, my map has a hovering quad damage, using the trick of having a func_wall underneath it and firing killtarget at the map start, from a trigger placed over the playerstarts.

In one person's demos/video, namely khreathor's, the quad is instead sitting in the water underneath it. Some discussion with him revealed that when loading the map with 'map retrojam5_tens', the quad is suspended midair as expected, but subsequently using 'restart' means it falls down into the water.

While the map doesn't fall completely apart if one grabs the quad out of order, it is a bit less fun, and though adding a short delay to the trigger that kills the func_walls might have avoided the issue, it raises the question of whether this behavior is by design or is some sort of bug. Should this be happening? 
Second Bug 
Is this bug specific to Quakespasm? There have been other instances in Quake where the restart command doesn't behave like loading the map normally, e.g. https://tomeofpreach.wordpress.com/2016/06/19/missing-items-and-the-restart-command/ 
 
Oh, it might just be my ignorance, then, sorry. I'm not intimately familiar with the subtleties of Quake and its various sourceports, so if this is standard operating procedure that mappers are just expected to accommodate, never mind the second bug report, I'll just get used to it. 
Excellent 
I reproduced the invisible flames, thanks for the detailed steps! 
#2612 
ahh good to know. I'll use "map" instead of "restart" from now. I wonder if putting Quad higher above the func_wall will fix this behavior? 
Ok This Is Weird... 
QuakeSpasm 0.92.1 - I can't load E1M7, I get

"host error: mod_loadclipnodes: planenum out of bounds" 
 
If you talk about vanilla e1m7 it works fine for me on QS 0.92.0 
Works For Me On 0.92.1 Too 
maybe you have corrupted pak or something ? 
 
yeah vanilla, no mods or anyfink. SDL2 version if that makes any difference 
 
Just tested E1M7 in 0.92.1 with the SDL2 exe and it loads fine. 
 
Weird, I've never seen that error before.

Check the md5 hash of pak0.pak, it should be one of:

85fc9cee2035b66290da1e33be2ac86b
5906e5998fc3d896ddaf5e6a62e03abb
- https://quakewiki.org/wiki/pak0.pak 
Combining Two Rogue Fixes? 
Today I played the MP2 (Rogue), and I ran into a problem.

We all know that elevator in R1M7 is broken, and while Seven made a fix, it was done via progs.dat file.

Few years ago, I asked someone to interpolate the Rogue buzzsaws movement, so Necros made a quick fix. The problem - it was also done via progs.dat file, but the game can use only one progs.dat file at a time.

I don't have any experience in QC, but is there any way to "combine" the two fixes? I have source files from both fixes - BUZZSAW.QC from Necros, and a folder with many QC files from Seven's fix. I hope someone can do this, here are the files:

https://www.sendspace.com/file/zdcg8w 
ToMaHaKeR 
Instead of asking people "please do this for me", which will most likely be met with a resounding "no", ask "how can I do this?"

I've found an apparently very clear tutorial that will guide you through the process of making your own progs.dat. It seems quite simple. Looky here: http://www.angelfire.com/ult/td/tuts.html 
Necros Did It On His Own 
I replaced the BUZZSAW.QC from Seven's folder with the one from Necros, and compiled using the default settings in FTEQCC GUI. Result is that Seven's fixes work, but Necros buzzsaw fix is ignored. It would seem there's more to this than just modifying BUZZSAW.QC file.

And I didn't actually ASK Necros (or anyone) to do this, I just reported the problem and Necros explained it and made a quick patch. 
Checksum 
Well pickle my pangolin, that was it - my pak0 was scrozzled, with a different checksum to what it should have. Which means some data on my hard drive became corrupted, which is worrying!

I re-downloaded from Steam and all works.

Cheers cheps. 
Weird 
R1M7 elevator works fine WITHOUT the buzzsaw patch, but the moment I add it, the elevator breaks. 
I Can Do It 
All qc must be subsumed into the collective.

I can't open your zip, 7zip says its corrupt. Maybe try putting it on quaketastic. (see screenshots thread for login+password)

What's wrong with the elevator? I never noticed anything on my last playthrough. Granted I think I was 14 at the time.

Buzzsaws interpolation:
Do you mind sending me what necros said to you? Also, are both progs.dat files in your rar? I can decompile the progs to find out what all else he did to it. I've become a qc comparison junky of late what with AD absolutely doing everything better so of course I had to update my own personal mod to add some awesomeness. 
Weird Indeed 
Well honestly, "I hope someone can do this" sounds a bit like asking people to do it for you... ;) Anyway, this thread is dedicated to Quakespasm and people here are not too fond of off-topic, so you should move your problem to that thread instead: http://www.celephais.net/board/view_thread.php?id=60097
I wish I could help more but I know about as much QC as you. 
To Qmaster: 
Check this out. Few hours ago, I tried compiling Rogue progs.dat from untouched Rogue source code (QC files). Guess what? Elevator doesn't work. I can't explain it, since the elevator DOES work with progs.dat located in original PAK0.PAK straight from the Rogue CD. Is it possible that Rogue CD contains different version of the PAK0.PAK file, with some kind of fix?

Necros said:
"The buzzsaw doesn't actually move in the normal way. What it looks like (only from looking at the QC) is you make a func_train or something that the player can't see. Then you target the train with the buzzsaw. Every 0.1 seconds, the QC sets the origin of the buzzsaw to the targetted train. This is why it doesn't interpolate, because it's not supposed to-- the QC call is setorigin."

Necros patch: http://s000.tinyupload.com/index.php?file_id=67396143984564862910

Seven's fixes: http://s000.tinyupload.com/index.php?file_id=56371481422796763833 
(Seven's fixes still corrupted, I don't know why, here's a direct link from QuakeOne)

https://www.dropbox.com/s/j2zixlpqcpt5tjy/ROGUE%20fixes%20V1.11.rar 
@ToMaHaKeR - Is This A QuakeC Help Thread? No It Is Not. 
Post your QuakeC questions in the following thread, which is a Quake help thread:

http://www.celephais.net/board/view_thread.php?id=60097

Your hipnotic buzzsaw issues have nothing to do with the Quakespasm engine. 
Told Ya... 
You'd better listen to Baker this time if you don't want to piss people off. 
Bug: Some Keystrokes Are Ignored In A Certain Situation. 
System, ubuntu 16.04, running latest quakespasm, quakespasm executable (does not occur in quakespasm-sdl2) lauched from terminal without any parameters.

Replicating the bug:

Upon load of the game, new game is selected. *Just* before the console retreats all the way to the top the tilde key is pressed and the console comes down again.

Here is where the bug occurs, the console, instead of staying down, goes back up. Now every time the console button is hit, the console will drop, then return back to the top.

This also affects other keys, if you then hit escape and go to "new game", when you're prompted "Are you sure you want to start a new game", the game will accept no input.

Alt-Enter is locked, so I can't quit the game, Escape is locked so I can't return to the menu. All I can do is change terminals (ctrl-alt-F1) and kill quakespasm. 
Thanks 
I reposted it to the bug tracker, hope you don't mind: https://sourceforge.net/p/quakespasm/bugs/17/

I have seen it before and IIRC it was SDL1.2 sending invalid key presses, but it would be good if QS behaved better if possible instead of locking up.
Good that SDL2 is working properly though, that was my experience as well. 
Heh, It Was Avoidable 
I've been using the 1.2 up until this point in time because for some reason my system (or quakespasm) wanted 32 bit SDL, vorbis and mad libs.

I didn't have them installed because I've been trying to avoid system bloat. I've installed them now though. Fingers crossed it won't break any of my other games :) 
@shamblernaut 
weird, I'm having trouble reproducing it at the moment. The last time I saw the bug was a year ago or so, but I don't run QS on linux very often, just when testing releases really. I am also on Ubuntu 16.04 with all updates applied, and using the unity desktop.

Just to double check the SDL version you have, mind running this?
dpkg -s libsdl1.2-debian | grep Version 
 
The command you supplied tells me its not installed, the version I have installed is 1.2.15+dfsg1-3 according to synaptic.

I just looked up what dfsg meant, apparently its debian free software guidelines. Now I wonder if the dfsg version is behind the non-dfsg version. 
It Was I All Along 
I'd just like to make the following correction. Over a month ago , post #2571, I reported a problem with Quakespasm and the latest Nvidia drivers cause an ungodly texture blurring scenario, and I was curious as to why nobody else was experiencing the same issue.

As it turns out it was my fault. I did a complete uninstall/install of Nvidia's latest Windows 7 drivers, totally clean. The problem was gone, so I can only conclude it was a certain graphic setting I had used within Nvidia's control panel, but which one it was I don't know. Or it may have been something else entirely.

But either way nothing is wrong with Quakespasm, nothing (as far as graphics are concerned) needs fixing, and I apologize if I caused any time wasted trying to figure out a problem that was never there. 
Antialiasing - Transparency 
Is the culprit responsible for Quakespasm's blurry texture scenario when using the latest Nvidia drivers. Avoid using that setting. 
CPU Usage Goes Nuts When Minimised 
OK, when minimised, Quakespasm's CPU usage shoots right up to use over 20% of my CPU, and my fan kicks in to overdrive (happens the same whether I'm in fullscreen, then alt-tab to windows - or in windowed mode, then I minimise the window).

I'm using the SDL2 version. 
@QuakePone 
I implemented a lightmap format change that may help the AD start map performance on your Intel graphics system:

1. unmodified svn r1371
2. new lightmap format (GL_BGRA GL_UNSIGNED_INT_8_8_8_8_REV)

I wonder if you could test these two buildson your system and report what FPS range you get in ad1.5's start map for each build.

link to source code 
Fyi 
I can't measure any difference between those builds on:
-Intel HD Graphics 4400 (2013? laptop)
-Intel 855GM (2004 laptop) 
 
Back a few years, I tried that modification. Tried the binary on several machines, couldn't locate one where it made a difference (Intel, GeForce, Radeon, etc.)

I believe such machines do exist, but I just didn't have any of them. 
 
Baker, yeah.. MH mentioned in the insideqc thread:

This is only really important for Intels that have hardware T&L - say, the 965 onwards; it seems as though earlier generations are more tolerant.

I guess my old intel is the more tolerant earlier generation.. and my newer 4400 came out several years after that thread, so apparently Intel fixed the perf issue by that time. 
 
Yeah, I haven't tested this in a long time but I don't believe it's an issue any more either. GL_RGB should still be an issue, but GL_RGBA should be fine. 
 
Just for reference, I've tested these builds on a more recent Intel 520 machine without measuring any difference either. This supports my guess that with DX10+ class hardware (where Microsoft forced the vendors to standardise on RGBA) it no longer matters.

A more interesting benchmark would be gl_flashblend 1 versus gl_flashblend 0. That would really help determine if it's dynamic light uploads. 
 
Thanks. For reference, build #1 I posted above (and QS releases) are using GL_RGBA / GL_UNSIGNED_BYTE.

--
Question for Shamblernaut:
Can you still reproduce the console retraction bug with sdl1.2? I just tried again and can't trigger it (though I remember seeing it like 1-2 years ago).
I tried in the default ubuntu 16.04 Unity desktop as well as the "ubuntu flashback (metacity)" one. Tried both windowed and fullscreen. 
Further Comparison 
This time on an Intel HD2000, which is closr in performance to @QuakePone's, but still no measurable difference. 
Shamblernaut 
You can disregard my question, managed to reproduce the console retracting bug 
I Didn't Even See The Question 
That's what I get for skim reading.

As an aside, is there any particular reason for console commands being case sensitive? I understand that filenames require it, especially in *nix based systems. Is this just a legacy code thing or are some commands actually case sensitive? 
 
in certain cases, yes, especially if you're exposing them to qc.
there's no good reason for case-sensitive tab completion though. 
I Honestly Can't Even 
I did test ad_start first by doing nothing and then b-hopping around until I catched those frame drops in each version. The more I tested the less times I encountered them and I usually got different results every time I restarted the map in 92.1 before this.

FPS go around 27 but in 92.1 I sometimes got the framedrops during late tests. It's very unconsistent.

You can't really take my word here, I am very confused about all of this and in the end I will probably need an engine that takes more advantage of unused GPU power. Sorry, I can't be of much help here. 
 
Ok, thanks for checking anyway. It sounds like the GL_UNSIGNED_INT_8_8_8_8_REV thing is no longer an issue.

My laptop with Intel HD 4400 is faster, but QS doesn't exactly fly on content like AD; some time I will have to look more closely at whether I get the same speed increase when switching to MarkV DX9. 
AD Content 
This isn't something I've sat down and analyzed. I'm just making general observations here.

Even with the fastest lightmap updates in the world, you'll still bottleneck on lightmap updates. In RMQ we had a scene with 20+ flickering candles; every lightmap in the scene would get updated and it would pull the NV 280 (I think) machine I was using at the time down to 20 fps.

GPU lightmaps are the future. Dynamics still have a cost but lightstyles are completely free.

FitzQuake's brush model renderer sucks. If you were to be actively malicious and deliberately set out to write a bad brush model renderer you might do worse but I doubt it. Ideally brush models should go through the same renderer as the world. A map with lots of brush models is always going to run slow.

FitzQuake's sky renderer sucks. If you were to be actively malicious and deliberately set out to write a bad sky renderer you might do worse but I doubt it. I had one of those "sweet baby Jesus" moments when I analyzed a scene in PIX and saw that 80% of the time was spent drawing sky. Any scene with sky in it is going to bog down on slower hardware.

What both of those have in common is per-polygon state changes. In the absence of batching in your own code the driver will make reasonable efforts to batch itself, but state changes will break that.

There are certain items of "Quake lore", such as Quake can't do big scenes, sky is slow, disable multitexturing, and so on. They're not true. The problem is in the implementation, and they can all be solved. 
@mh 
In Quakespasm, the brush models are drawn with the world, if I recall.

As a general note, since I don't know if you are aware of this -- Arcane Dimensions is a bit less optimal than some other single releases in a couple of departments:

1) First, it uses sprites as particles. So each little floaty pixel is an entity. You can turn this off by doing "temp1 0" and restarting a map, if I recall.

2) Second, you know static entities like torches? Arcane Dimensions doesn't do torches as static entities. And Arcane Dimensions uses a lots of torches.

I haven't checked, but combined with the fact that Arcane Dimensions maps tend to have tons of details and complex geometry and generally the maps tend to have at 200-300 monsters and super-tons of items/books/etc ...

It's a bigger load than most maps tend to be.

And because of the torches and particles, I suspect puts more pressure on the QuakeC interpreter too.

The end result is very cool and creative.

Also: I have never checked, but in complicated maps with huge entity counts -- how much is vis helping? Engines with r_lockvis you might not be able to tell ...

(If I "r_lockpvs 1" in Mark V, then no clip outside the start map it looks like this ...)

http://quakeone.com/markv/media/start_map_r_lockpvs.png

Now, mh, look at this ...

On ad_mountain ...

I type "r_lockpvs 1" and noclip outside map ....

http://quakeone.com/markv/media/ad_mountain_r_lockpvs.png <--- RED ALERT!!!

So ... whatever is going on ... vis is doing a very poor job ...

Imagine how many entities are drawn per frame with vis doing that? 500? 1000? I don't know, but frustum culling cuts some of that down.

So I wouldn't approach this this that the maps are optimal and the mod are optimal from a performance standpoint and the Quake tool are doing a good job.

Arcane Dimensions is a great experience, but there is plenty of room for performance. 
 
2nd opinion on "r_lockpvs 1" using DirectQ, just to make sure.

http://quakeone.com/markv/media/ad_mountain_r_lockpvs_directq.png

And let's throw ARWOP Roman1 into the mix which isn't Arcane Dimensions ....

http://quakeone.com/markv/media/arwop_roman1_r_lockpvs.png

^^^ With vis generating results like the above, well --- let's just say the wide open outdoors map thing sure doesn't vis very well. 
Vis On Big Maps 
Is a struggle.

In the old days mappers used water volumes to control vis as they were vis blockers. I asked ericw to add a vis brush to perform this task instead when compiling. Don't think it was ever implementedy 
 
Vis doesn't do its job all that well, not even on many of the original Quake maps.

But Sometimes it does.

But the real problem is even more insidious.

Vis is used to determine what entities Quake thinks you can see!

If it is drawing damn near the whole map, it's also drawing all those spritey particles and perhaps most of the monsters in the map. 
@mh ---- 
In Mark V, if I type sv_cullentities 2 in the console.

I get a significant frames per second boost. 15-20% on ad_mountain.

sv_cullentities 2 is a very strict "is the entity visible" check on the server side against all entities. It is otherwise known as "anti-wallhack".

It's also a somewhat cpu expensive, but I guess it is saving several hundred entities from being drawn at all so it is paying off here. 
That Ad_mountain Pic 
Could that be detail brush shenanigans? I remember a discussion once where it was concluded that detail brushes can sometimes mess up the PVS if they totally cover a world face. 
Baker 
Try it in id1 Zendar and then ad_zendar?

I recall sock doing some hint brush fuckery, maybe that's the culprit. 
 
I wouldn't read too much into ARWOP behaviour, ARWOP is very much a special case.

The AD screenshots definitely indicate that something different is going on too. I'm going to do a bunch of testing on that and see can I figure what it is.

Re: VIS I'm amazed that no Q1 VIS tool has implemented area portals. Being able to lob off huge chunks of geometry just by closing a door is a win. I'd love to see Q1 VIS moving to legacy; engines can still load & use it for compat but let's standardize on Q2 VIS for the future. 
Hypothetical Question 
is there a different culling method that could potentially be written into a quake engine that would be better suited to big open maps? 
Vising Is Often On The Mapper 
designing as intelligently as possible. Don't make giant box maps (something I need to work on myself).

However it would be nice to have some extra toys to work with. 
 
Big open maps and culling are not the problem. The current culling is perfectly capable of handling them, a minor optimization to R_RecursiveWorldNode makes it a little better (software Quake has the optimization, GL doesn't).

The problem is in the renderer and server processing. QuakeSpasm now has the necessary renderer work to be able to handle big scenes. It could go faster by bumping the hardware requirements to GL 3.x and implementing array textures for lightmaps, as well as putting in some instancing for MDLs, but that might be too intrusive a change to the codebase.

Server processing is a problem and QC is just too slow for large entity counts. That's the next tree that has to fall. 
Vis 
I agree with mh, it still works impressively well on big, open maps, and it matters a lot on AD maps. ad_tfuma was fastvised it right up until release, because Fifth and I both assumed vis would take forever and not be able to optimize much, since it's more or less a giant box with some underground areas. Just before release, one of the testers complained of low fps, so I tried full-vising it - took only 20 minutes (8 threads), and the wpolys visible from the start position were cut in half (30k to 14k iirc).

QS's brush model renderer was the first renderer thing I changed (this was ~2014 for RRP, ijed's map had some complex bmodels), they're not merged with the world, but each is drawn using the world renderer.

QS uses the Fitz sky renderer unmodified. (same for liquids).

GPU lightmaps: blending the 4 lightmaps per face sounds like a straightforward good idea. I'm wondering if it will be difficult to do the moving dynamic lights from rockets/etc. IMHO they need to be kept at the low-res of the lightmaps - when I was experimenting with high res lightmaps and LIT2, I remember noticing that rocket trails really stuck out like a sore thumb when they were over a high-res lightmap. @mh did you do any experiments with this part of GPU lightmaps? 
GPU Lightmaps 
I draw dynamics as additive blended extra passes over the scene. Full per-pixel quality. TBH it doesn't bother me but maybe this is one of those things that annoys different people in different ways.

I guess you could use a low res attenuation map texture but I just do the maths.

Optimizations: Eric Lengyels scissor test optimization is mostly designed for shadows but helps here too. Frustum culling the dlight. Only light surfaces that were drawn in the main pass.

I also add dynamics to BSP brush models using this scheme.

Light styles: I actually use 3 textures, one for each of R, G and B and encode the styles into the color channels. Animation is a 4-component DotProduct per channel and combine them to the final color. 
@mh - Just So You Have All The Information. 
Another side effect, not related to rendering, of the vis problems combined with spritey particles is huge demo sizes.

As you know, the vis information is used to determine what entities the server side thinks is visible to you.

If you record a demo in most of the Arcane Dimensions maps, the demo is going to be massive after 30 minutes of play (600 MB).

I ended up disabling the autodemo feature by default in Mark V because recording a demo in Arcane Dimensions became a performance issue ...

... Which users perceive as "this engine is choppy", hehe.

So anyway, the full deck of cards.

/The very nice thing about Arcane Dimensions is that it is open source. Sock is #1 in my book because he's always been open source.

Which also means it is possible for new optimizations to theoretically be written eventually to shift some burdens from the QuakeC to the engine (particles).

Arcane Dimensions merely exposes things that the map compile tools and the engine particle systems could handle better. 
Ad+demos 
particles - qss uses fte's particle system to support the effectinfo stuff that sock used in ad, as a result qss should have much more sane demo sizes with ad 1.5.

choppy - use a thread to perform the disk writes, then you don't get stalls from flushing happening on the main thread.
making that change reportedly solved multi-second stalls with fte on linux.

size - gzip it as you go (you don't rewind, right?...). 
#2669 
damn

the demo that i recorded for ad_magna is 2gbytes

i checked with r_showtris 1 and no particles-entities, the demos should be smaller 
 
making that change reportedly solved multi-second stalls with fte on linux.

Interesting. 
R_drawworld 0 
All the FitzQuake derivatives support r_drawworld 0; fog 0 // fog 0 helps visualize distance entities.

The following screenshot demonstrates how map vis isn't helping much ...

Particles ... but as you can see there are tons of candles and monsters in the vast distance. It's a lot of unnecessary drawing.

http://quakeone.com/markv/media/r_drawworld_0.png

All those monsters that have no chance of being seen ...

1) Get sent to the client by server.
2) So they get recorded in a demo
3) So the engine tries to render them on the screen

Rendering hundreds of entities that cannot be seen is a performance hit. 
Hmm 
"Which also means it is possible for new optimizations to theoretically be written eventually to shift some burdens from the QuakeC to the engine (particles).

Arcane Dimensions merely exposes things that the map compile tools and the engine particle systems could handle better. "

I was tinkering around with an idea, (well mostly because I found what I did wrong with bsp2), working on some AD stuff, and particles. I started with making little flames on the tops of candles, instead of the bouncy little polygons. But I could expand this to replaces the sprite emitters from AD and use QMB particles on the engine side. I'll post some results/screenshots when I get things rollin'. 
Weird Bug 
Hey, I'm getting a weird wateralpha bug

see: http://imgur.com/a/rqoGv

the lava (or any fluid) appears milky except for when the player is clipped into a wall?

the alpha is set to 0.3

the version is version 0.92.1 (SDL 2 build)

I'm running ubuntu 16.04 LTS using opensource radeon drivers.

Is this a configuration thing or a software bug? Cheers. 
 
the map isn't water-vised...
(combined with gl_clear) 
 
I thought that the vanilla maps worked fine with wateralpha 
 
only if you revis them yourself, or use get vis patches.
otherwise they'll just be transparent and reveal the void below.

if you were using a value of 0.6, you might not have noticed. 
R_novis 1 
Will work but I believe it affects performance 
 
I thought that the vanilla maps worked fine with wateralpha

No, they don't. This is actually called out in the original GLQuake readme: https://github.com/id-Software/Quake/blob/master/WinQuake/docs/readme.glquake#L152

Unfortunately, the standard quake maps don't contain any visibility information for seeing past water surfaces, so you can't just play quake with this turned on.

Note that r_novis will just let you see surfaces through water; it will not let you see entities (monsters, doors, pickups, etc) through it. 
 
Mark V and DarkPlaces (rather sure) and some other engines support external .vis files.

https://quakewiki.org/wiki/External_Lit_And_Vis_Files

You put the .vis files in id1/maps and then all your Quake maps are vised.

It's pretty much the same thing as external .lit files. 
 
heh TIL

thanks guys :) 
 
I use this from BPJ wrote on an old thread on QuakeSource.org that just draws everything

[code]
byte *Mod_DecompressVis (byte *in, model_t *model)
{
static byte decompressed[MAX_MAP_LEAFS/8];
int c;
byte *out;
int row;

row = (model->numleafs + 7) >> 3;
out = decompressed;

if (!in || r_novis.value == 2)//BPJ
{ // no vis info, so make all visible
while (row)
{
*out++ = 0xff;
row--;
}
return decompressed;
}

do
{
[/code]

it simply allows me to see all ents underwater, yet im sure it's not optimal :P 
 
It's definitely not optimal because it will also pull in ents that would otherwise not be visible in a properly watervised map.

The other thing it will do is increase server load and protocol traffic.

The latter is something you might be surprised about. We have a tendency to base assumptions and measurements only on things we can directly see. In a scene with 400 active and moderately complex entities, the bottleneck isn't the renderer - it's PR_ExecuteProgram (QC, in other words). 
Sky Far Clipping 
Some weirdness going on with the sky at high distances: back wall disappears when more than 8192 units away. 
Check Gl_farclip? 
 
I Did. 
It's at 16k as per default. With normal textures it works fine, just the sky brushes are affected. 
Ah.. 
I bet it's a qbsp limit (BaseWindingForPlane). Someone reported this as a bug in tyrutils-ericw a while ago and I raised the limit, try the latest version of my tools. 
 
You really should just draw sky with glDepthRange (1, 1) - that way you can draw it as a tiny (but larger than nearclip) cube around the viewpoint and it will automatically position itself at the far clipping plane. The way Fitz & derivatives handle both the scrolling sky and skyboxes makes this very possible. 
 
I know most of the mods/maps have to be installed in the base Quake folder, but it really keeps that folder messy and it's hard to sort through if you have tons of maps/mods and when you want to delete a folder it's a hassle.

Is it possible to put all the mods/maps in a seperate folder and still be able to launch QuakeSpasm with enjector? I tried doing that but it won't let me because everything has to be in the basedir, is there a command i could use?

Is it possible to set a path to a different folder in quake injector? 
Elevators Etc. Working Funny Past Host_maxpfs 165 
Hi!

Thanks for all the hard work you've put on this great engine. It wasn't until now that I was able to come across a bug that I'd like to report.

Fairly recently I got myself a monitor with a max refresh rate of 165 Hz, so to squeeze out all that juicy smoothness the monitor can offer, I decided to adjust the host_maxfps setting in the config to 200. However, this causes problems that can be seen most notably in elevators: all entities onboard the elevator seem to kind of lag behind.

For example, if I go down an elevator, the elevator goes down smoothly, but I go down in skips, as if I was Wile E. Coyote forgetting that gravity exists for a split second and then I fall on the elevator again only to forget gravity for another instant as soon as I touch the elevator again. And the pattern repeats.

The same happens going upward, with more severe consequences, as I end up slightly inside the elevator, which may sometimes cause the elevator to think that it's squishing me, which causes it to damage me and then reverse back down.

I did some testing, and the only influencing factor seems to be the value of the host_maxfps setting. (Fiddling with the V-sync settings didn't seem to do anything.) The threshold value seems to be about 165, above which the problem starts appearing.

Anybody else have this problem? Sorry, if this has been addressed before. 
Framerate Is Tied To Physics 
In most quake engines and wasn't really designed to go that high. Some engines have uncoupled physics from framerate and work better at higher frames. I believe dark places is one such engine. 
Quakespasm And Raspberry (again) 
Hi,
I know QS is OpenGL while RPi is GLES, but, really, it would be great to enjoy Quake (or Arcane Dimensions)on a small, silent and low-power-consuming Raspberry Pi 3.
BTW Quakespasm is yet available in Raspbian Jessie repository, but I get a "Couldn't load video device" error when I try to run it in framebuffer mode (CLI).

So really no interest in a Raspberry support? :( 
Gles/rpi 
there's actually a few engines that support gles2 nowadays.
Izhido(was it?) had one for ios, alternatively there's multiple engines that run on android with its gles1/2 limitations, including my own.

If you grab the source for fte, you should be able to use the following command for the original rpi (cross compiles, you might need to fix up some assumed paths inside the makefile):
cd engine && make gl-rel FTE_TARGET=rpi
If they've fixed up their egl support since the original, you can try and be more generic and just use the following:
cd engine && make gl-rel FTE_TARGET=linux32 CFLAGS=-DUSE_EGL
With that generic build line, you can switch between egl vs glx under x11 with setrenderer egl vs gl.
I don't actually have any sort of rpi, so I can't really help much more than that. 
 
Funny thing I just ran across...

Using the latest 64-bit quakespasm-sdl2.exe, with the latest NVidia drivers, there are certain POV points on the DM3 bridge where sections of the outside pentagram area are being rendered in my view.

Screenshots:

https://www.dropbox.com/s/1b5cb0dbg9t51o6/spasm0000.jpg?dl=0
https://www.dropbox.com/s/nlst7lupknon1ga/spasm0001.jpg?dl=0

and here's my config.cfg and autoexec.cfg:

https://www.dropbox.com/s/wm75461ngtotcv8/config.cfg?dl=0
https://www.dropbox.com/s/6i1jj64oelutyg2/autoexec.cfg?dl=0 
 
I think it's just r_wateralpha 0.5 in config.cfg + non-watervised bsp (QS has had gl_clear default to 1 for a few versions, so you don't get HOMs anymore, but you get that instead, which is less obvious what's happening).

So it's good that it's not some deeper bug in the renderer, but this is a common enough thing (it's been reported a couple times I think, happens to me fairly regularly) that we should probably do something about it...

IIRC, QS has had r_wateralpha be archived in config.cfg since an early version, and when you combine that with changing gamedirs with "game" you can easily launch something like AD, then change to id1 in the console, exit, and end up having r_wateralpha 0.5 saved in your id1/config.cfg.

There's also the option of having the engine detect watervis, etc. 
 
Ah hum. Yeah I clean-installed recently and I guess I picked up a default r_wateralpha of 0.5 from either QS or Mark V. Actually it's been so long since I messed with those settings for non-watervised maps I forgot that it even had an effect if r_novis was 0. 
320x200 Fullscreen Scaling 
I really wan't to play Arcane Dimensions in low resolution. Unfortunately mark v, which supports resolution scaling, doesn't support AD. The winquake version has problems everywhere and the opengl version can't handle some things like the fog in the necromancers keep. Apart from that performance is also really bad. mh explained how that has to do with mark v being cpu-bound while engines like quakespasm are fillrate-bound, which also means that downscaling would greatly improve performance in quakespasm while having close to no benefit in mark v.

I mainly wan't this feature because of the way it looks (explained in detail in my mark v post here: http://www.celephais.net/board/view_thread.php?id=61375&start=1487 ), but the potential performance boost is also incredibly useful to me as I'm running quake on pretty slow hardware. Quakespasm is already a huge improvement over mark v in AD, but I still get occasional framedrops on 1366x768 (native resolution of my laptop) while 320x200 runs silky smooth. Of course not in fullscreen, but quakespasm will output that resolution in windowed mode if you specify it with -width and -height. That proves to me that the resolution I wan't to play on is at least technically possible in quakespasm, I would just need a feature similar to that in mark v which stretches a borderless window to fit the full screen without interpolation. You can even simulate something like this by using the windows magnifying tool, but it's horribly awkward to set up and doesn't allow you to use the mouse (more on that in my last post in the mark v topic).

So, getting to the point here, I will pay the developer who implements this feature in quakespasm. That's how badly I want this. I absolutely love quake, and the amazing lovecraftian environments in AD make me truly happy to experience, but I can't enjoy them as much on high resolutions as I would otherwise.

If you're one of the developers reading this, name your price for the time it would take you to implement this. I will pay you, given that the price is within reasonable bounds. 
+1 
Not sure I'd play on 320x200 but less detailed quake maps definitely look better in lower resolutions IMO. I tried setting QS to a lower res than my laptop screen, but my screen just blurs it and it looks terrible. It would be nice to have the option of playing on lower resolutions but with krisp krunchy krixels 
 
Yep. In vulkan quake i dont see an issue with 289. In quakespasm i get the gravity problem or when going up a lift it damage happens to health. 
@2697 
Boris,

You could try this workflow for your purposes.

The following link details a DOS compilation of super8. I'm not sure how recent it is, however it may support modern map limits and features.

http://www.vogons.org/viewtopic.php?f=24&t=39878

If you don't have a DOS machine, you could try running it from DOSBOX or similar emulator or VM to achieve your desired results.

Good luck! 
Re: Scaling 
I am game to implement this - it shouldn't be much work, and it fits well with the "vid_desktopfullscreen" feature we've had for a while (If you set this to 1, the vid_width/vid_height cvars are ignored when you go fullscreen, it just uses you desktop res.) Another reason to do it is, one of my test machines (Linux) doesn't offer any fullscreen modes besides the native LCD res.

How does this sound, new cvars r_width/r_height, which default to 0 (use window size), but if you set them to something else like 320/240, Quake would render at that given resolution and then get scaled to the window size.

The remaining questions are, if you render to 4:3 but have a 16:9 window, should it be letterboxed or stretched, and should the stretching be always nearest-neighbour or respect gl_texturemode? I am thinking always letterbox rather than stretch if the aspect ratios differ, and always nearest for now? 
 
Off the top of my head, if I was doing this I'd repurpose the old vid_stretch_by_2 cvar and retain the aspect ratio. 
 
"The remaining questions are, if you render to 4:3 but have a 16:9 window, should it be letterboxed or stretched"

Imo horizontal letter box is the best option, stretching looks bad. Setting resolution to 320x240 (4:3) and then stretching it to 16:9, defeat the purpose. I guess someone who wants to play in 16:9 in super low resolution will set it to 320:180 anyway. 
640x360 
would probably be a better resolution. 180 pixels tall is way too low res tbh 
#2704 
Yeah, I just thrown this as an example.
I think hardware-wise minimum resolution available in modern cards is 640x480, so it will be scaled to closest minimum anyway (or to whatever resolution you have), so you could go with any resol