That's interesting, i don't remember whether i added that support or not (but i would have assumed i did.) There is this comment in the readme:

- fullbrights now use additive blending instead of alpha blending. This allows me to support external glowmaps, and entity transparency with fullbrights/glowmaps. In some cases, additive fullbrights are rendered using multitexture, but only if GL_EXT_texture_env_add is available. The command line option -nocombine will disable the use of GL_EXT_texture_env_add.

This implies that without combine, models with fullbright masks are rendered in two passes. It doesn't say that they are rendered correctly with alpha though... hmm. 

It is probably a virtually non-existent situation.

I've not seen an instance of someone using .alpha on an alias model in a single player release. And there probably aren't any Open GL drivers that don't support combine.

It's just that the Direct3D wrapper doesn't have combine ability written in the code and that Mark V offers a "gun with transparency" option when invisible, instead of Quake not drawing the gun at all.

/But the brush models don't suffer this problem in the Direct 3D + no combine scenario (I tested against back2forwards which uses .alpha for glass). So at some future date when I have time to chart out the rendering, I should be able to rewire something --- assuming I would do that instead of maybe taking a shot at adding combine to the Direct3D wrapper. 

(Actually, thinking about that --- Nehahra does .alpha on wraiths and Mark V runs Nehahra.) 

the sparks in rubicon2 fade out using alpha (they are models) 

Hehehe, never noticed that. I only noticed the laser barrier bars and such used .alpha. 

Torch flames in sock's maps usually (always?) have alpha as well. Any maps using Preach's smoke model. 

I did proper animated fog once. It used world position and a function of time to do a lookup in a 3D noise texture which was then used to adjust the opacity. It looked beautiful but the performance hit was just on the wrong side of what I considered acceptable.

Totally irrelevant to the ongoing fog discussion, of course, but it was fun. 

While we're mentioning fog, faint transparent water with a more subtle texture could make for neat looking fog, especially if combined with mankrip's shore fading. 

Contract Revoked used this trick, IIRC. 

Didn't have fog. 

dwere was probably talking about this. I didn't adjust the translucency and soft depth levels to match Qmaster's suggestion, though. 

Ok, you asked for it Baker, so here is my review of Quakespasm. Much of this will be personal preference, and other stuff will be comparisons to Mark V.

I mentioned that Quakespasm is off-putting to me. This starts with the website (I talked about that long ago, way upthread). I do note the addition of a clear "readme" link on the site, and that's a definite improvement, because when I go to try and download something like this, I want specific information rather than the vague artsy presentation which just gets in the way....

The second off-putting thing to me was all the files Quakespasm wants to drop into my Quake directory.... My goodness, that's a lot of files. 12 DLLs, a PAK file, 3 TXT files and an HTML... along with the 2 EXEs. What a lot of clutter.

The third major hurdle was that r_oldwater defaulting to 0, which caused my frame rate to be like 5-10 on the Start map.

Finally, there's the difficulty in finding what settings are available, such as all the various console variables, like the one above -- there's no good documentation. I would have never known to try that to fix my issue.

So yeah, with all those issues, I was like, "Forget this..." and I'd move on to something else.


