That sounds like it could massively improve vis quality in big outdoor Tronyn-style facemelters. 

but i'm still waiting for a something new from Kinn

@Kinn , there's a TF discord channel, if you're willing to join to https://discord.gg/P56HXr 

... to see in 2018 is the weapon position from WinQuake's "viewsize 100" implemented properly in Quakespasm, Mark V and Darkplaces.

Mark V has an option to enable it...

Recent QuakeSpasms have restored the original code via the same cvar-based mechanism as MarkV too.

It'll probably never happen in DP because Religious Reasons. 

I'd love to see the top tier mappers start a project expanding on the shareware episode maps the AD's extra beastiary and projectile weapons.

I want to play E1M1 with the Widow-maker, dammit! 

What you described are Retroquad's hybrid skyboxes. It's a great idea indeed, but it's a pain in the ass to get working, at least on the software renderer. And creating alphamapped skyboxes that looks good is very difficult.
Hey, that's pretty neat. At risk of sounding like a complete moron, what exactly causes it to be a pain in the ass? I'm sure it's somewhat difficult to make it look good, but honestly, any sort of happy medium between the standard tiling two-layer skies and the static but six-sided skybox textures supported by newer engines would be fantastic. The extra detail given by the skybox is great but given how lively some Quake maps tend to look within the play area itself, the completely stationary skies and backgrounds can sometimes stick out like a nailed thumb. 

...what exactly causes it to be a pain in the ass?

I assume that's specific to the software renderer. In hardware it's just some cubemaps and some texture matrices. 

#112 Recent QuakeSpasms have restored the original code via the same cvar-based mechanism as MarkV too.

Thanks, I've found it now. There's no menu option for it in QuakeSpasm, and I usually don't bother searching through cvars in game engines anymore, so I didn't notice it was implemented.

After enabling it, paying in QuakeSpasm got 200% better for me now!

#114 what exactly causes it to be a pain in the ass?

The zero-overdraw architecture of Quake's software renderer is incredibly monolithic and gets in the way.

In my implementation, each side of the skybox is vertically cropped twice, one time for the fully opaque section of the image, and another for the section that contains some transparent texels, while the fully transparent vertical area of each side if fully cut out. The fully opaque section gets drawn as an opaque surface, and the rest is drawn as an alphamasked surface.
Also, the background layer's sides are cropped from the bottom of the alphamasked portion of the foreground, to the absolute height of the skybox.

Dynamically resizing surfaces like this, specially when all of them are shared by the same cube, causes complete chaos in Quake's monolithic BSP architecture.

The hybrid skybox implementation in previous versions of Retroquad was far simpler, resorting to much more overdraw, which is much slower. 

I noticed that some universal flags like Not in ... don't work for all entities, even though they work for entities that aren't documented as having them in .fgd and .def files.

How hard would it be to do this without mods so i can use an existing mod that i have no source for? Or is it better to leave that to mods just in case someone used those flags on theirs? 

Unless I misunderstand, it seems like there are two issues with that idea. First, there will always be false negatives if a leaf is visible in a narrow sliver that falls between raycasts. I realize these can mostly be reduced by adding more raycasts but never eliminated. Second, leaf PVS has to be valid for all points within a leaf, while any raycast-based system will be treating the leaf as a single point (or a small number of points) 

...there will always be false negatives if a leaf is visible in a narrow sliver that falls between raycasts. I realize these can mostly be reduced by adding more raycasts...

I really don't understand this part, and it's second time around.

Why the fixation on raycasts?

I'm not talking about raycasts.

Forget about raycasts.

There are no raycasts. 

isnt a "sample" in a hardware occlusion query effectively a raycast? I admit to not knowing the tech behind it. 

Unless you raycast for each pixel or something? 

If, however, you assign a unique color to each leaf and render flatscale color into a buffer, then parse each render to see what colors are visible... 

https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_occlusion_query.txt

Occlusion queries use the depth buffer. Raycasts are absolutely nothing to do with it. 

