@spike also -- while I'm thinking about this -- your single port rewire of reading messages -- I haven't investigated so is probably non-issue, but in my head I was thinking "make sure that can't skip a player impulse". I think QSS queues up +jump and such.

/Again, haven't had time to focused on deep examination of that, so quite possible I'd see something obvious that I'm not thinking of at the moment. 

I have no audio crackling / distortion, everything sounds fine for me.

Those who are having glitched audio, might help track down the problem if you type 'condump', and paste this section from your id1/condump.txt:
Sound Initialization
Set primary sound buffer format: yes
Using secondary sound buffer
2 channel(s)
16 bits/sample
11025 bytes/sec
DirectSound initialized
Audio: 16 bit, stereo, 11025 Hz
Sound sampling rate: 11025

Also - congrats on the release, Baker :) 

Thanks ericw! At more than one point, didn't think it would ever happen. 

qss's single-socket stuff just switches from looping through each connection and then handling the messages to checking the socket(s - ipv4+ipv6+ipx) and then parsing them within the context of the player with the same remote address.
there's no extra buffering there that wasn't already there, certainly not in the client-side stuff. inputs are handled the same way as they always were.

if you're getting crackles mid-sound then rewrite your resampler. resampling 44->48khz will probably screw up the waveform if you have 44khz frequencies. most people can't hear those anyway.
be aware that the vanilla resampler uses 'nearest filtering', which has somewhat obvious deficiencies...
on the other hand, pops when you override another sound could be fixed with a gradual fade-out instead of suddenly dropping down to 0. 

Count me as another person who is very glad this release happened, and it happened now instead of later in 2017!


"gun fov 90 -- people love the feature"

Well, people love lots of things, but that doesn't mean Quake's default should change, heh. I mean, lots of people probably love r_viewmodel_ring 1, but it's defaulted off....

From looking at the old thread, the people who are using r_viewmodel_fov are not using your default value anyway.... They are using 110 or 130.

And of course, they are using it when setting a higher fov. It's good for that. I like it for that too. Too bad it doesn't work ONLY for that.... Lower fov's make it weird.

So yeah, I'll disable it. I have a section in my fitzquake.cfg file for "Restore Quake Defaults." The section is actually not too long (about 7 behaviors), which is a very good thing. But I'd be more happy if it was completely unnecessary to restore any Quake defaults!

Now, it's not always bad to change a default, but you have to be certain there is definitely no negative impact from the change.

For example, I couldn't see any negative impact of defaulting r_viewmodel_ring 1. It's a cool setting, and everyone should use it... but I would never actually argue for making it a default... because it's not Quake's default! Heh. But of course, I would't mind if it was made default either, unless some unforeseen negative impact arose.

Of course, sometimes the "negative impact" is simply that it doesn't look the way people are used to, and they don't like that... sooo... in the end (as you say), you gotta be really conservative about changing defaults. Err on the side of caution. 

In this engine, one thing I've tried to do is absorb as much of the feature set from other engines with great contributions that aren't developed any longer like Enhanced GLQuake/WinQuake, ProQuake, JoeQuake.

But it is currently lacking one of the most prominent features of JoeQuake as an option (will off by default), which are the optional particle effects system (QMB particle system by Dr. Labman).

It'll need some rigorous testing when it's available in a few hours. 

Rigorous is my middle name.


Well, not literally. That would require some really weird parents.... 

Here you go! This is with me changing sndspeed to 44100

Sound Initialization
Set primary sound buffer format: yes
Using secondary sound buffer
2 channel(s)
16 bits/sample
44100 bytes/sec
DirectSound initialized
Audio: 16 bit, stereo, 44100 Hz
Sound sampling rate: 44100 

Oops, and here is QS:

Sound Initialization
SDL audio spec : 44100 Hz, 1024 samples, 2 channels
SDL audio driver: dsound, 65536 bytes buffer
Audio: 16 bit, stereo, 44100 Hz 

Is there any feature left in ProQuake still that hasn't been subsumed by Mark V? 

I'm just going off current memory.

ProQuake + JoeQuake in Mark V
------------------
1) Ping in scoreboard.
2) ProQuake enhanced client
3) ProQuake enhanced server *limited* to Spiked Quakespasm levels due to acquiring QSS single port server capability.
4) ProQuake 16-bit aim available under protocol 15. (Spiked Quakespasm has this too).

ProQuake
--------
1) Mark V downloads depot http download missing maps, sounds, models when connected to ProQuake or DarkPlaces server, but not when a Mark V server or Spiked Quakespasm server.

(* because Mark V is likely to have in the future peer-to-peer TCP/IP transfer of "gamepacks" -- think "travail.zip" due to conversations with Spike on how to do download right. On a LAN in particular, transferring "travail.zip" (83 MB) happens in the blink of an eye. Since Spike has already written .pk3 support for QSS, and since .zip and .pk3 are same thing ... it is also likely in future Mark V will never decompress a Quaddicted download at all.)

