particles - qss uses fte's particle system to support the effectinfo stuff that sock used in ad, as a result qss should have much more sane demo sizes with ad 1.5.

choppy - use a thread to perform the disk writes, then you don't get stalls from flushing happening on the main thread.
making that change reportedly solved multi-second stalls with fte on linux.

size - gzip it as you go (you don't rewind, right?...). 

damn

the demo that i recorded for ad_magna is 2gbytes

i checked with r_showtris 1 and no particles-entities, the demos should be smaller 

making that change reportedly solved multi-second stalls with fte on linux.

Interesting. 

All the FitzQuake derivatives support r_drawworld 0; fog 0 // fog 0 helps visualize distance entities.

The following screenshot demonstrates how map vis isn't helping much ...

Particles ... but as you can see there are tons of candles and monsters in the vast distance. It's a lot of unnecessary drawing.

http://quakeone.com/markv/media/r_drawworld_0.png

All those monsters that have no chance of being seen ...

1) Get sent to the client by server.
2) So they get recorded in a demo
3) So the engine tries to render them on the screen

Rendering hundreds of entities that cannot be seen is a performance hit. 

"Which also means it is possible for new optimizations to theoretically be written eventually to shift some burdens from the QuakeC to the engine (particles).

Arcane Dimensions merely exposes things that the map compile tools and the engine particle systems could handle better. "

I was tinkering around with an idea, (well mostly because I found what I did wrong with bsp2), working on some AD stuff, and particles. I started with making little flames on the tops of candles, instead of the bouncy little polygons. But I could expand this to replaces the sprite emitters from AD and use QMB particles on the engine side. I'll post some results/screenshots when I get things rollin'. 

Hey, I'm getting a weird wateralpha bug

see: http://imgur.com/a/rqoGv

the lava (or any fluid) appears milky except for when the player is clipped into a wall?

the alpha is set to 0.3

the version is version 0.92.1 (SDL 2 build)

I'm running ubuntu 16.04 LTS using opensource radeon drivers.

Is this a configuration thing or a software bug? Cheers. 

the map isn't water-vised...
(combined with gl_clear) 

I thought that the vanilla maps worked fine with wateralpha 

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.