only if you revis them yourself, or use get vis patches.
otherwise they'll just be transparent and reveal the void below.

if you were using a value of 0.6, you might not have noticed. 

Will work but I believe it affects performance 

I thought that the vanilla maps worked fine with wateralpha

No, they don't. This is actually called out in the original GLQuake readme: https://github.com/id-Software/Quake/blob/master/WinQuake/docs/readme.glquake#L152

Unfortunately, the standard quake maps don't contain any visibility information for seeing past water surfaces, so you can't just play quake with this turned on.

Note that r_novis will just let you see surfaces through water; it will not let you see entities (monsters, doors, pickups, etc) through it. 

Mark V and DarkPlaces (rather sure) and some other engines support external .vis files.

https://quakewiki.org/wiki/External_Lit_And_Vis_Files

You put the .vis files in id1/maps and then all your Quake maps are vised.

It's pretty much the same thing as external .lit files. 

heh TIL

thanks guys :) 

I use this from BPJ wrote on an old thread on QuakeSource.org that just draws everything

[code]
byte *Mod_DecompressVis (byte *in, model_t *model)
{
static byte decompressed[MAX_MAP_LEAFS/8];
int c;
byte *out;
int row;

row = (model->numleafs + 7) >> 3;
out = decompressed;

if (!in || r_novis.value == 2)//BPJ
{ // no vis info, so make all visible
while (row)
{
*out++ = 0xff;
row--;
}
return decompressed;
}

do
{
[/code]

it simply allows me to see all ents underwater, yet im sure it's not optimal :P 

It's definitely not optimal because it will also pull in ents that would otherwise not be visible in a properly watervised map.

The other thing it will do is increase server load and protocol traffic.

The latter is something you might be surprised about. We have a tendency to base assumptions and measurements only on things we can directly see. In a scene with 400 active and moderately complex entities, the bottleneck isn't the renderer - it's PR_ExecuteProgram (QC, in other words). 

Some weirdness going on with the sky at high distances: back wall disappears when more than 8192 units away. 

 

It's at 16k as per default. With normal textures it works fine, just the sky brushes are affected. 

I bet it's a qbsp limit (BaseWindingForPlane). Someone reported this as a bug in tyrutils-ericw a while ago and I raised the limit, try the latest version of my tools. 

You really should just draw sky with glDepthRange (1, 1) - that way you can draw it as a tiny (but larger than nearclip) cube around the viewpoint and it will automatically position itself at the far clipping plane. The way Fitz & derivatives handle both the scrolling sky and skyboxes makes this very possible. 

I know most of the mods/maps have to be installed in the base Quake folder, but it really keeps that folder messy and it's hard to sort through if you have tons of maps/mods and when you want to delete a folder it's a hassle.

Is it possible to put all the mods/maps in a seperate folder and still be able to launch QuakeSpasm with enjector? I tried doing that but it won't let me because everything has to be in the basedir, is there a command i could use?

Is it possible to set a path to a different folder in quake injector? 

Hi!

Thanks for all the hard work you've put on this great engine. It wasn't until now that I was able to come across a bug that I'd like to report.

Fairly recently I got myself a monitor with a max refresh rate of 165 Hz, so to squeeze out all that juicy smoothness the monitor can offer, I decided to adjust the host_maxfps setting in the config to 200. However, this causes problems that can be seen most notably in elevators: all entities onboard the elevator seem to kind of lag behind.

For example, if I go down an elevator, the elevator goes down smoothly, but I go down in skips, as if I was Wile E. Coyote forgetting that gravity exists for a split second and then I fall on the elevator again only to forget gravity for another instant as soon as I touch the elevator again. And the pattern repeats.

The same happens going upward, with more severe consequences, as I end up slightly inside the elevator, which may sometimes cause the elevator to think that it's squishing me, which causes it to damage me and then reverse back down.

I did some testing, and the only influencing factor seems to be the value of the host_maxfps setting. (Fiddling with the V-sync settings didn't seem to do anything.) The threshold value seems to be about 165, above which the problem starts appearing.

Anybody else have this problem? Sorry, if this has been addressed before. 

In most quake engines and wasn't really designed to go that high. Some engines have uncoupled physics from framerate and work better at higher frames. I believe dark places is one such engine. 

Hi,
I know QS is OpenGL while RPi is GLES, but, really, it would be great to enjoy Quake (or Arcane Dimensions)on a small, silent and low-power-consuming Raspberry Pi 3.
BTW Quakespasm is yet available in Raspbian Jessie repository, but I get a "Couldn't load video device" error when I try to run it in framebuffer mode (CLI).

So really no interest in a Raspberry support? :( 

there's actually a few engines that support gles2 nowadays.
Izhido(was it?) had one for ios, alternatively there's multiple engines that run on android with its gles1/2 limitations, including my own.

If you grab the source for fte, you should be able to use the following command for the original rpi (cross compiles, you might need to fix up some assumed paths inside the makefile):
cd engine && make gl-rel FTE_TARGET=rpi
If they've fixed up their egl support since the original, you can try and be more generic and just use the following:
cd engine && make gl-rel FTE_TARGET=linux32 CFLAGS=-DUSE_EGL
With that generic build line, you can switch between egl vs glx under x11 with setrenderer egl vs gl.
I don't actually have any sort of rpi, so I can't really help much more than that. 

Funny thing I just ran across...

Using the latest 64-bit quakespasm-sdl2.exe, with the latest NVidia drivers, there are certain POV points on the DM3 bridge where sections of the outside pentagram area are being rendered in my view.

Screenshots:

https://www.dropbox.com/s/1b5cb0dbg9t51o6/spasm0000.jpg?dl=0
https://www.dropbox.com/s/nlst7lupknon1ga/spasm0001.jpg?dl=0

and here's my config.cfg and autoexec.cfg:

https://www.dropbox.com/s/wm75461ngtotcv8/config.cfg?dl=0
https://www.dropbox.com/s/6i1jj64oelutyg2/autoexec.cfg?dl=0 

I think it's just r_wateralpha 0.5 in config.cfg + non-watervised bsp (QS has had gl_clear default to 1 for a few versions, so you don't get HOMs anymore, but you get that instead, which is less obvious what's happening).

So it's good that it's not some deeper bug in the renderer, but this is a common enough thing (it's been reported a couple times I think, happens to me fairly regularly) that we should probably do something about it...

IIRC, QS has had r_wateralpha be archived in config.cfg since an early version, and when you combine that with changing gamedirs with "game" you can easily launch something like AD, then change to id1 in the console, exit, and end up having r_wateralpha 0.5 saved in your id1/config.cfg.

There's also the option of having the engine detect watervis, etc. 

Ah hum. Yeah I clean-installed recently and I guess I picked up a default r_wateralpha of 0.5 from either QS or Mark V. Actually it's been so long since I messed with those settings for non-watervised maps I forgot that it even had an effect if r_novis was 0. 

I really wan't to play Arcane Dimensions in low resolution. Unfortunately mark v, which supports resolution scaling, doesn't support AD. The winquake version has problems everywhere and the opengl version can't handle some things like the fog in the necromancers keep. Apart from that performance is also really bad. mh explained how that has to do with mark v being cpu-bound while engines like quakespasm are fillrate-bound, which also means that downscaling would greatly improve performance in quakespasm while having close to no benefit in mark v.

I mainly wan't this feature because of the way it looks (explained in detail in my mark v post here: http://www.celephais.net/board/view_thread.php?id=61375&start=1487 ), but the potential performance boost is also incredibly useful to me as I'm running quake on pretty slow hardware. Quakespasm is already a huge improvement over mark v in AD, but I still get occasional framedrops on 1366x768 (native resolution of my laptop) while 320x200 runs silky smooth. Of course not in fullscreen, but quakespasm will output that resolution in windowed mode if you specify it with -width and -height. That proves to me that the resolution I wan't to play on is at least technically possible in quakespasm, I would just need a feature similar to that in mark v which stretches a borderless window to fit the full screen without interpolation. You can even simulate something like this by using the windows magnifying tool, but it's horribly awkward to set up and doesn't allow you to use the mouse (more on that in my last post in the mark v topic).

So, getting to the point here, I will pay the developer who implements this feature in quakespasm. That's how badly I want this. I absolutely love quake, and the amazing lovecraftian environments in AD make me truly happy to experience, but I can't enjoy them as much on high resolutions as I would otherwise.

If you're one of the developers reading this, name your price for the time it would take you to implement this. I will pay you, given that the price is within reasonable bounds. 

Not sure I'd play on 320x200 but less detailed quake maps definitely look better in lower resolutions IMO. I tried setting QS to a lower res than my laptop screen, but my screen just blurs it and it looks terrible. It would be nice to have the option of playing on lower resolutions but with krisp krunchy krixels 

Yep. In vulkan quake i dont see an issue with 289. In quakespasm i get the gravity problem or when going up a lift it damage happens to health. 

Boris,

You could try this workflow for your purposes.

The following link details a DOS compilation of super8. I'm not sure how recent it is, however it may support modern map limits and features.

http://www.vogons.org/viewtopic.php?f=24&t=39878

If you don't have a DOS machine, you could try running it from DOSBOX or similar emulator or VM to achieve your desired results.

Good luck! 

I am game to implement this - it shouldn't be much work, and it fits well with the "vid_desktopfullscreen" feature we've had for a while (If you set this to 1, the vid_width/vid_height cvars are ignored when you go fullscreen, it just uses you desktop res.) Another reason to do it is, one of my test machines (Linux) doesn't offer any fullscreen modes besides the native LCD res.

How does this sound, new cvars r_width/r_height, which default to 0 (use window size), but if you set them to something else like 320/240, Quake would render at that given resolution and then get scaled to the window size.

The remaining questions are, if you render to 4:3 but have a 16:9 window, should it be letterboxed or stretched, and should the stretching be always nearest-neighbour or respect gl_texturemode? I am thinking always letterbox rather than stretch if the aspect ratios differ, and always nearest for now?