3d Skyboxes
#236 posted by Kinn on 2018/03/05 14:01:11
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.
Kinn
#237 posted by bal on 2018/03/05 14:10:17
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).
#236
#238 posted by mankrip on 2018/03/05 14:45:42
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.
Probably Already Stated
#239 posted by mjb on 2018/03/05 14:54:15
But new mappers entering the fray.
With Dumptruck_ds's tutorials I think that's entirely realistic! ;)
#240 posted by eukara on 2018/03/05 16:25:43
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.
#241 posted by eukara on 2018/03/05 16:33:42
The stage in question will look somewhat like this
{
map $cube:gfx/env/mountains
blendfunc blend
tcGen skybox
}
#242 posted by eukara on 2018/03/05 16:47:08
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.
I Hope You Feel Properly Embarrassed
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?
#245 posted by eukara on 2018/03/05 17:11:49
As I've said before, Q3 BSP supports skyportals, aka 3d skyboxes. So yes. RtCW probably used them...
What Is Even Happening In This Thread
#246 posted by anonymous user on 2018/03/05 19:43:35
People Are Talking About Improvements They'd Like To See In Quake
#247 posted by Shambler on 2018/03/05 20:55:07
#248 posted by mankrip on 2018/03/06 03:07:46
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.
Texture Loading
#249 posted by mh on 2018/03/06 04:53:23
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.
#250 posted by mankrip on 2018/03/06 06:54:30
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.
#251 posted by mh on 2018/03/06 08:51:24
Yeah, that would work better.
I Want To See...
#252 posted by Shambler on 2018/03/07 10:00:59
...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.
Shambler
#253 posted by Kinn on 2018/03/07 10:17:11
Just smear some Vaseline on your screen. I'm sure you must keep a jar of the stuff near your computer.
Bler
Unfiltered textures in TB are very helpful for when I'm doing some complicated (i.e. everything on a 45 angle) texture alignment.
Shambler
#255 posted by bal on 2018/03/07 11:06:25
TB already has a GL-filter mode, just no one uses it (for the reasons you already know... :D )
Sigh. Quake Ruined.
#256 posted by Shambler on 2018/03/07 11:30:05
[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
Shambler Needs More Pixels Not Less
#257 posted by Qmaster on 2018/03/07 13:16:49
#258 posted by eukara on 2018/03/07 16:40:15
Texture filtering in Quake was a mistake.
#259 posted by Shambler on 2018/03/07 16:42:41
Your conception was a mistake. Your mom told me as much.
#260 posted by mankrip on 2018/03/07 16:57:41
Quake with unfiltered textures looks great, if you play it in the originally intended resolutions. In 1996, 640*480 was the highest resolution that achieved playable framerates in most high-end machines.
I used to play it at 512*384 in a Cyrix MII-300 in the early 2000s. Had a solid 12 fps which was surprisingly enjoyable, and looked pretty good to me.
Nowadays, its texel-to-pixel ratio at the highest playable resolutions is poor.
|