> Using (kinda) weapon repositioning with scr_ofsx "-2" in autoexec.cfg as a workaround

Both QS(S) and vkQuake should have a cvar for this:

* New "r_viewmodel_quake" cvar. Set to 1 for WinQuake gun position (from MarkV). 

Yeah, I am using that (pity there's no menu option for this). For my taste, weapons are still too low with it. But well, it's also because the statusbar is in the way. Maybe it's really time to switch to one of AD's new fancy side panel-HUDs as a new default. 

You're running with a status bar alpha less than 1; set it to 1 and it will correct the position, obviously as a trade off for no longer having a translucent status bar.

QuakeWorld has a nice HUD that it would be cool if other engines picked up, and that also works well with gun model positioning. It's about as close to an official alternative as it's possible to get. 

Ah well, I will get used to it. I wished there were ways to do things like that Fullscreen Statusbar Mod I made with 3saster for GZDoom.

Consider that statusbar request cancelled, then. Vanilla waterwarp and .vis support should be doable. I saw there are feature requests for it over at the QSS Github already. For vkQuake, I made the tickets by myself. 

In QS 0.93.2 For MAC, elevators are definitively an issue, irrespective of the map.
Just try the elevator in the start map of AD 1.8. 

... or the elevators in E1M1. The elevator blocks if you are going up. No problem if you go down.

I didn't have this issue with 0.92.2. 

... my fault --> host_maxfps above 72!

I apologise, a warning was even present in the console. 

Hey, I'm using the OS X version of Quakespasm with a 16:10 resolution and none of them look right. The screen's either too high or too low, so I get black bars on edges. Any way to fix it?

PS. Sorry for my noob question, this is literally my first post. 

Adding -width x -height x to your command line will run Quake in a custom resolution of your choosing. Not sure how this would work on a Mac but doesn't a popup appear when you launch on Mac?

More info here

https://steamcommunity.com/app/2310/discussions/0/340412122415607313/ 

Yeah, that's the obvious thing, right, but doesn't fix the problem. I select the right resolution for my monitor and honestly all of them have the screen either being too high or too low, cutting off parts of the game. 

Since there is no vkQuake thread I figured I would ask this here. In the latest version of vkQuake (1.05.0) any and all brush entities are not affected by dynamic lights, including lights from rockets and weapon flashes, flickering or strobing lights, etc. They always remain the same lit value, note the first secret door in e1m1 is fullbright despite being in an area with a flickering light.

Is this behavior intentional, or is it a bug? 

That has to be a bug. I've just had a quick look over the Github and the code for calculating lights on brush models is still there. I didn't look over it comprehensively enough to pinpoint what the bug may be, however. 

reading through the issue tracker I found that this commit caused the problem.

https://github.com/Novum/vkQuake/commit/253a706f8907866ae7ab664e092cdcb6ae43cfc2#diff-d606d657e2d89d658bc091d13fb9ee2de2cf4fa01a26b127d79d890a0c75c20bL151 

Hi! i was trying to change console font but i cant find the way, how can i do it? and where can find conchars example to test it?

Thanks alot! 

Quakespasm uses the standard file format for conchars, here is a guide:

https://www.quakewiki.net/archives/fatty/defaulte128.html?opinion=conchars

Short answer, it's in gfx.wad 

aaaaa!!!! thanks you so much bro "!!! 

And for Quakespasm spike? you how works? same way than quakespasm ? 

The same method will work there. 

thanks! 

Sensitivity on MOVE stick is too high. I can't strafe properly, my character just launches himself left and right.

You can alter the sensitivity of the LOOK stick but not with the MOVE? 

apparently QSS supports IQM:
https://github.com/Shpoike/Quakespasm/blob/9ffca1dedc47061ec4c2b7c230c44aa23a591226/quakespasm/Quake/r_alias.c#L619

so, for animated models, one can just use the following plugin:

https://github.com/lsalzman/iqm/blob/master/blender-2.93/iqm_export.py

and use them as replacements? Or are animations not supported at all? 

Is there a way to make particles bigger like they are in original DOS Quake or WinQuake?

For example, comparison screenshots: http://gila.deathmask.net/particles/

In DOS or WinQuake, the particles are really big, even in higher screen resolutions. In modern GL/Fitz/QS/vkQ variants the particles are too small compared to that.

I thought that r_quadparticles would affect this, but it's purpose is probably something else. 

What you're seeing in Dos/Win Quake is particles that are further away. It's also noticeable that when particles are closer to the viewpoint in Dos/Win they're substantially smaller.

FitzQuake and derivatives just use the same particle scaling algorithm as GLQuake, so nearer particles are larger, further particles are smaller, with further particles being slightly boosted in size to prevent them completely disappearing at more extreme ranges.

Looking over the code, there's no way to modify this behaviour, but there are a few scaling factors that could potentially be cvarized in a future version.

QSS, I would guess, has all of this controllable by CSQC. 

Thanks for explanation!

I walked rigth up to the wall and fired the shotgun. In WinQuake the particles are small, but as soon as I start moving away (like ~64+ units away maybe?) they suddenly get bigger, like x4 in size.

In GL/Fitz/etc it's the other way around. Really 'in your face' particles are big but moving away makes them smaller, almost like this behavior is inverted from DOS/Win :)

It's just that recently I played some classic map packs (Beyond Belief, etc) and both official mission packs in Mark V WinQuake to check out (more like to remember) the 256-color look, and then I go back to QS/vk/Fitz and the particles like blood and explosions are so puny and small... 

It's unfortunate that glquake and fitzquake and friends don't have particles that feel "correct", but the behavior of software quake is hard to call correct either, so probably the best solution (if one is needed) is to provide some cvars to let users get closer to the behavior they think is best.