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 

Could anyone confirm if stainmaps Quake default setting is OFF? 

Default Quake doesn't have stainmaps, so it is indeed OFF. 

Thanks! 

 

I fixed it in rubicon 2, the solution was to use a different channel for the second sound I think 

Created a page on the Quakewiki for external .vis and .lit packs, and put a link to that page on the Mark V page.

I separated out one (Abyss of Pandemonium) as an example and uploaded it to Quaketastic and put a link to it. See the first page in the Func "Screenshots" thread for the Quaketastic username and password.

This way new .vis and .lit content files can be added and updated. 

Video - Flames using QMB particle system

The QMB particle system is now working.

It'll be in the preferences menu and off by default. 

I have some extreme nitpickery to report.

Messing with the fullpitch stuff, I see that Mark V says these value mimic normal Quake:

cl_maxpitch -70
cl_minpitch 80

Buuut, they don't.
These values do:

cl_minpitch -69.93
cl_maxpitch 80.17

So it seems Mark V's pitch is very close to 0.17 lower than it should me.

How do I measure this? Well, start up a new multiplayer game, set gl_texturemode gl_nearest to get a nice sharp pixely look, and look all the way up or down. Looking down, set fov 30 or so and find a nice spot on the floor where you can mark your crosshair position. Do the same by looking up as far as you can with fov 10.

Repeating this (take screenshots if you like), you can see that in original Quake and Proquake, the position is identical, but in Mark V (and I think earlier Fitzqauke) it's off by a bit, unless you make the settings I posted.



Though neither of those cl_maxpitch values will be without issue when connecting to a Proquake server which disables fullpitch.

Upon connecting to FvF, for example, I find my value is altered to:

"cl_maxpitch" is "79.9969" (altered!)

Setting anything above that value causes the weirdness when you try to look all the way down and your view is jerked back to a legal value.

Though with the server sending the setting to me automatically, that's not really an issue.



On a less nitpicky note (though some will disagree!), this is one of those settings I have in the "Restore Quake Defaults" section of my MarkV.cfg file.

The Quake defaults should be respected and left as the defaults here. Fullpitch is for people who want an altered-from-default functionality.

Gosh darn it, back when I was a kid, we couldn't look all the way up and down, and WE LIKED IT THAT WAY!!



Though,

cl_minpitch -700
cl_maxpitch 800

Is pretty funny to play with! 

You are very likely correct about the original pitch numbers because of how client/server read and write those numbers and various roundings that happen (floating point imprecision and conversion to integer types of various sizes).

I remember having to do some fighting with those numbers when test against servers that require original pitch limits or they will fix your angle for you, which is an unpleasant experience. 

I just noticed an interesting interaction between shadows and transparent water.

It looks like the water is being drawn on top of the shadow instead of the reverse. So if the r_wateralpha is 1, you don't see the shadow at all. If the r_wateralpha is .1 then you see the shadow pretty well with a very faint water surface on it, and r_wateralpha 0 makes the shadow fully dark (using r_shadows -1).

This may be related to the issue NightFright reported on #697 of the old thread (and that issue still occurs, by the way). 

they seem to occur around every 30-60 seconds and last for about 3 seconds. the fps doesn't drop at all. It's like micro-stutter with input lag. I initially thought this had something to do with the seemingly random autosaving (didn't know winquake autosaved randomly until now) but loading the autosaves after a lag spike doesn't show a correlation.

this is on a relatively powerful pc (4970k, gtx980, ssd, etc). Still poking around for a solution... 

Shadows + water looks fine to me. screenshot.

Is this DX8 or a special circumstance or combination of settings? I believe you, but need more information or an example -- post a screenshot?

/Note: I expect to change r_shadows -1 to r_shadows 2 in next version. Follows more closely to the way other cvars work like r_lerpmodels (0,1,2) 

Are you using host_maxfps 72? 

144. going to test with 72.

im dumb.

sorry. 

Both GL and DX.

I think you are getting the shadow effect there, but it's not very noticeable because your shadow is fully in the water, and the area is dark. Notice you see the water texture on top of your shadow, but your shadow should be fully dark if you are using r_shadows -1

Stand somewhere so your shadow is partially over water and partially over solid ground, and alter the water alpha settings to 0, 1, and somewhere in between. Try the little square thin water place on e4m2 or just stand on the upper level of e1m3 so that your shadow overhangs the edge above the water.

Or the Start map, just stand so your shadow passes over one of the cracks in the floor with water below.

Uhhh... I wasn't going to post a screen because this should be easy to reproduce, but what the heck is happening here?

http://imgur.com/a/vUIz9


Some kind of anti-wallhack thing? sv_cullentities is 0. If I set gl_clear 1 then that area becomes grey. This in in DX. Looks like in GL, the area is grey even with gl_clear 0. 

Oh, chase_mode 1 is what's causing that weirdness.... I know that's an "experimental" feature... but that's an ugly effect, heh. 

You are using chase_mode and I told you it was experimental ;-)

Sometimes chase_mode can't work perfectly for a few different seasons --- remember the thing about saying how complex camera code is in modern games?

In your screenshot, the camera and the player are in different visibility leafs.

The player can't see those walls, but your camera view point can.

Only one solution for you: Type r_novis 1 + sv_novis 1 and pay the price for the server sending 100% of all entities and the client-side just assuming every wall in the map can be seen. 

Yup, r_novis 1 clears it up. But I'm not leaving that on. Of course, normal chase_active 1 doesn't have the problem, but I like the neat feature of having my crosshair remain accurate in chase mode (that's all I really want), so I'll deal with the occasional ugly effect and keep using chase_mode 1.