You're describing "3D skyboxes". AFAIK, the Source and Unreal engines supports that. 

Do those work with objects that are still very much part of the level though? Say I have a church spire. In one "room" of the map, the church spire is placed as very much a physical part of the room, like any other brushes.... it's just this particular object would get flagged to also be drawn in other "rooms" in front of the sky faces. 

No that would not work in Source/Unreal skyboxes, which basically just draw the contents of the sky-room as really big. What you're describing sounds kind of clunky to setup.
Having Unreal type skyboxes would be neat though, that's for sure, and it's purely visible so kind of backwards compatible (engines not supporting it would just have the normal sky or skybox). 

Hmm, in that case the objects wouldn't be part of the skybox. Getting such a thing to work could be tricky.

We already got visblockers, and your suggestion needs the inverse — a vis unblocker. Also, depending on how the engine handles skies, things can get complicated. 

But new mappers entering the fray.

With Dumptruck_ds's tutorials I think that's entirely realistic! ;) 

Q3 BSP supports skyportals (for things such as 3D skyboxes)

For The Wastes I pushed Spike to add support for cubemap layers in FTE's sky shader stages. That way you can have a scrolling cloud layer (or 2 or 3...) in a shader and overlay a skybox on top of it. Like a mountain landscape or something. That will get the Unreal effect.

In the end if you want more fidelity like that, pretty much everything is already doable in the Q3BSP/Shader world. 

The stage in question will look somewhat like this

{
map $cube:gfx/env/mountains
blendfunc blend
tcGen skybox
} 

Thoughts on mouse-driven menus in Quake:

Retrofitting the qmenu is not the most ideal thing. You can get it to feel somewhat okay, but it will never beat a design that actually is designed around the input method.

Simply being able to click on options that were previously able to only be selected with a keyboard does not make the menu usable for mouse driven input.

A good mouse driven menu allows you to jump quickly from one place (that was deeply nested into sub-menus before) into another place with just one click, while still retaining a sense of order. In the case of Quake, that would require dumping menu.c into the trash.

Unreal used to have a very Quake/Doom ish looking menu, but with Unreal Tournament they realized that people actually wanted to move around the menus fast and have a better overview over all of the options available. This was then carried over to Unreal Gold and that's how most people see it today. It was a drastic change but a needed one. 

in the morning, Baker. 

isn't like RtCW had 3d skyboxes? I vaguely remember seeing some kind of screenshot or something showing small scale far-away environment, later rendered before level as if player in the centre of it? 

As I've said before, Q3 BSP supports skyportals, aka 3d skyboxes. So yes. RtCW probably used them... 

 

 

Some people complains that searching for replacement textures through all the possible paths from all the different standards takes a lot of time under Windows.

And then I remembered that when I started expanding the number of savegame slots to 100 saves in the Dreamcast version of Makaqu, it also resulted in massive slowdown when scanning for saves. The VMU interface is freakingly slow. But there was a solution.

When you search for a specific file, the operational system will read each file entry from the specified location, until the desired file is found. This is fine when you just want to load a single file, but it's idiotic when you're actually going to load many files from the same location.

The solution, in the Dreamcast case, was to scan each and every file entry from the location only once, in an unordered fashion (the physical order in the filesystem), while checking every one for compatible savegames. The logic is simple: If the file you want is physically the last file in a filesystem location, the OS will scan all file entries from that location anyway. Subsequent searches for other files from the same location would make the OS scan the same non-matching files multiple times, resulting in lots of redundant work.

I bet a similar solution would work under Windows. Linux probably caches file entries in the RAM automatically to prevent redundant scanning of physical storage devices. 

You can enumerate paths one time only at startup then only search the paths that actually exist when loading textures. Sort a PAK file directory and binary-search it. Use the native API which has faster calls for determining if a file exists rather than putting everything through stdio.

The point is, you can be a little intelligent about how you approach problems and it doesn't require creating hugely complex code. 

It's better to do the path enumeration at the beginning of map loading, in case the user alt-tabs to add more assets without closing the engine.

I often add more external textures and reload the map in-game when mapping. 

Yeah, that would work better. 

...TB including a GL-filter mode as default so when we're watching streams of people making otherwise awesome looking maps, we don't have to have them ruined by shitty square pixels everywhere when the mapper is zooming around in and out of brushes.

Also I want to see the return of Baker once his hangover finishes. 

Just smear some Vaseline on your screen. I'm sure you must keep a jar of the stuff near your computer. 

Unfiltered textures in TB are very helpful for when I'm doing some complicated (i.e. everything on a 45 angle) texture alignment. 

TB already has a GL-filter mode, just no one uses it (for the reasons you already know... :D ) 

[10:23] Kinn: @Shambler - are you sure that your blurry vision quake mode doesn't just make the surfaces of the world just appear all smooth and sterile and devoid of life?
[10:25] Shambler: i don't have blurry vision quake mode, i have smooth vision quake mode
[10:25] Shambler: and generally to avoid "sterility and devoidness of life" in any imaging situation, my first thought isn't "add lots of little squares like a mosaic"
[10:25] Shambler: unless, of course, i wanted a mosaic
[10:25] Shambler: which i don't 

 

Texture filtering in Quake was a mistake. 

Your conception was a mistake. Your mom told me as much.