And has all other ProQuake features except ..

2) Does not have ProQuake iplogging (check to see someone if someone is imposter). Not compatible with IPv6.
3) Cannot run ProQuake QCCX mods.
4) Typing matrix in console displays a Matrix movie full screen character effect.

JoeQuake
--------
1) Mark V has .dz playback built-in even on Mac, does not require any extra dzip.exe or anything. (Speed Demos Archive speed runs)
2) Mark V Has scr_showspeed - display speed on screen.
3) Will have QMB particle system tonight
4) Doesn't have cl_bobbing (items can bounce up and down)

Enhanced GLQuake/WinQuake
-------------------------
1) Mark V should be able to play Q-Rally with sv_gameplayfix_setmodelrealbox 0. Maybe other rare (Spike says poorly coded) old stuff that needs it.
2) Mark V can read protocol 10002, allowing Mark V to play Warpspasm start demos.
3) Mark V, developer 2 displays extra warnings from that engine.
4) Mark V does not support 32 or 64 player scoreboard.
5) Mark V does support sprite32, even in WinQuake version.
6) Obv, Mark V can play Nehahra.
7) Mark V, unlike other FitzQuake forks except Spiked Quakespasm, can serve protocol 15 game. 

I really like the manipulation of console variables via mul, valsave, valload....

Here are my newly Mark V-enhanced zoom aliases, for anyone who wants to try them.

The mouse wheel zoom is my favorite -- you can zoom in and out to different levels (even out to chase mode) with the mouse wheel. I've used it for a long time, but now it is better due to being able to save any fov before messing with it, and use math to change the sensitivity. If someone wanted to expand on this, you could make even more zoom steps, or even more zoom steps backward in chase mode with chase_back values.

(to use these, you'd want to paste them in a .cfg file to exec)


// mouse wheel zoom

alias zoom_out_full "mul sensitivity 2; bind mwheelup zoom_in_half; bind mwheeldown zoom_back; fov 50;wait;fov 70;wait;valload fov 1"
alias zoom_out_half "mul sensitivity 2; bind mwheelup zoom_in_full; bind mwheeldown zoom_out_full; fov 20;wait;fov 30"

alias zoom_in_half "mul sensitivity 0.5; bind mwheelup zoom_in_full; bind mwheeldown zoom_out_full; valsave fov 1;fov 70;wait;fov 50;wait;fov 30"
alias zoom_in_full "mul sensitivity 0.5; bind mwheelup wait; bind mwheeldown zoom_out_half; fov 20;wait;fov 10"

alias zoom_back "chase_active 1; bind mwheelup zoom_standard; bind mwheeldown wait"
alias zoom_standard "chase_active 0; bind mwheelup zoom_in_half; bind mwheeldown zoom_back"

zoom_standard




Here is a single-key solution that still allows different zoom levels. Sometimes you may not want to zoom in ALL the way, right up the monster's nose. With this you get an alternating zoom level each time you press the key.


// single-key multi zoom

alias rekey1 "bind r +zoom1"
alias rekey2 "bind r +zoom2"
alias +zoom1 "mul sensitivity 0.5; valsave fov 1; fov 70;wait;fov 50;wait;fov 30"
alias -zoom1 "mul sensitivity 2; fov 50;wait;fov 70;wait;valload fov 1; rekey2"
alias +zoom2 "mul sensitivity 0.25; fov 70;wait;fov 50;wait;fov 30;wait;fov 20;wait;fov 10"
alias -zoom2 "mul sensitivity 4; fov 20;wait;fov 30;wait;fov 50;wait;fov 70;wait;valload fov 1; rekey1"

rekey1





Baker, your +zoom_key alias is rather non-optimized. There is no need to change the sensitivity with each step of the zoom (it all happens so fast, only the beginning and end sensitivity matters). And actually there's no need to save and load the sensitivity value at all -- you can just use the math to change it and restore it (X * 0.1 * 10 = original value).

And there's really no need to use math on the fov for each middle step of the zoom either -- those steps are just there to provide an animation for the zoom effect, so they work fine at set values. Again, only the beginning and end values are important.

So if I may, this would be a much cleaner, optimized version of your +zoom_key:

alias +zoom_key "valsave fov 1; valsave r_viewmodel_fov 3; r_viewmodel_fov 0; mul sensitivity 0.1; fov 70; wait; fov 50; wait; fov 30; wait; fov 20; wait; fov 10"

alias -zoom_key "fov 20; wait; fov 30; wait; fov 50; wait; fov 70; wait; valload fov 1; valload r_viewmodel_fov 3; mul sensitivity 10" 

1) Mark V does have ProQuake/JoeQuake/DarkPlaces bestweapon command .. bind x "bestweapon 8 5 4 3 2 1" ... will select best gun with ammo available.