In full HD, surfaces smaller than 7*4 pixels would be invisible. 

And raycasts, lots of raycasts. Whatever the fuck they are. 

+1 for new scripting system
+1 for flexible HUD

Movable liquid volumes. Like turning a water brush into a func_door I could lift to flood an area. I understand that it envolves translating a volume where special physics and render takes place in runtime, but how hard it is to do? 

spy, cheers I might visit that discord place as long as it's not full of weird porn like the irc channel was. 

comprehensive co-op mod, with a selection of purpose-built maps by the community and an easy way to play online with friends who aren't really bright enough to play anything that's not on Steam. 

This basically requires all engine authors to agree on a feature so hahahaha, but anyway one thing that has always peeved me is how mod folders all have to be a child folder of a main quake (engine) folder.

When you have hundreds of mods, taking up gigagbytes, you only really want a single instance of your mod collection to exist on your hard drive.

This means when you have multiple engines, all these engines, and the roughly ten thousand dlls (often clashing) and readme files associated with each engine, all have to be dumped in the same main quake folder that's parent to your mod collection.

Yes, of course you can create a separate Quake folder for each engine, and duplicate all your mods across each of these, but as I said earlier, that rather sucks, can take up too much space, and it soon becomes a synchronisation nightmare.

I guess what I am saying is it would be great if you could tell any engine to reference a mod folder that's ANYWHERE on your drive, so you can just keep your mods centralised and separate to the engine installs. 

This means when you have multiple engines, all these engines, and the roughly ten thousand dlls (often clashing) and readme files associated with each engine, all have to be dumped in the same main quake folder that's parent to your mod collection.

Sorry I should have clarified a bit more - this sucks arse mainly because it becomes nearly impossible to then later remove a particular engine when they are all dumped in the same folder because all the dlls for each engine and other secondary files are all just mixed up together in one massive unorganised clutter, and you don't have a clue what can be deleted. 

Any decent engine will still respond to the -basedir argument (otherwise the vanilla behaviour is to use the working directory).
You can then install your (decent) engine inside some subdir and then tell it to use the parent dir for content.

Note that this won't help when it comes to the numerous config.cfg file conflicts. You'll need homedirs or alt-config hacks (eg: fte.cfg) for that, which is still ugly.
There's probably still a few other conflicts too (like console input history), though I don't think I've seen any such issues more serious than config.cfg conflicts.


Unfortunately a few engines are buggy and force the basedir to where the exe is (regardless of working directory), and in doing so ignore the -basedir argument.
You can create symlinks as a workaround (or reparse points on windows), but as this is per-mod-per-engine then its just annoying to do unless you want to spend a while creating some kind of fancy script to maintain them for you.

Tbh though, if a dll isn't backwards compatible (and didn't get renamed) then that library just sucks, or whoever built it does.


And then there's a few engines where all the important stuff is statically linked so that it works even with no messy dlls at all! 

Thanks, I now feel like a right knob that I typed all that out without knowing about -basedir. 

afaik, metl's concerns in #118 are still applicable to rasterization / occlusion queries. The visdata is supposed to be valid for all locations within a leaf's volume and all camera angles, so if you generate it by sampling a few camera positions (or just the center) and a few angles, and rasterizing, false negatives will be possible (homs/grey flash).

I still think it's a cool idea worth trying, the question is just how many views (camera positions/angle combinations) you have to render to make the false negatives a non-issue. I don't have any sense of how fast it is to render these 256x256 (say) views and doing the occlusion queries. If you budget 1ms per leaf, that would give 64 second vis time for a 64k leaf bsp. I wonder how many FPS for rendering these views would be expected on a decent graphics card.

e.g. this would allow vising ORL's latest pack which has unvised maps.

PS the "showing the other side of the map" bug is fixed as of v0.15.10 of my compile tools, as far as I know the only cause of that symptom was the way func_detail was added to qbsp. 

Was just lurking and spotted this. If there are issues using -basedir as Spike alluded to, you could always use Symbolic links, not sure what OS you're on but they're fairly easy to setup.