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. 

Quakespasm has game controller support, you might check that out.

In the future when the day comes that I can work on the engine more, I expect to try to get the joystick control working perfectly. PFL earlier in the thread posted joystick settings that he used. (My response was I'm glad it worked, since I don't have a joystick at the present time). 

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

I'm not using any command line switches (other than setting resolution). I can run Quakespasm just by itself and still no Contrast adjustment (same with the Quakespasm-sdl2.exe). I tried adding the -fitz switch, and that didn't help either (although then the demos play, when they normally don't in Quakespasm).


"I think ring of shadows hue is too dark. "

Yes, I agree. How about a console variable to adjust that?


I cannot get monster skins to work in Quakespasm.... They work fine in Mark V, and all other textures work in Quakespasm, such as walls, items, and weapons. Just not the monsters, no matter where I put the textures, like:

ID1/progs/ogre.mdl_0.tga
ID1/textures/ogre.mdl_0.tga
FVF/progs/ogre.mdl_0.tga
FVF/textures/ogre.mdl_0.tga

And I even tried the Qrack format ogre_0.png in various locations, just to be sure.

But the ogre stays ugly. Well, I mean... low-resolution ugly as opposed to high-resolution ugly. *shrug* I don't care enough to keep trying to make it work 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!

Some of legacy GLQuake code in Quakespasm interferes with modern operating systems, preventing users from applying external skins to MDL files. To fix this, you need to go into your C:/Windows directory and delete system32. 

Quakespasm doesn't have external texture support for models. Just maps.

In preferences there is an option to lighten the view blends, the ring of shadows falls in that category. Otherwise you have to play with gl_polyblend or r_polyblend or whatever the name is. 

The reason the contrast slider wasn't working is it requres GL2.0+, which the intel 945 doesn't support.
Thanks for all the feedback! 

I didn't adjust the translucency and soft depth levels to match Qmaster's suggestion, though.

It should look even better with translucency, because it's multi-layered. 

Ah, gl_polyblend is something I can mess with, though I really would like to be able to adjust only the ring blend, and not ALL the blends, because I think the others are ok. If I turn the ringblend down to where I think it looks good, then all the other blends look way too light. I guess I will settle for just toning it down a hair to 0.9, which doesn't lighten anything else too much....

I've also noticed that Mark V allows standard chat behavior during the "level end" scoreboard (i.e., you can still see the chat lines on the screen, and additionally if you are typing as the level transitions, it stays on screen too). Nice touch. This is an old old Quake bug that I hadn't seen anyone else deal with. And we do like to continue chatting in FvF while we dance at the end of a level ;)


On the bad side, I seem to be experiencing a few crashes on level transition both online and offline.... That's gonna be hard to debug on my end unless Mark V can generate error logs. But it seems like it possibly happens more often on certain maps. I'll keep notes on this....

Also, sometimes, when lots of stuff is flying around (especially lightning), I get "warning: 150 tempentities exceeds standard limit of 64." I don't think there's a need for users to see that warning, is there? It's fine as a debug message, but not something the end user needs to see.

And the shadows in DX Mark V are... uh... well, they look like ProQuake shadows where it's like you can see the folds inside the model casting varying intensity shadows -- the shadows don't look solid. In the older GL versions of Mark V, the shadows were a uniform color/transparency.


And just an interesting thing to note: I found out what was causing DX Mark V to run really badly in a window when I first tried it (but fine in fullscreen). I have a little program running that sits in the corner of my screen and shows the network traffic. It's called BitMeter 2. When that is on my screen and DX Mark V is running in a window, my FPS goet to like 6. As soon as I hide the little BitMeter display, my FPS smoooths out dramatically.... It doesn't effect the GL Quake clients I've used, though I have had videos get unsmooth when I try to watch them full screen if I had BitMeter displaying as well.... *shrug* 

baker: i finally got a chance to look at the fitzquake 085 code, it appears that without texture_env_combine, you still can get alpha blending but what you lose is overbright lighting. 

Retroquad doesn't support overdraw between surfaces with the same kind of liquid in the same entity, because in most cases that would be just a waste of framerate. In maps with molten mapping enabled and compiled with lit liquids, that would be a framerate killer.

But I agree that multiple layers of translucent surfaces may give a better fog impression. The lava in some AD maps (playing with QuakeSpasm, as my engine can't run it) looks more like plasma to me due to this.

(Sorry for the off-topic, Baker.) 

@gunter: By the way, in Mark V...

* You can paste text into what you type in a "say" message (messagemode2).
* You can paste text anywhere text input is accepted. In fact, if you hold down shift and select text in the console, you can press CTRL-C and copy text.
* You can also type "copy" in the console and copy the contents of the console to the clipboard.

DX wrapper doesn't have stencil, so can't do stencil shadows. Those smooth shadows are stencil shadows. But even those shadows don't clip. DarkPlaces is the only engine that renders player shadows properly on multiple surfaces that clip.

Warnings. Standard FitzQuake 0.85 printing warnings. But I've seen it confuse more than 1 person. Quakespasm made those only print with developer 1.

Its to help mappers know they are making a map that isn't standard Quake compatible (it won't be playable in Quakeworld like ezQuake, nor playable in GLQuake, etc.)

The DOPA release by Machine Games a couple of months ago is an example of a episode that is actually all-Quake compatible.

@metlslime: Didn't have enough time to check the .bsp code to see what alpha brushes rendered ok. Sounds like you are saying that I would have discovered no overbrighting on those when combine isn't available when I did look. In the future, I probably mimic that path for models with translucency to resolve lack of transparent gun rendering in DX version.

(@mk - it's not off-topic at all. Software renderers matter too!) 

Hm, so if you can't make stencil shadows in DX, how about making the shadows completely black? Perhaps the r_shadows variable could work like wateralpha, and set the transparency level of the shadow. 0.5 might be the standard setting, but a setting of 1 would be a solid black shadow, which would look better than the weird shadows of varying thickness in DX.


I found that setting "noclip 1" caused the HUD area to turn grey. It sometimes flashes back to the HID when other effects are happening.

I tried playing a demo that someone recorded (I believe in Qrack) and it was constantly spamming the console with everyone's pings. I played the same demo in Proquake and it didn't do that. I played my autodemos from Mark V, and they also did not do that in Mark V. So I tried recording a couple demos in Qrack myself (not sure what version of Qrack I have), and they wouldn't play at all in Mark V, and one of them caused Mark V to crash. I tried the same demos in ProQuake, and it also crashed, but it popped up an error message first, "sv_lightstyle > MAX_LIGHTSTYLES"



A possible suggestion: how about overlaying the standard Quake sky over the skyboxes using the skyalpha to make it mostly transparent? Then you'd still have transparent moving clouds in front of the skybox.... Maybe just the first layer of clouds, and make the second layer completely invisible or something. 

I'd be curious to see how Gunter's multi-layered sky would look. 

That would be neat! Best of both worlds. Vanilla skies lack realism and skyboxes are pretty but completely static. Both are slightly annoying in their own way, but if we could mix them... w00t! 

Update...

I reported before, the "Invisibility - Draw Weapon" option that makes your weapon model transparent did not seem to work in DX Mark V, leaving the weapon fully solid.

But I just found that if "external_textures 1" is set, it DOES work, and my weapon model is transparent!