Thanks, Appreciate It
#3082 posted by ericw on 2017/11/16 05:49:19
Will keep exploring this but did not happen with .92x and Admod versions.
One thing is, 0.92.x and the admod build did not have refresh rate control. (I only added it in august.)
Something that might be worth checking is Fitzquake 0.85, if you don't have it already; it has the same refresh rate cvar and option in the video menu:
http://www.celephais.net/fitzquake/
I also did a bit of searching and it sounds like gamma changes can be an side effect when high-refresh rate monitors switch refresh rates - so I wonder if it could just be that?
http://www.mmo-champion.com/threads/2098378-Asus-24-quot-LED-A-Sync-MG248Q-brightness-at-different-refresh-rates
#3083 posted by R00k on 2017/11/16 06:12:55
okay, so not trying to be a proud c0ck in any way, yet, hear me out. I try to to a timedemo demo2 in QS newest, and get around 631.4fps yet in Qrack in the classic settings (which is standard quake) im getting 2200fps yet Qrack uses stupid opengl 1.3...
i'm not trying to tug a war just wondering if your glsl is batching per frame or per model?
#3084 posted by R00k on 2017/11/16 06:16:01
im using windows 10 pro 64bit nvidia 960gtx
btw
#3085 posted by R00k on 2017/11/16 06:32:16
quakeone.com/qrack test it yourself
#3086 posted by metlslime on 2017/11/16 07:29:32
screenshots will not show hardware gamma correction, that correction happens only as the framebuffer is drawn to the screen. (which is why it affects the whole screen when playing quake in a window, rather than just the game window.)
#3087 posted by ericw on 2017/11/16 07:58:46
rook: yeah, I get similar results, though not as extreme, 850fps for qrack vs 500fps in QS for timedemo demo1. this is 1920x1200 on a 650gt. I don't have a good explanation. QS does well when the maps get bigger and/or there are lots of MDL's on screen, but there must be some reason it's worse on "easy" content. IIRC, DirectQ on the other hand was blazing fast on id1 content.
#3088 posted by mh on 2017/11/16 10:36:12
Is QuakeSpasm still sleeping every frame, even in timedemos? That would cause it.
#3089 posted by mh on 2017/11/16 15:28:07
Tested using latest source, in main_sdl.c, line 184:
if (time < sys_throttle.value) 483 fps
if (time < sys_throttle.value && !cls.timedemo) 1228 fps
#3090 posted by szo on 2017/11/16 17:40:18
Set sys_throttle to 0 on your console before running a timedemo.
#3091 posted by R00k on 2017/11/16 17:43:18
ya setting sys_throttle to 0 im pushing 2000fps now.
Eric
#3092 posted by spy on 2017/11/16 18:34:01
Could you add an "r_viewmodel_fov" cvar from mark_v
Spy:
#3093 posted by ericw on 2017/11/16 19:56:02
it's something I want to add but didn't get to for this release. The RC does have r_viewmodel_quake (also from markv) where 1=restore winquake gun position.
Been Wondering
#3094 posted by iriyap on 2017/11/16 21:24:33
Is there any technical reason why water etc liquids textures are not mipmapped in QuakeSpasm? It's usually not very noticeable, but maps with large bodies of water (like Orl's shib1) have a lot of aliasing.
#3095 posted by R00k on 2017/11/17 04:39:47
does the water textures have TEXPREF_MIPMAP flag set?
Re: #3094
#3096 posted by metlslime on 2017/11/17 06:55:02
It's probably unchanged from Fitzquake. In Fitzquake it was done for two reasons: 1. it's not mipmapped in the software renderer (so +1 for authenticity) and 2. since the water texture is rendered every frame (when using r_oldwater 0) this means the mipmaps would also have to be recalculated which I didn't know how to do at the time (and still might not be fast enough even if I did know how.)
Yay Authenticity
#3097 posted by Qmaster on 2017/11/17 22:16:10
But in the interest of algorithmic nerdiness...
Could you generate the mipmaps at level load and cache them?
#3098 posted by iriyap on 2017/11/17 22:59:12
vkQuake (a fork of QS on Vulkan API) does support water mipmapping. Not sure how much of the Vulkan code can be translated back into OpenGL, but I suppose it could be helpful as a reference.
#3099 posted by ericw on 2017/11/17 23:10:40
Yeah - I saw that vkquake does it. It sounds like it is doable in OpenGL 1.4+ with GL_GENERATE_MIPMAP, and is done in by the GPU (if it was done on the CPU it would kill performance because the warp textures are updated every frame):
https://www.khronos.org/opengl/wiki/Common_Mistakes#Automatic_mipmap_generation
The other thing I was going to investigate was doing the warp in a fragment shader, but need to investigate whether it's faster even on lower end hardware, and if it can be made to look identical to the current warp.
#3100 posted by R00k on 2017/11/17 23:18:21
hmm odd i thought even glQuake mipmapped all textures including
water and sky textures?
#3101 posted by mh on 2017/11/17 23:46:55
Warp in a fragment shader is faster, even on lower end hardware, and can be made look identical.
Visually it can even be superior, because normally with mipped warps the texture can shift between different miplevels as it warps, even if nothing else changes. But by taking the screen space derivatives of the unwarped texcoords and using a tex2DGrad (or equivalent) lookup, you get to avoid that and get a nice solid warping image.
MH
#3102 posted by ericw on 2017/11/18 19:15:55
cool, thanks for the tip on tex2DGrad, will look into that.
I dug out a quick hack of RMQEngine's warp code to GLSL that I was experimenting with a year or so ago.
Snapping the texture coordinates to the nearest 1/512 (fitzquake renders the warp image into a 512x512 texture by default) seems to approximate the look of fitzquake's warp very closely:
vec2 texc_input = gl_TexCoord[0].xy;
texc_input = floor((texc_input * 512.0) + vec2(0.5, 0.5)) / 512.0;
rest of the shader
screenshots:
fitzquake render-to-texture warp
the above shader
above shader with the rounding-to-nearest-1/512 commented out
The timing is slightly off between the fitz and shader versions but they look pretty close to me otherwise, so this looks promising.
Quakespasm 0.93.0 Released
#3103 posted by szo on 2017/11/20 12:13:33
Congrats On The Release!
#3104 posted by iriyap on 2017/11/20 13:07:16
Also maybe it's a good time to mention that a lot of links on the QS page are broken, like the id software link on the "Being" page and most of the links on "Other Worlds" (just link them to Quaddicted, Kell's page has been moved here).
Cl_alwaysrun
#3105 posted by Spud on 2017/11/20 13:21:12
Well hey, that's a neat early-morning surprise. Might've noticed a minor mistake in the patch notes, though:
Revert "always run" changes from 0.85.9 and move the QuakeSpasm
customizations to a new "cl_alwaysrun" cvar: Set to 1 in order to
scale forward/side/up speed by "cl_movespeedkey" (usually 2), and
to make "speedkey" act as "slowkey".
So far as I can tell, cl_sidespeed isn't actually affected by any of the settings and remains at 350 (the Quake default) regardless of Always Run setting, while _forwardspeed and _backspeed work as intended (400 for Vanilla, 200 for Off, 200 [* cl_movespeedkey 2 to equal 400] for Quakespasm). 'Walking' also only affects forward and back speeds, not side speeds, the same as the old behavior.
About The Quakespasm.pak
#3106 posted by Barnak on 2017/11/20 14:40:07
Is the quakespasm.pak file up to date from the sourceforge link ?
The version that comes with the link above has date
2 march 2016 00h00,
while the version I already have (from somewhere I don't remember) has date
27 june 2017 21h46.
So what is happening with this file ?
|