Thanks for the reply, Eric. I tried your suggestion but to no avail. That put Quakespasm being the issue to bed. I uninstalled SCPToolkit, installed DS4Windows and all is back to normal.

Again, thanks for your help. :) 

Sorry to harp on about controller stuff, Eric, but I have a request if it's possible.

Though there is change in player movement speed depending on how far one pushes the left analogue stick it would be nice if there was more nuance to it.

I don't know the technical term for it but I feel the movement should ramp up smoother across a greater range of the stick. Right now, it's a little twitchy for precision jumping and the like.

The right stick for looking is great though.

A slider in the menu would be perfect but even a CVAR (or is there already one that I've missed?!) would be nice.

Hope you're having a lovely Christmas. :) 

Hmm.. it looks like the only cvar for controlling the movement stick is "joy_exponent", default 3. But, that also affects the look stick as well.

Try lowering it to 2 or 1. 1 will give you linear mapping from stick travel to movement speed.

I can probably split this into 2 cvars if it turns out you need different values for the move and look sticks. There is no menu page for any of this, would be a good idea probably.
Thanks and merry Christmas as well! 

Setting the joy_exponent to 1 made a big difference to movement. However, like you suspected the effect is too heavy handed for looking. Would it be possible to split it into 2 CVARS?

I reckon setting them to 1 and 3 would be pretty perfect in terms of map navigation and aiming. At least, for me.

Also, I just want to say thank you for always responding in an interested and polite manner. I can't tell you how refreshing it is not having a dev respond with eye rolling or "code it yourself, noob". I enjoy playing another old FPS and I dread asking questions about that source port. Again, thanks for allowing me the space to 'just' be a player and not a mapper, modder or coder. :) 

Hey guys, thanks for the great work you're doing.

I tried running heavy mods like AD with Quakespasm, experienced not-so-high-fps. Which features can I disable (or use some commands) for any fps boost? 

• Reduce video resolution
• Play on a computer made after the year 2010. 

Be aware that the physics breaks above 72 fps. So if your standard is ultra-smooth 144 fps you're going to be disappointed. 

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. 

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... 

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. 

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! 

Interesting comparison of model light levels across WinQuake, QS and FTE:

http://www.celephais.net/board/view_thread.php?id=61351&start=121 

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. 

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? 

 

True, it could also be from playing an old mod. 

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. 

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. 

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. 

It was indeed the pak0.pak. Man, my CD must be old. 

Collectible! :-) 

0.93 "has stopped working" when trying to load death32c.bsp 

reproduced it. 

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).