But I will say, once past all that, Quakespasm is a really nice engine. It may even run a bit smoother in places as compared to Mark V. Well, I am stuck with the DX version of Mark V now, since the newer GL ones just crash for me... so... that may make a difference. The fog certainly looks better in Quakespasm as compared to DX Mark V (but that's also true of GL Mark V vs DX).


My first point of feedback would be that the r_oldwater setting should really default to 1... since it seems to be such a power-hungry effect to have active (in my case any way). I tried enabling it in Mark V, and got the same result -- baaaaaad FPS. But Mark V has r_oldwater 1 by default.

In the menu, I really like the "Scale" slider. Very nice. I had to set up keys in Mark V to achieve the same effect by altering 3 different console variables. The nice slider seems to adjust everything at once (that's definitely something Mark V should add).

The "instant Quit" upon selecting Quit from the menu. Hm, not sure how I feel abut that. I don't love it but I don't hate it. The new Console background is the same type of thing -- not sure if I like it or not, but FvF has its own console replacement anyway, which still looks close to the original Quake one, so it doesn't matter much.

Hey, the "Always Run" menu option is a definite improvement in the way it functions. In most Quake clients (like Mark V), having "Always Run" on seems to place more emphasis on your forward movement, causing the side-stepping movement to be way too slow (when you gotta side-step to get out of the way of a rocket, you want to sidestep FAST!). The way Quakespasm implemented it seems to instead function just like a run key (+speed), which places emphasis on your side-stepping speed while only slowing your forward speed down a little (there's still an overall speed limit you can't pass when moving "diagonally"). Even better, when "Always Run" is enabled, your usual +speed key acts to slow you back to normal walking speed. That's a nice touch (Baker, Mark V needs all of this! :D ).

Uh, where's the clock ? The usual clock in DM mode is MIA. Is there a console variable to enable it? But watch out that it doesn't overlay the "player squares" that appear where the clock would normally be -- just limit the number of those "squares" that appear there.

Also, there are no pings by the scoreboard when you press tab while playing online. That's a pretty common feature, and pretty much expected these days.

Speaking of the scoreboard (and all other things that are printed in the center of the screen, like centerprints and "loading" images), the ProQuake method of positioning all these things near the top of the screen is the best way to go. Then they don't block your view in the middle of the screen. Every modern Quake client should be imitating Proquake in this respect. EVERY MODERN QUAKE CLIENT, Baker :D


(continued below, because maximum character count is only 5000, haha) 

Wow, MP3s load fast! I guess some of those DLLs are doing their job. The MP3s seem to load with no delay at all. My gosh, Mark V takes like 10 seconds to load an MP3 track (all the while your game is frozen). Can we get this in Mark V? Like, seriously. I won't even complain if it will require some extra DLLs!
Though it seems the menu option to enable/disable external sounds does not take effect until level change (Mark V enables/disables the music right away. Well, after the loading delay, that is).

Speaking of those DLLs, I don't suppose they would go into the PAK file to make them more tidy? Probably not, eh? Well, the next best option would be to move all the Quakespasm-related files (DLLs and PAK) into a Quakespasm folder within the Quake folder (this is like how Qrack does it).... Quakespasm would still know where to find them, and they would be out of the way. I think this would be a significant improvement.

Is there a way to toggle high-quality textures on and off? Mark V has external_textures to toggle.... I like to be able to turn them on and off in game, to make comparisons and to test loading time. There doesn't seem to be a way to turn them off at all in Quakespasm?

And... how do I get high-quality monster textures to work? I tried them in Qrack format (png), I tried them in Mark V format (tga), I tried them in various locations (progs folder or textures folder), but they don't show up. Documentation, please!

I do note that the high-quality wall textures load correctly in my modified dm6 (it's got some small extra areas added to the standard DM6 map). For some reason, Mark V does not load the custom textures in it, and reverts back to the standard textures for the map.


Speaking of my modified DM6 and Mark V (and this is really a Mark V bug report, but I'm on a roll), for some weird reason, when I run FvF and go to start a new Single Player game, I am dropped into my DM6 at a DM spawn point (I did add SP spawn points to the map) instead of the Start map! What's up with that? No other engine does that (including Quakespasm or older Fitzquake Mark V or Proquake....). Some weird interaction of Mark V and FvF, or the modified DM6? It's not really important, because FvF doesn't actually have a single player mode... It's just weird.


gl_overbright_models does not look good for me. Makes the Quake solder way too washed out when he's standing in a bright area, especially if he's wearing white. Same in Mark V. I just disable it.

I like that r_wateralpha controls all the liquids by default. In recent Mark V, it seems each setting must be made separately (like r_lavaalpha). This appears to be a result of Quakespasm using defaults of 0 for like r_lavaalpha, and also allowing the r_wateralpha to affect all liquids. That's a much better way of handling it, which still allows fine-tuning of separate liquids if desired. Mark V could benefit from this.

Hey, the "under lava" blend looks perfect, right out of the box in Quakespasm. Has the intensity of it been changed? Quakespasm doesn't seem to have the ability to alter it manually.... Good thing it looks perfect as-is! But I'm curious as to why it does, when it looks so blinding in Mark V at the default Quake values.

Models with missing skins come up as white in Quakespasm. This is old GLquake behavior, but it should really be handled like Winquake does, by using the default texture. For example, if a monster or projectile has multiple skins for a mod (FvF does this a lot), but the client does not have those skins installed -- so the like mod is assigning skin_1 or skin_2 to a model, but if the client doesn't have them he should just see the default skin_0 for that model. Mark V does show the default skin in these cases.

Hm, scr_showfps doesn't stay set for the next time you start Quakespasm.... That seems to be standard behavior for Quake clients, but this seems like one of the settings that should be stuck in the cfg file and saved.


(continued) 

Keeping in mind I'm running on a netbook with a resolution of 1280x600,
If I set Quakespasm to a 800x600 window, the actual space inside the window (game area) is 600 tall, but the title bar and border extend farther.
In Mark V (and Proquake, etc), the entire window (including title bar and border), is 600 tall.
This means that in Quakespam, there would be a tiny portion of the screen cut off at the bottom of my actual screen, because I can't move the top of the window all the way off the top of the screen.
I'm not really saying one way is more correct (though the standard, I think, is that the 800x600 defines the dimensions of the entire window, including borders).
So I end up setting my window to a weird size so it all fits my screen, 750x550 (I've used this with Mark V and Proquake sometimes too), but when I do that, Quakespasm's color depth is locked at 16 bpp and can't be changed in the menu.
If I go back to an 800x600 window, the color depth is again changeable in Quakespasm's settings, though I really can't tell any difference at all in the graphics when I change it (in full-screen or window). My desktop is set at 32 bit color. I don't have any real issues with any of this -- I'm just reporting my findings, heh.

I do have a slight issue that the Contrast slider does not do anything for me (no matter the BPP or full-screen/window settings)... so the Brightness slider is my only option for adjusting things, and that tends to make colors less vibrant. Mark V's Contrast slider works fine for me.

The weapon model is too low. I guess that's the Fitzquake default.... Mark V allows (and defaults to) the Proquake way of showing the weapon, which makes it less hidden at the bottom. Well, normally Quakespasm hides the weapon behind the transparent HUD anyway, but I like to set my HUD to opaque. And I like to see more of my gun.

While on that topic, the Mark V "transparent weapon when invisible" is a nice option Quakespasm could use.

Demos don't load at all upon startup? Is there an option for that?

The r_noshadow_list has same problems as Fitzquake: There is no bolt1.mdl in Quake. That should be bolt.mdl. Baker did add bolt.mdl to Mark V, but he forgot to remove the bolt1.mdl. Also, k_spike.mdl (the Death Knight fireball attack) and lavaball.mdl really should be added to the list, as they are glowing things that should not be casting shadows.

Hm, I miss the stain maps from Mark V....

And I would suggest adding Proquake's RCON function to Quakespasm (as Baker did for Mark V -- thanks!!). It is extremely useful to be able to admin a Proquake server while I'm connected and playing. This is a pretty big criteria for me when selecting a Quake client, though it may not matter at all for most people.

And of course I always suggest adding support for Colors 14/15. Heh, They are in Quake... it's just that the client doesn't allow them to be selected. I think it's an easy thing to modify (later versions of ProQuake have it).


I guess in the end Quakespasm and Mark V are pretty close, with each having pros and cons compared to the other.... 

In most Quake clients (like Mark V), having "Always Run" on seems to place more emphasis on your forward movement, causing the side-stepping movement to be way too slow (when you gotta side-step to get out of the way of a rocket, you want to sidestep FAST!).

Apparently, your mod uses a slow default for cl_sidespeed.

The actual Quake default was always somewhere around the max speed, making strafing very fast regardless of autorun. I don't know why they set it up like this, but my guess is it was an attempt to assist keyboard-only players in dodging.

The result is that the autorun toggler in the menu most likely just ignores cl_sidespeed and only affects cl_forwardspeed and cl_backspeed. 

re: mp3 loading speed slower in Mark V

Quakespasm uses a software library for media playback, Mark V uses Windows hardware accelerated playback. On the computers I have tried Mark V on (probably around 20), it typically loads instantly. I think it stop/pause/restart instantly, but Quakespasm can't.

The software library Quakespasm uses is more reliable because it isn't subject to Windows settings or Windows .dlls, but uses more CPU.

/Mark V is a "pure client", it doesn't use 3rd libraries (that's why doesn't need .dlls). Quakespasm uses SDL2. Spike statically linked Quakespasm-Spike, so it doesn't need dlls and the library instructions are rolled into the .exe.

Quakespasm contrast not working

Quakespasm contrast not working is probably the result of one the command line options required to make Quakespasm run on your netbook. Try removing one of those command line options and see if it runs.

Quakespasm it uses a shader for brightness/contrast, it only affects the Quake window --- not the entire desktop.

Mark V by default uses the Windows API, but it affects the fullscreen so in windowed mode the rest of the desktop screen is affected by your brightness settings --- but it has no effect on frames per second or cpu usage (it's free).

r_lavaalpha etc

Hehe, ericw/Quakespasm did a push to get different transparent level for different liquids. Hence the feature in Mark V.

Quake defaults

AFAIK, Mark V uses 100% Quake defaults and 100% Quake behaviors with minor exceptions (mouse look defaults on).

I don't like all the defaults, I think ring of shadows hue is too dark.

You might not like how standard Quake "always run" is less than perfect, but I'm seeking to exactly mirror GLQuake/WinQuake/FitzQuake in behavior.

External textures

You must use the DarkPlaces texture naming convention. They must be in .tga format.

Mark V recognizes
(1) one format --- it's TGA
(2) one folder for things to go -- the DarkPlaces location
(3) one naming format -- the DarkPlaces one

DarkPlaces Examples:

progs/backpack.mdl_0.tga
progs/spike.mdl_0.tga
progs/armor.mdl_0.tga // green skin
progs/armor.mdl_1.tga // yellow skin
progs/armor.mdl_2.tga // red skin

I don't care about the Qrack place/name --- DarkPlaces is the engine that people make skins for. Everyone should use the DarkPlaces name/format *and* only the DarkPlaces name/format. The naming convention Qrack uses for skins comes from the FuhQuake Quakeworld client, which provides no naming convention for sprites. The Qrack naming conventon is flawed. 

The FuhQuake texture naming convention not only has a bad naming convention, it stuff like specific folder names for different models. Qrack uses the same, as does ezQuake.

It's insane.

Poor FTE (Spike's engine obv) obviously caters to people familiar with ezQuake and he has check for textures in like 16 different places in some cases. It's slowish and can add to load time (think of a map with 160 textures) and then multiply by supported graphics formats and then how a file can be in a pak or not.

So the rogue FuhQuake/ezQuake/Qrack naming convention is not only slow -- and not only confusing to users --- but the code looks like spaghetti.

The other problem is if you are a user, how are you going to find the texture if it could be in so many different places.

It's crazy

/Mini-rant, but DarkPlaces naming convention injects 2 forms of minimalistic sanity! 

No, there's definitely some different behavior when using +speed vs using "Always Run" in default Quake. Try it in most any Quake client, such as Proquake or Mark V.

Default cl_forwardspeed is 200
cl_sidespeed is 350

Setting "Always Run" just sets the cl_forwardspeed to 400, leaving cl_sidespeed at 350

But using this setting, try going to the Easy hall on the Start map. Back up into the corner of the wall and the step (so the health box is behind you), and press Forward + Right. You will barely make it to the "corner" of the wall and the metallic column thing at the end of the hall, before you hit the right wall.

Now disable Always Run and either set +speed in the console, or assign a Run button like Shift, and hold that down.

Repeat the exercise above.... You will easily make it to the right wall in half the time, and if you quickly reverse direction to the Left, you will even hit the left wall before leaving the hall area.


I believe I understand why this happens now!

When you use +speed, all your speeds are doubled, so the values are effectively changed to:

cl_forwardspeed 400
cl_sidespeed 700

Now, 700 is obviously faster than the speed limit, so you expect it to be stopped at 400 by the server, and that's true.

However, that 700 number places EMPHASIS or priority on your side speed over the forward speed -- maybe the server calculates where you WOULD be if you were moving by those values, but only allows you to move a max of 400 toward that point.

Now, if you use "Always Run" that only sets your cl_forwardspeed to 400, leaving cl_sidspeed at 350... which would produce a completely different calculation for where you WOULD be if you could moved at those values.... Further, if you then press the +speed button, it will not affect where you end up because both the numbers would be doubled, to 800 and 700, which would be the same comparative amount of movement in each direction.

However, if you go in and manually set cl_sidespeed to 700, then you're back to moving just like +speed, with fast side movement, even with "Always Run" enabled.


So in short, "Always Run" de-emphasizes your sidestepping speed by not doubling, while +speed increases your sidestepping speed by the same proportion as your forward speed, allowing your sidestepping to remain nice and fast.


The fix: Make "Always Run" also set cl_sidespeed to 700 along with setting cl_forwardspeed (and cl_backspeed) to 400.

Then the movement ratio stays the same. 

Spike statically linked Quakespasm-Spike
No, I didn't. I just didn't include any dlls - the target audience will have them already.
I meant for it to be a patch rather than a fork, so I didn't see the point in making the zip huge.

FTE's texture loading code looks like spagetti because its designed to act like it, and by that I mean it supports both threads and filesystem caching.
This makes it _much_ faster to load stuff than DP.
And that's despite it trying about 125 different paths (ignoring the multiple extra gamedirs) for each individual texure last time I checked (that count doesn't include lumas/gloss/normals/bumps).
But yes, DP is consistent yet strict. Its a good choice as the favoured path to try first - unless of course the texturs in that path were completely flat with the expectation of bumpmaps providing all the depth, in which case they'll look terrible without rtlights.
So yeah, hurrah for fuhquake's naming convention! 

The above reply was to dwere ^


In regard to what Baker said about it, I don't have a problem with sticking to Quake's default behavior for "Always Run," however in that case you should stick to Quake's default behavior and leave "Always Run" DISABLED by default. Of course, I dislike it and won't use it (for the reasons mentioned above), and can set up my config in an alternate way, but with it defaulted to ON, when I'm setting up new configs, it requires toggling the menu option to disable it -- there's no console command to disable it, right? 

Gunter, I agree intellectually with what you say.

But I do things from the perspective of the standard existing behavior so the users gets what they expect and have always known.

(1) Power users like you know how to edit your config.
(2) Some users who just want to play they game and it be like what they've always known.

They aren't necessarily power users and if you change things on them, they get confused.

@spike -- Interesting stuff. I thought you statically linked it like what imagine do with FTE. I know SDL2 can be statically linked in MinGW. 

Of course, I dislike it and won't use it (for the reasons mentioned above), and can set up my config in an alternate way, but with it defaulted to ON, when I'm setting up new configs, it requires toggling the menu option to disable it -- there's no console command to disable it, right?

There's no single console command, but a bunch of variables. You can set them however you want, and safely ignore what's written in the menu. The engine wasn't taught to detect your custom settings, so it just assumes one of the two conditions (autorun on/off) based on some of these variables (most likely just one of them).

The variables are:

cl_forwardspeed
cl_backspeed
cl_sidespeed
cl_upspeed (swimming/flying up and down)
cl_movespeedkey (multiplies the above speeds when +speed) 

Hm, considering it more, I really think this is an error or oversight in the original Quake code that has gone unfixed for a long time (actually, Quakespasm has fixed it!), and it really should be fixed in modern clients.

An illustration:

Default diagonal walking speed has you to move 2 steps forward and 3.5 steps to the side (200 and 350 are the actual settings).

So imagine a line starting at the lower . and ending at the top right .
Just go ahead and draw a line on your monitor with a marker to connect the dots :D

21.2.3.
.
1
.

That shows your line of motion -- the direction you will be traveling.

If you "run" using a Run key (+speed), those steps are both doubled, so you will be trying to take 4 steps forward and 7 steps to the side.
Imagine your line of moment now starting at the lower . and ending at the 7

41.2.3.4.5.6.7
.
3
.
2
.
1
.

You can see it is the same line of movement -- it just travels twice as far. Of course, you won't make it that whole distance, because there is an absolute speed limit, but you will still be traveling along the exact same line in the same direction as before until you hit the speed limit.



Now with "Always Run" ONLY modifying your forward speed, you will be taking 4 steps forward and 3.5 steps to the side, which greatly alters your line of travel. Now you are traveling from the lower . to the upper . again


41.2.3.
.
3
.
2
.
1
.


Completely different line of movement, and your sidestep speed suffers greatly.


The total distance you end up moving will be the same (the absolute speed limit) but your position will be different because you are moving along a different line in each case....

I believe the first line of movement is the correct intention for Quake, since it applies to the default walking or running methods.

I think with the "Always Run" menu option, they simply overlooked that it was supposed to also apply to the sidestep speed, which IS supposed to be doubled along with the other speeds when running. 

(1) A menu is to satisfy the basic needs of the average user.

(2) A config is to satisfy specialized needs, preferences or interests. 

Getting back to other bug reports, Joystick support seems to be broken in the latest Mark V, though it seems to work fine in my older version mark_v_e.

It says Joystick detected, and joystick 1 is set in the console, but no input is detected.