2) Does not support pq_moveup (swim up as fast +moveup).

3) No ProQuake 4.93 server browser pressing F5, but instead Spiked Quakespasm server browser.

/Shorter version: For various reasons, Mark V won't likely appeal to most ProQuake users and almost all of them would probably stick with ProQuake because they aren't playing new single player releases and most probably only play dm3 24/7/365 or the start map or e1m7 in RuneQuake. 

Malice has items that modify the player's speed. One of them allows the player to go as fast as 600. Features of this kind are realized by modifying client settings (like cl_forwardspeed) every time an item is activated or deactivated, which leads to problems with savegames.

Perhaps what's more important is the way the mod sets sv_maxspeed to 600. I don't know why, but it does that at the beginning of each level, but not at the game startup. The symptom is: starting Malice and loading a savegame gets you a standart speed cap if 320.

My limited understanding suggests that an engine-side solution to a problem of this kind won't be pretty, but I thought I'd mention these anyway. 

Yeah, that isn't related to Mark V as I think you know.

They could have benefited from some of the things Preach has Quoth do upon save/load, but Quake was new and no one developed Preach's Quoth trickeries.

/Quake's save games don't actually save enough information. And never have. 

Capslock key not bindable? ("not a valid key")

Can it be?

I guess you might have to disable its standard function so that it's not actually setting Caps Lock every time someone used it. Just do that if it's actually bound, but if not, let it be standard Caps Lock.... Or just disable it completely. Who needs Caps Lock in Quake?

Hm, looks like Proquake just disables it... but... still won't let me bind it as a key ? 

A thoughtful response 

Oh. Why is that? Is the CapsLock key just something Quake can't handle? I thought with all your extra keyboard code, it wouldn't be a problem.

It's a shame to have an unusable key right there next to WASD, where everyone's hand will be. 

Joking around aside, I spent quite a bit of time studying input API on various systems and in Windows. And with system methods and SDL input methods.

Caps Lock is a real PITA in a number of the above scenarios.

I don't want the input code as a nightmare when I go to do Mac or Linux, so I don't want any differences in the keys behaviors.

An analogy:

Mark V's GL and WinQuake and Direct3D builds are a breeze to maintain because it's common code for about everything.

... Unlike what original Quake did where they were very separate.

By having unified input code (which is tough) ... when I finally do Linux, for instance, I won't have to deal with a lot of irregularities. 

Well, Grumpy Cat makes any thread better.

One last report, then I retire to my crypt for the night.

scr_sbaralpha got borked at some point.

In DX, it just doesn't make the HUD transparent at all.

In GL, it does make the HUD transparent, but if the value is below 0.7, the console background becomes invisible.



I've been looking through the "find all" list. I notice pq_fullpitch is in there as "external server hint." Is that just so you don't get errant messages like "unknown command pq_fullpitch" when you connect to a server that makes the setting?

If that's the case.... When I connect to the FvF Proquake server, I get "unknown command cl_fullpitch." So could cl_fullpitch be added in there too? Very minor issue, really.... But It looks like Proquake has both those commands. 

I noticed the external texture sbar alpha thing with the dx build when I was trying to unravel your dx8 issue. The invisible HUD below 0.7 is probably due to alpha masking test 0.666 in FitzQuake. And cl_fullpitch thing bothers me some. I'll eventually address all 3 of those small little oddities. 

In Shrak v2.0, they also fixed an issue in vanilla Quake, and I am not sure if it is fixed in Mark V. From the Shrak readme:

"id included sounds for unlocking the door as well as the normal 'door opening' sound. But because the unlocking and the opening happened at exactly the same time, you never heard the unlocking sound." 

This probably got lost in the old thread, but it's perfectly possible to do in GL 1.2 and no shaders needed.

Draw the regular 3D view.

glCopyTex(Sub)Image it to a texture.

Then draw that texture back using a grid with warps at the vertices.

This is similar to stock Fitz/QS "framebuffer water warp" but kind of in reverse. It should even be possible to reuse much of the code, maybe tweaking some parameters.

Of course the larger texture size needed for this implies a higher GL version, but that never stopped people with external textures or skyboxes.

You can also hack something up by playing around with the projection matrix. In addition to the FQ stretch & squeeze, mix in some rotation. It can look good and it has minimal performance hit, but here you need to derive the frustum properly from the view and projection matrices rather than calculating it separately. IMO you should be doing that anyway, likewise with vpn/vright/vup, which also come straight out of these matrices. It's always good to clean up Quake's "calculate the same thing in different ways and in different places" crap. 

Sounds like a QuakeC game logic fix -- so it should work in an engine. 

That was @nightfright obviously