News | Forum | People | FAQ | Links | Search | Register | Log in
Quakespasm Engine
This engine needs its own thread.

Feedback: I like the OS X version, but I have to start it from the terminal for it to work and can't just double-click it like a traditional OS X app. I'm sure you guys already know this, either way great engine.

http://quakespasm.sourceforge.net/
First | Previous | Next | Last
Thanks, Appreciate It 
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 
 
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? 
 
im using windows 10 pro 64bit nvidia 960gtx
btw 
 
quakeone.com/qrack test it yourself 
 
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.) 
 
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. 
 
Is QuakeSpasm still sleeping every frame, even in timedemos? That would cause it. 
 
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 
 
Set sys_throttle to 0 on your console before running a timedemo. 
 
ya setting sys_throttle to 0 im pushing 2000fps now. 
Eric 
Could you add an "r_viewmodel_fov" cvar from mark_v 
Spy: 
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 
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. 
 
does the water textures have TEXPREF_MIPMAP flag set? 
Re: #3094 
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 
But in the interest of algorithmic nerdiness...
Could you generate the mipmaps at level load and cache them? 
 
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. 
 
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. 
 
hmm odd i thought even glQuake mipmapped all textures including
water and sky textures? 
 
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 
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 
Congrats On The Release! 
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 
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 
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 ? 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.