Thanks for the feedback, even though your feedback differs from other feedback I have received and I had reason to question to your judgment from the start, don't think for a second I won't take your feedback into consideration.

I'm hardcore that like where I consider the feedbsck from all.

+1 for rising to the occasion.

OTP. Let us hear your opinion. 

Yeah, I am .. well .. it's 17 beers down at this point.

A sincere thanks for your feedback.

I get what you say about the mouse wheel, but I strongly disagree for reasons that are too detailed for me to explain right now (but make perfect sense -- either you honor the mouse position or you don't and in that case you must take the mouse position over the mouse wheel for behavior reasons).

I reiterate that I do respect you. You manned up. I always respect anyone who manned up. You did. Case closed, you have my respect.

I wanted to convey that. 

That was an interesting last 20 posts....

I wanted to avoid the toxic stew of the unrealistic weird crap in this thread.

Too much crazy talk for me in this thread

Oh okay then.


My "bad rants" are purely philosophical perspective and conservative prudeness, otp.

My "bad rants" are impersonally "perspective oriented", even here.

...

Baker + 12 beers > bigger morale compass than otp.

quit being such a dick for no reason maybe?

...evidently so.


You are a big "stick-in-mud-conservative"

I'm not entirely sure about that, given that half the old skool maps I play on stream I comment with "This would be really nice with some subtle fog and coloured lighting and AD-style breakables", and that I have started a thread about modern improvements to Quake. I suppose I am a big "gradual-improvements-and-harmony-with-current-Quake-style conservative", tho.

Anyway, I tried the mouse-driven menu in MarkV, I concur with Spud - it feels exactly like a mouse-driven menu and if I actually wanted a mouse-driven menu then this is just the sort of mouse-driven menu I'd go for. HTH. 

"Anyway, I tried the mouse-driven menu in MarkV, I concur with Spud - it feels exactly like a mouse-driven menu and if I actually wanted a mouse-driven menu then this is just the sort of mouse-driven menu I'd go for."

Thank you for taking the time to try out the mouse-driven menu, I invested a lot of time and effort in it.

I'll take this as a good start for today.

Perhaps, tomorrow I hope to win your heart and your soul completely over. I may not have entirely accomplished this today, but I will take that I at least partially won your over.

That will have to do for now.

I appreciate your feedback and thank you for taking the time to do this, Shambler. 

Based on me barely having a total of 17 beers-worth of alcohol in the last 2 months.

Mouse-driven menus - never felt a need for it.

Improved AI - why not, I wouldn't mind it if it's done well. Not a fan of uber-strafing bobs and nehahra enemies, and z-aware ogres have to be used sparingly, but some better chasing AI could be pretty fun if used well. Like everything, introduce it carefully. Also better tactical negotiations between different enemies could be funny as long as it doesn't override infighting.

Real-time lighting / high res textures - both completely out-of-place and jarring with the current level of detail and especially the current Quake models. However these things are constantly improving and if/when all the Quake models are improved and a higher level of design / detail becomes standard (subject to mappers being able to do it easily / comfortable), then both of these more advanced graphical effects would be pretty welcome.

I've said it before and I will say it again:

Subtle, incremental, careful, and harmonious improvements to Quake's graphics are great

There's already been a lot of good stuff added: coloured fog, coloured lighting, breakables, transparencies, cobwebs/vines, particles, the new Shambler model (not perfect but I like it and it does fit in) etc. All of these have been small changes that still fit well with the relatively crude models / texture resolution / detail levels, AND they have often been used really nicely and carefully by mappers to enhance their maps. Hopefully there is more of this to come, and in time bigger graphical leaps like hi-res tex, RT lighting, soft smoke etc, will be able to fit in well too. 

I'm tempted to add a big laundry list of stuff, but I'll just mention one thing for now.

- Some kind of thing that works as follows:

Create a brushmodel, place it in your level in a nice position, and flag it as "always draw". Now, throw sky brushes around to seal all your rooms in a sensible "I understand vis-blocking" way....but...plot twist! Wherever you see sky, you can also potentially see your special "always draw" brushmodel, drawn in front of the sky but otherwise sorted with the rest of your geometry.

This would allow the creation of town / city style maps with cool skylines that don't make the engine draw literally the entire level at once.

To make it more optimised you could even give the mapper ability to turn it off in places where you don't need it. 

Keyboard focus should not be tied to mouse focus. I'm not going into the specifics, but there are good reasons why all operational systems' GUI keeps both focuses independent.

All major operational systems have user interface guideline documents describing what makes an interface to be good. From the ones I've read, the Microsoft one was the best, despite their product still having major design flaws. There's also the Apple one, and some others from some Linux distros.

Anyway, for Quake itself, in which mouse aiming has become the main control scheme, the purpose of a good mouse-driven interface should be to remove the need for the user to switch his/her right hand from the mouse to the keyboard. Just that. The mouse should enable the user to do anything that the keyboard would require his right hand for, minus typing text.

So, the main measure of good mouse-driven interfaces in Quake should be that the less right hand movement needed, the better. Arm injuries such as Carp Tunnel Syndrome are very real and some players have them, so the developers must take this kind of issue in consideration when designing their UIs.

User interface design is not a subjective mysterious art. 

- More widespread adoption of lit water (cough, cough QS)

- FTEs "software banding" option adopted/copied in more engines (cough, cough QS). Quake feels too sterile without it. 

*carpal tunnel syndrome, not carp. 

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.