Options:
#3202 posted by Qmaster on 2017/12/31 01:30:27
• Reduce video resolution
• Play on a computer made after the year 2010.
Also
Be aware that the physics breaks above 72 fps. So if your standard is ultra-smooth 144 fps you're going to be disappointed.
#3204 posted by Baker on 2017/12/31 07:46:24
Can't find the tools thread (I suck) ... didn't want to kill joy in a new release thread.
"Fix MarkV .lit rendering (do the color->greyscale conversion in a way that forces MarkV, FTEQW to render identically to Fitzquake, Quakespasm) "
That's is completely inaccurate description. The external .lit file is just covering up the evidence.
If you would load a map that suffers the issue in GLQuake or WinQuake it would look all wrong too, so there was a majorly serious issue there with the .bsp having lit data that didn't resemble the data in the external .lit file.
I am hoping you already know this and expect you do.
Back a few years ago when Spike explained the rationale behind FTEQW's .lit method, the logical was so sound and impactful that it was clear it was the "right" way to do things.
Posted here so I don't killjoy your release thread.
Pritchard should get beta tester MVP trophy.
Most Valuable Pritchard
#3205 posted by PRITCHARD on 2017/12/31 13:11:22
What, for noticing that the lighting was buggered?
I don't know what the best solution is for .lit compatibility is but it might still be this one - having maps look different in different engines sucks so being able to make everything look the same is very valuable. It would be a lot harder to coordinate this between each individual engine I imagine...
#3201
#3206 posted by mh on 2017/12/31 13:15:24
In AD you can try disabling the custom particle system. QS doesn't sort or batch sprites so this can be still a bottleneck.
IIRC there's an impulse command for it docemented in one of the readmes.
Be aware that at some point in the future a version of QS might exist that does batch sprites, so this bottleneck might go away and "disable particles for higher performance" would no longer be good advice.
#3203
Can't one set vid_refreshrate "144" and host_maxfps "72" for a smooth frame rate without tearing and breaking the games physics? I thought that's what these CVARS were for... I could be wrong, though, as I'm pretty ignorant to most settings for Quake!
FYI
#3208 posted by Kinn on 2018/01/02 01:55:56
Interesting comparison of model light levels across WinQuake, QS and FTE:
http://www.celephais.net/board/view_thread.php?id=61351&start=121
Possible Bug
#3209 posted by FireNX on 2018/01/03 01:20:28
Nice port, I'm really sorry that my first post is gonna be a bug report. Previous Weapon doesn't seem to work, no matter what I assign to it. Next Weapon does work though. Also, when assigning a key to an action (when the equals sign appears) moving the mouse acts as if using it to point (as in moving the camera). Besides that, it's a great port, really faithfull to GLQuake.
#3210 posted by Joel B on 2018/01/03 03:06:36
The "Previous Weapon" feature is a function of the gamecode in your pak files, not something that the engine does (normally). It sounds like your pak files are not the final ones that were released for Quake. Sooooo... where did you get them from? Is it from the Quake demo, or an early run of the Quake CD?
Which Mod?
#3211 posted by Qmaster on 2018/01/03 04:45:04
#3212 posted by Joel B on 2018/01/03 05:14:17
True, it could also be from playing an old mod.
#3213 posted by FireNX on 2018/01/03 22:27:07
The .paks are from my CD. Someone else told me about the .pak thing today elsewhere. The weird thing is the same using the same .paks in MarkV doesn't give me this problem.
#3214 posted by ericw on 2018/01/03 22:32:16
MarkV can add "previous weapon" (impulse 12) even if the mod doesn't have it / you are not running the latest patch version of the pak0.pak/pak1.pak.
FireNX
#3215 posted by anonymous user on 2018/01/03 22:45:28
Replace pak0.pak (the one that's the same in shareware and regular Quake) in your Quake directory with the latest version (1.06, available here) and you should be good.
Pak1.pak shouldn't need to be updated to the best of my knowledge.
Solved
#3216 posted by FireNX on 2018/01/04 00:59:18
It was indeed the pak0.pak. Man, my CD must be old.
#3217 posted by Joel B on 2018/01/04 19:15:16
Collectible! :-)
#3218 posted by negke on 2018/01/07 10:16:21
0.93 "has stopped working" when trying to load death32c.bsp
Thanks
#3219 posted by ericw on 2018/01/07 19:28:32
reproduced it.
Getting Stuck On Buttons
#3220 posted by ericw on 2018/01/11 19:57:13
64-bit builds (tested on windows, probably linux/mac also) have a bug where the player gets stuck on buttons that move at an angle:
https://sourceforge.net/p/quakespasm/bugs/26/
I don't have a fix yet, but it's 99% likely the same as past 64-bit bugs (code assuming x87 math with 80-bit temporaries for floats) and should be quick to fix.
We'll do a 0.93.1 bugfix release sometime soon with this, a fog bug fix - https://sourceforge.net/p/quakespasm/bugs/24/ , and the death32c.bsp crash (vis data overflow).
Does That Allow For Alpha Values Below 0.666 On {fence Brushes?
#3221 posted by Qmaster on 2018/01/11 22:24:03
Qmaster
#3222 posted by ericw on 2018/01/11 22:38:56
Do you know if any engines with fence textures implement it?
I'm assuming it would just need to use (0.666 * entity_alpha) as the alpha mask cutoff, instead of always using 0.666?
Not That I Know Of, Twould Be Great For Ground Fog
#3223 posted by Qmaster on 2018/01/12 01:00:00
Currently you can have a func_illusionary using a fence texture and set the alpha to any value between 0.666 and 1.0, but below that it just dissappears.
I think it is just an arbitrary hardcoded threshhold. If it is necessary to have a threshhold, having it at 0.09 would be preferable. I haven't done an engine comparison for it.
Could be the thresshold has something to do with support for alpha channels (e.g. on png) instead of just the pink palette value 255, but not really sure on that point.
#3224 posted by ericw on 2018/01/12 05:34:58
My understanding is, the 0.666 threshold only comes into play when you use texture filtering - the actual pixels of the fence texture only have alpha of 0 or 1, the texture filtering interpolates between these, and then the fragment shader converts the interpolated value back to 0 or 1, depending on whether it's less than the threshold or not. So the specific threshold will control how big the fringe is around spites / fences.
The "(0.666 * entity_alpha)" sounds right to me, it's just something that should have a test map + screenshots, maybe with 0.25, 0.5, 0.75, 1.0 entity alpha on a fence texture.
#3225 posted by mh on 2018/01/12 08:21:05
Lower alpha values will cause edges of fences to become faded, blurry or hazy, which is a very undesirable artefact. If you want to achieve a specific effect it's better to open a discussion about it, rather than trying to overload an existing effect in unintended ways.
Quakespasm Gamepad Problem With Menu
#3226 posted by Jago on 2018/01/13 19:04:05
I am trying QuakeSpasm with a Dualshock 4v2 connected to Steam Link (so it appears as an xinput device to the game, afaik). The controller works, but there is a very odd problem: there is seeminly no way to "enter" any menu. I can enter/exit the main menu, navigate it, but not actually enter any of the menu options with any gamepad buttons.
And a feature request if I may: would it be possible to add an in-game mod and map browser/launcher?
|