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.
First | Previous | Next | Last
Problems Using DSR Resolutions 
After finding much success with EZQuake and 3620x2036 DSR enabled via NVIDIA settings I notice that QuakeSpasm cannot handle the DSR resolutions well: the console rendering gets all whacked. 
Define "all whacked"
I can run it in 7680x4320 and it looks just fine.
Have you tried changing scr_conscale? (also scr_menuscale, scr_sbarscale) 
Well, this is odd: I tried to take some screenshots to show exactly how it is "all whacked" only to realize that screenshots in fact show the console and the entire screen rendered correctly. It's only on my actual screen where things look wrong.

As I started paying more attention I realized that going above the screen native resolution of 2560x1440 increases the overall "zoom level" of the screen. When using DSR resolutions, I can clearly the the bottom "status bar" dissapear and the left side of the console window falls outside the viewpoint. As the DSR resolution is increased further, so increases the amount of this "zoom" leaving out borders of the screen out from view.

Are there some other cvars involved? 
Apparently QuakeSpasm was trying to used windowed mode instead of fullscreen. 
Cl_bobcycle Causing Grey Screen 
Setting cl_bobcycle to "0" makes the screen go grey.
Found this out after a long battle to get things to work again. 
Setting cl_bobcycle to "0" makes the screen go grey.
There's a division-by-zero in the original code with cl_bobcycle 0 - "cycle = cl.time - (int)(cl.time/cl_bobcycle.value)*cl_bobcycle.value;" - whether or not it makes your game go nuts probably depends on compiler options/etc and unfortunately in the original engine it was OK but in some ports it's not.

So just set it to a really low value until the QS devs fix it. 
I think the intent was "cl_bob 0", not bobcycle 
I had an config file which works good with many engines. At some point though I only got this grey screen in quakespasm. After finding the solution I wanted to post here to help anyone experiencing the same problems. 
Yes, "cl_bob 0" is obviously the intended way to disable bobbing in the engine, but unfortunately "set cl_bobcycle to 0" is one of those items of "Quake lore" that gets passed around, which accidentally works some of the time, but which is actually wrong.

Fortunately it's an easy fix in the code: just check if it's 0 and set cycle to 0 if so: 
Dynamic Shadows 
So, I woke up at 3am, bored, and well here's this..

in r_alias.c

i just added the shade variable in GL_DrawAliasShadow

R_LightPoint (e->origin);

shade = (((lightcolor[1] + lightcolor[2] + lightcolor[3]) / 3)/128);//R00k


glColor4f(0,0,0, shade * (entalpha));//R00k: fade light based on ambientlight


GL_DrawAliasFrame (paliashdr, lerpdata); 
un-private the video fella 
Needed Features 
Hello. There are any chances to see WinQuake's software render with oldschool look/atmosphere and QuakeWorld servers support? 
Quake Qbism. 
"QuakeWorld servers"
There is no Vanilla based engines with those features, so I want to see it in QuakeSpasm. 
Its exactly the same as WinQuake even with no proper widescreen resolutions support and this port has its own bugs, so it has no sense. 
tyrquake, compared to WinQuake, can render more complex maps (BSP2 support) and has model interpolation. It also has alpha support for models and liquids, including the software renderer.

I'd say it's otherwise close to WinQuake, but it certainly has improvements. It certainly is not on the feature-level of quakespasm.

Talking of which: I noticed vkquake included QSS' support for decoupled render/physics framerates:

Looks surprisingly non-intrusive and should not alter behaviour for framerate caps up to 72. Is this something that can be considered for upstream inclusion? 
iirc the 'decoupled render/physics' is from quakespasm-spiked. And it does have limitations.
if you are on a huge map and your frames drop below 72 it starts to produce a slow-motion effect the further away from 72 you go. And on the opposite end, the higher you go over 500fps, it gets faster.
but, for the 72-500 range it works fine. And it's not the logic of the code, it also happens on othe independent physics code i have tested. 
Yeah, that's code from quakespasm-spiked.

As for problems above 500 fps - well, capping it at (pulling a number out of thing air) 300 fps would still enable a match for all modern display devices, so that's the easy case.

Slowmo below 72 fps, of course, is a problem. I wonder if the engine could detect that and switch dynamically as per situation. 
Basically, grab the current fps value, if its < 72 then turn off the independent physics code, and let the engine run like normal. 
same for > 500 too. 
You could also run multiple physics frames of the renderer is running slow. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2020 John Fitzgibbons. All posts are copyright their respective authors.