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. 

I've saved some especially for you, there's a secret sub-channel specifically for that stuff :) 

How many camera positions does vis compute anyhow? Or does it figure out how many positions to account for and only compute those?? 

It's funny how a lot of people's requests are already possible or exist. We need this sort of thread more often to help spread the word. 

Who the fuck says an engine needs DLLs?

WinQuake doesn't need DLLs.
FitzQuake 0.85 doesn't need DLLs.
FTE doesn't need DLLs.
Mark V doesn't need DLLs.

The idea of needing DLLs is a shitty LINUX concept.

LordHavoc was a Linux user when he made DarkPlaces. The original Quakespasm authors (not ericw) were Linux users.

Linux ideas like DLLS and OGGS should be rejected and shunned.

NOT normalized, like a dopey person would do.

Don't be a dopey person. I'm just saying. Who the fuck said engines need a folder full of shitty DLLs?

Well -- answer: Linux people who do not use Windows.

In fact, in the compile tool chain for Linux friendly engines there is a static linking option that would eliminate the DLLS.

Demand better! Don't buy into the "need to have shitty DLLs" way of thinking. It's a lie.

/Against my better judgment I click submit! 

That would make updating so much nicer, as well as having multiple engine/single directory coexistance. 

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

no worries, the nsfw channel's hidden now 

is some sort of new visual thematic. It seems like the past 4 or 5 years have been dominated by mashups or updates of old themes. I'd like a comprehensive new texture-set that stands up on its own and looks just as good in a vanilla engine as it does in one with advanced features. 

DLLs are, of course, a Windows (and OS/2) thing. On Unix and Linux you have .so files. The concept of shared objects and libraries is present in any modern operating system. A vanilla install of WinQuake comes with:

GENVXD.DLL
PMPRO16.DLL
QUAKEUDP.DLL
WDIR32.DLL
GETINFO.DLL
PMPRO32.DLL
WDIR16.DLL

No idea what connection to Linux you see there.

Also, as someone with a Xiph.org connection a few years ago, I hereby kindly request Ogg Vorbis support in all engines ;-) (or, perhaps even better, Opus support - awesome for music, sfx and voip). 

Yeah, was gonna say WinQuake also had its fair share of dlls too.

Anybeans, now that I have discovered the sheer wizard magic of -basedir, I'm keeping all my engines quarantined in their own individual folders and the dll thing doesn't bother me now. Others' mileage may vary obviously. 

reading the documentation i see that AD already has what i said in #42 about scrags, and possibly demons

the third thing would be level-aware monsters, but in some ways they would start acting like multiplayer bots, so i don't know...