#2902 posted by Spike on 2017/07/10 02:53:09
actually, 'gamma fps' will drop your framerate AND be unplayable in QS (gamma 0 = white screen).
In QS, you want 'gamma 1;contrast 1' to boost your fps.
To be fair, I guess that 'gamma fps' would at least stop you from caring so much about framerates...
@Spike
#2903 posted by bakedpotato on 2017/07/11 11:13:29
Wow, I hadn't realized how much that contrast nerfed my fps. In the AD level selection map I'm running 95-105 until I crank contrast up to 1.8, which drags it down to 60-75.
The colors are so much more vibrant, though...
#2883
#2904 posted by Jonas on 2017/07/11 16:03:42
I'm a femministt cuckk to.
Bakedpotato
#2905 posted by ericw on 2017/07/11 22:08:23
what GPU out of curiosity?
We could improve it a bit by (avoiding an extra copy of the framebuffer) by rendering into an fbo and drawing that to the window. (currently it draws the game in the window, copies it to a texture, then draws it back to the window with gamma/contrast.)
@Ericw
#2906 posted by Spike on 2017/07/12 03:31:20
contrast-only could be done without the fbo or even glsl.
glBlendFunc(GL_DST_COLOR,GL_ONE);
glDisable(GL_TEXTURE_2D);
glTexEnvi(GL_MODULATE);
will do something like:
screen=screen*(white*vertexcolour) + 1*screen;
with the above, gamma 1;contrast 1.8; is about as cheap as you can get it without blackmailing microsoft into finally fixing their gamma ramps issues.
A (quake)gamma of 0.45 or so can be achieved quite cheaply with glEnable(GL_FRAMEBUFFER_SRGB); (although you're meant to use an srgb-capable pixelformat too, which is messy but not needed at least on nvidia). Side note: this approach gives MUCH less banding than you would get with glsl.
Of course, talk about srgb just drives home that quake's colours are totally screwed, and its lightmaps are non-linear too...
Hold On
#2907 posted by Qmaster on 2017/07/13 03:46:58
Let's not confuse contrast with gamma now. :)
Feature Request (Not Hopeful!) :P
Would it be possible to add vibration support for the controller?
Playing with controller works really well in single player but sometimes when I'm playing maps that have actual 'quakes' in them it feels strangely hollow not feeling any rumble... Also, the Widowmaker in AD could really do with shaking that controller too!
Would Be Cool, To Control A Motorized Plastic Vagina Too !
#2909 posted by Barnak on 2017/07/13 19:16:48
Vibrations in Quake !? Geez I'm interested !
@ericw
#2910 posted by bakedpotato on 2017/07/14 05:24:11
It's getting old; Nvidia GeForce 8600 GT running driver v341.44.
Color me interested on the vibrations as well! I've actually been using the Steam controller to strong effect. It's worlds better than an Xbox controller, but still can't quite compete with a good ol' mouse'n'keyboard.
Just Pasting It Here, Maybe One You Find It Useful.
#2911 posted by anonymous user on 2017/07/16 00:02:53
QSS Protocol
#2912 posted by Mugwump on 2017/07/17 04:41:36
My QSS (admod) is set to protocol FTE+666. I thought this would make demos playable in both 666 and FTE protocols but they don't work in standard QS' protocol 666. I tried typing sv_protocol 666 in QSS' console but it doesn’t change to regular 666. Help?
Mugwump
#2913 posted by ericw on 2017/07/17 04:54:42
I haven't tried it, but try: "sv_protocol 666-"
To prevent the server from detecting replacement deltas (so they don't appear in demos), use "sv_protocol 666-" (omitting the - will neither enable nor disable fte extensions).
To re-enable extensions, use "sv_protocol FTE+666"
from http://triptohell.info/moodles/qss/qss-changelog.txt
Thanks Eric!
#2914 posted by Mugwump on 2017/07/17 07:27:27
Ahh Crap
#2915 posted by ericw on 2017/07/17 08:19:26
I didn't read the readme properly, apparently the proper setting is "cl_nopext 1"
QSS uses elements of FTE's improved network protocol by default. This is in an attempt to reduce demo filesizes, as well as allow for mod extensions. This does not hinder QSS's use as a server and is only an issue for demos. Set cl_nopext 1 before connecting/starting a map if you wish to disable the use of this.
http://triptohell.info/moodles/qss/
OK, Thanks
#2916 posted by Mugwump on 2017/07/17 08:53:52
I did try sv_protocol 666- and it worked, though.
an attempt to reduce demo filesizes
Wow! Reduce indeed! I've recorded demos of the same map in both QSS protocol FTE+666 and QS protocol 666 and the difference in size is approx tenfold... I was wondering if this was normal.
@#2916
#2917 posted by brassbite on 2017/07/17 17:31:42
Well when you zip or otherwise compress demos, they squish together at similar rates.
#2918 posted by Baker on 2017/07/18 00:46:33
FTE+666 is an optimized protocol.
If a health box is just sitting around in your view, Quake will send information on that healthbox every single frame.
FTE+666 sends it once, gets an acknowledgment back, and then won't send information on it again unless something changes and if so, only sends what changed and sends the change just once.
QS Sound Question
I am doing some sound work for Map Jam 9999. (new sounds with play_sound_triggered)
I know QS requires mono sounds but am I cool with making sounds 44.1k 16bit? I've tested them and they work (even 48k) but wanted to make sure I won't encounter any issues.
#2920 posted by ericw on 2017/07/18 02:37:12
16 bit 44.1k mono sounds should work fine. QS's mixer downsamples sound effects to 11.025k by default, so the extra quality of 44.1k won't be heard, but it won't hurt.
@ericw
Thanks. 11k introduces extra noise on my end (if I master them in that format.) I would prefer to start cleaner so this is good news.
#2922 posted by khreathor on 2017/07/18 18:39:32
Imo you should export to 11k. You'll have more control over quality and sounds will "weight" less.
Just figure out why sounds get noisy and fix it :)
I don't know what software you are using but this small free editor always saved my ass when it comes to editing sounds for old games:
http://www.wavosaur.com/
It can set loop markers too, if you want loop sounds in Quake :)
@kthreathor
I'm using Adobe Audition CC 2017. I can set cues for loops no problem.
But no, if the engine uses 44.1k that's what I am using. The downsampling and filtering seems cleaner than fucking with noise reduction to save a couple of megs in file sizes - that will affect the sound quality greatly. But thanks for the suggestions anyway. I just wanted to be sure I wasn't going to cause any unforeseen problems. I will look at wavosaur for sure. Never too many sound apps!
Vid_desktopfullscreen "1" Issue
I'm using build r1425. I'm not sure when this started but every time I close a game the above is added to my config.cfg. Whether I change the resolution in-game or add it to an autoexec file, it ALWAYS resorts back to:
vid_desktopfullscreen "1"
Even if I delete the line entirely from the config it just gets added again.
I've removed all config AND autoexec files that I can find, yet it still ends up back in there!
It's driving me mental! Any ideas? :)
PS:
I want to run fullscreen at 720x480. It also used to work fine...
#2926 posted by ericw on 2017/07/19 19:08:25
Try entering "vid_desktopfullscreen 0" at the console and then exit. It should get saved in your config.cfg as 0, then start the game again and print the value (just enter "vid_desktopfullscreen" at the console), it should still be 0. If it's not 0 then it's coming from another .cfg or quake.rc file.. do a find-in-files for "vid_desktopfullscreen" with a text editor
|