News | Forum | People | FAQ | Links | Search | Register | Log in
Quake Engine Features Wish List
A project to collect ideas and discuss modifications to Quake source ports that would bring innovation and quality of life improvements for mappers. One of the goals would be to encourage and coordinate standards across the different existing source ports. Using GitHub should hopefully open up the project to interested coders outside of the func community.

This is an attempt to create a centralized place for engine coders to note what features mappers would like to see in future source ports or updates. Read the original thread here:

Right now, it's a simple issue tracker with comments but it will likely become much more with expanded involvement from the community. I'm not a Git expert so help would be appreciated.

If you would prefer not to make a GitHub account to post there, feel free to post here and I will add an issue with a link back here.

If you would like an invite to be on the team post here or email me your Git username and I will send an invite.
Things Wot I Want In Quake As A Player And Sporadic Mapper. 
1. Entity key-value listings as per AD in TB.
2. Entity state stuff as per AD.
3. Ersgan quality subtle and faithful improved definitely textures.
4. High quality faithful monster replacements as per the AD shambler.
5. Slightly nicer flame models but retaining a similar style, not some weird fuzzy bloomy shit.
6. Coloured fog per area without hacks.
7. Gamma control that slightly increases contrast and saturation along with brightness to compensate for the washed out high gamma issue.
8. Subtly improved water with gentle surface movement and refined texture.
9. Ability to blend textures into each other across a join (wishful thinking?).
10. There might be more, if in doubt think "subtly improved quality and quake-faithful" .

I have no idea whether these are engine, editor, or game related or whatever. I like Quake tho. 
Lmao But Nice List 
Lol wtf a monster model is not an engine.

Fog volumes and texture blending are manipulated by shaders in Q3. It would seem more appropriate to port Q1 monsters to Q3 for some kind of single player Q3 mod.

Q3 mapping with terrain and texture blending (actually from Q3:TA), where the artist essentially has to code the shader and specify the textures, is significantly more demanding than Q1 mapping.

Which is why modern engines has node system so artists can design shaders themselves. I'd like to see a node based shader system in Q1... ... ...
But I'm gonna wait for hell to freeze over first cause none of this shit is ever going to happen. 
Lol Wtf Did You Even Read The Last Line 
I have no idea whether these are engine, editor, or game related or whatever.

Emphasis on the "whatever". Also this thread is derived from a "how to attract coders to the Quake scene" thread so I presume general coding might be considered. 
All of the above could be done. Some engines already support different model formats, so it's a matter of content more than engines.

I think there's a lot that can be done with water and fog that doesn't break compatibility and art doesn't violate the esthetics.

Not sure about blending textures though. But a low res masking with multitexturing could be an interesting addition. 
@Serious anon guy
Since you can run Quake3 in FTE, maybe this engine already suports shaders, fog volumes, texture blending and terrains... but i never played Q3 with FTE, so i really don't know... 
Treading Carefully 
There's an argument for saying that 99% of the features that will ever be requested here can just be replaced by the sentence "turn the quake engine into the quake 3 engine", and that's not actually too far off the truth.

Darkplaces and FTE both support Quake 3 bsp and md3. Wraith: Age of Onions is built on Darkplaces to take full advantage of this.

The 2 feature requests currently in the github thing (lit water support and md3 model support) are again Q3 things and you can use them in DP for example.

I think I personally look at the quake engine and see something which is obviously ugly and bad (fullbright water and horrible jelly models preventing you from making big boss monsters that don't look like shit) and then say "would be great if we could fix this in quake 1".

For me I feel like I don't quite want the cross the fine line that has "fix something obviously sucky about quake" on one side, and "make everything like quake 3" on the other. 
Another Example 
Quake's animated textures SUCK. Making a waterfall using animated wad textures looks like crap because the framerate is so low. Also, switching the texture on a brush model is extremely limited - you can currently only toggle between two texture states.

Now, I could put in a request that says "full quake3 style shader support lolol", but really I just want to fix the obvious suckitude with those two existing quake features.

I'll need to have more of a think about it, but I'll probably submit some suggestions along the lines of making quake's existing animated texture support less shit. 
Texture velocity vector could be something to consider. It'd be a simple per surface value, not a complete shader system. 
Standardisation Of CSQC Specs Across Engines 
CSQC needs to improve drastically, I believe the way it is done can be better thought out. Maybe a higher level API to handle UI specific things?

@Kinn, we could also have a cvar to increase overall texture framerate speed and even maybe texture animation interpolation, or support for UV coordinates animation.

I also agree that we should think of things with a "make a better vanilla quake" mindset instead of adding "next gen" stuff until engines turn into the Q3 engine or into DarkPlaces. The doom community makes a beautiful distinction between "new age" doom with models and polygons and the "vanilla" experience, and the vanilla experience is way more valued as it should since the game is supposed to look like that.

This thread is a great idea anyway as a place to bounce ideas around before determining whether it’s worth adding to the github thingy 
I have idea for maps with cool pre rendered video cutscenes. 
Bink/Smacker requires a license, no? In order to preserve Quake asthetics Huffyuv or Lagarith would probably be a better idea. 
I think Bink is proprietary format, so I should think Lagarith or mp4 playback would be awesome feature.

You can make Quake animation and render in Mental Ray or Eevee then play video in game. Imagine Nehahra with better cutscenes. 
Nitpicky I guess but mp4 is just a container. It can hold pretty much anything, but it typically stores h264 (which, probably, will be superseded by h265/hevc at some point) and an audio track. But h264 is not only covered by patents but also lossless (huffyuv and derivatives aren't). Quake output is not really high fidelity so huffman-based codec should work fine. Maybe. 
That said VP8/VP9 is probably the best option if one were to stream videos since it wouldn't require transcoding and has some HW acceleration support (vaapi supports VP8). 
lit water:
Compile your maps with that argument (at least with ericw's tools) and you should get lit water as a result, at least in FTE+DP. QS does not support it still afaik.
Its backwards compatible so start using it and maybe other engines will get the idea a little bit sooner...

animated textures:
texture names have 15 chars to express everything, which isn't really enough to have x+y speeds etc while trying to avoid breaking other texture prefixes.
so the options are to just use q3 shaders, make some more limited clone of q3 shaders (or rather, more normal material descriptions), or to do some weird manipulation of quake's miptex lumps and fix up the qbsp to not mangle the extra data.

quake3 standards at least have an existing sample implementation.
the biggest issue with q3 is that eg q3bsp implicitly requires q3shaders, etc, which makes it quite messy to implement into an existing q1 engine.
on the plus side, q3 tools already exist, and there are q1 engines that support the formats albeit with varying levels of compatibility.

ultimately, using existing formats like q3's is the only option if we keep on forgetting about feature wish lists for tools too...
(or for that matter, requests for eg pbr textures instead of blinn/phong ones. we at least already have some replacement md3 models for engines to use)

trying to standardize csqc now is to give up and mandate DP's clumsiness.
In terms of higher-level apis then yes, QSS's implementation is higher level, its also more limited. On the plus side the qss devkit contains a wrapper for dp so that you should be able to get the same mod working in fte+qss+dp. Let me know if you have more specific complaints.

video playback:
fte+dp have some support for decoding anything that ffmpeg supports (license/patent/etc willing).
Assuming its all set up right, you can 'just' use the playvideo command to play stuff.

alternatively, you should also be able to use 'videomap' in a q3 shader to play your videos on walls/models/csqc's drawpics/etc... 
Some Simple Things. 
-Get some way to use more than gold/silver keys in a map without relying on Runes.

This is just for consistency if nothing else. I like it when the Runes are special and not used to open a third door. That just annoys me.

-Being able to change the key set if you so choose

Being able to change keys for a map would make for more variety in map aesthetics.

-Expand weapons/bestiary list

Being Quake faithful's great, but it'd also be interesting to be able to fight other enemies or use different weapons sets like Malice for example.

I don't want to impose too much here, but these minor things would be fun to have access to. 
When Spam Buries Important Things 
I don't know if this is engine or progs related, but i really like to see maps in quake using trees and foliage, like in those Valve games:
or like in "Pyramid of the Magician" Q3 map:

I think with plants, trees, grass and general foliage support mappers could make new/fresh looking awesome maps. 
These are best made as mdl models, and you can now use alphatest (aka "fence") textures in mdl to get leafy stuff looking ok. You could even animate the mdl to get some swaying going on.

HOWEVER, where all this falls apart is in the lighting integration.

Mdl models never look integrated with the environment with the current state of the q1 tech. The light compile would have to recognise static mdl meshes, and not only have them cast shadows onto the rest of the environment, but it would also need to generate special lightmaps which the engine could then use on the static mdl models. It would be a fairly involved compiler+engine feature.

I once had a fair stab at making bsp-based trees, but it's probably the worst possible thing to use bsp for and I gave up after all the glitches and issues and hacks I had to do, which made it more trouble than it was worth. 
I’m Actually Interested 
In hearing why are BSPs so ill-fitted to host trees, that is causing all these glitches you mention? 
The bsp algorithm starts to really creak when you have a lot of detail involving faces at arbitrary angles. You've seen HOMs right? Where a face is dropped and you can see the grey void. When trying to make a tree that's slightly more attractive than something from 1992, the probability of the bsp process b0rking and you getting these dropped faces is rather high. The bsp algorithm just isn't really cut out for dealing with arbitrarily detailed and complex mesh geometry. You're in "here be dragons" territory in terms of bsp tree complexity. At the very least you will need to make each tree a func_wall or func_illusionary so the bsp tree mangling doesn't also affect the rest of the map (which can result in odd PVS glitches amongst other horrors).

I gotta scooch now but I'll elaborate more on the mdl idea later. 
Do You Happen To Have 
some example maps of way back when you attempted to create those BSP-supported trees still available? I’d love to see these artifacts and glitches by myself, try and understand what’s going on within the engine with them. 
Foliage would probably require additional lighting mechanism in order to look acceptable.

First: in order for trees and what not to cast shadows, some simplified impostors/low LOD models would be used in vis to cast shadows on a static geometry.
Second: Vis would probably need generate low frequency lighting information (spherical harmonics every 64 units or whatever) which could be used for foliage shading. This way shadows would not be baked onto models and swaying trees (or grass) wouldn't look too jarring. 
Now that I think about it: SH would also affect trains and enemies plus SH exported out of the bsp could serve as a rough lighting hint in TB. 
Would love post-processing options. Even basic color tinting to high, low, and mid values would add so much power.

Proper height fog would also be nice, instead of just distance fog. 
progs_dump 1.1.0 RC3 has persistent keys so you can use multiple gold / silver key doors with the same key (as in DooM.) 
Yeah Ik That 
I mean being able to have different kinds of keys instead of multiple gold or silver keys. It's something that I think would be cool. 
some example maps of way back when you attempted to create those BSP-supported trees still available?

I had a look but I only keep the last 5 iterations of any given map, and that old stuff has long been cast into the digital abyss.

To reproduce, just go as far as you can with obj2map buggery of organic mesh structures and see how far you can get before it starts causing problems that make you think "this is such a dumb thing to be doing using existing q1 tech". 
Engine Features And Mapping (progs) Features Are Different Things 
So let's keep in mind that engine features should be thought out with engine standardization in mind while mapping features only rely on progs distributed by third-parties.
Some mapping features are not worth to "hard code" into engines imho 
Yeah the idea is to come up with ideas for obvious (and realistic!) engine features that would get a lot of use and deserve to be widely adopted on all engines, not just the niche "eye candy" engines that none of the mappers here seem to be interested in. 
+1 For Height Fog 
That sounds like a feature that would sit great within the existing quake vibe, and in fact enhance it, like the distance fog does. Literally every map now uses distance fog and I would imagine height fog would be similarly popular. 
Is this different than volumentric fog or an updated way of referring to the same thing? 
While height fog could fix this a bit, i would be interested in seeing real fog, one that needs to be lit and in which the increase of fog per distance and the formula can be changed like with lighting attenuation, as it is now it looks cool, but the fact that has nothing like real fog save if i make it real thick or light the entire map strongly has made me not use it ever, even after trying on several maps.

On the other side i see the current one good to use as a sandstorm/heavily concentrated dust, or as darkness to make it look like the player lights around. 
Fog volumes could also be nice, but that's different.

@cocerello are you talking raymarching fog? Or some other tech? 
Rain, Thunderstorms And Lightnings, Snow, ... 
What I would like to see in Quake, are rain effects (like in AD Sepulcher under QS Spike), realistic snow storms, thunderstorms and lightning effects. More realistic fire and smoke...

And better looking trees and bushes. 
Some Advice 
Can you lot stop beating around the bush and just rename this thread "Stuff we want in Quakespasm because it's not like any of us are ever going to give a shit unless it's in Quakespasm".

May as well at least be honest about it. 
"honest" says the anon 
As I've said a number of times now, it's "Realistic ideas for engine features that would be broadly popular amongst the contemporary mapping community and thus have a good case for being standard across all engines in the same way that coloured lights and distance fog are".

Not sure if thread titles can take that many words.

May as well at least be honest about it.
Thanks for that advice, "anonymous user". :ohtheirony: 
beaten by dumptruck! 
<----- Skybox Stuff (Sheep == Cloud) 
Rotating skyboxes?
Multiple skybox layers (e.g. cloud layers) with ability to independently rotate the layers?
Lerp different skyboxes over time?

Just shooting the shit here... 
Ah Yeah. 
I forgot about that, was totally on my list to ask for! 
I do not know what would be required, but probably not much of a change, but i do not know much about code.

I am talking in results' terms, so i will use examples instead:
- In my last map, i put on a side of a big room a hole from where an enemy will ambush the player and another with some items, so i kept them in the dark so they would be harder to spot, but with the fog on, those holes are lit by the fog because it is always lit like water, making the hole stand out with light instead of being hidden. And there is no way around save for making the fog almost non-existant, as if i darken the fog it will no longer look like fog and i would need to turn it almost black to achieve it.
Another side of this is that darker parts stand out in general more than bright with the fog on, so the fog needs to be dark like dust clouds like in most Quake maps, or to be used to blur the farthest parts of the map like in honey.

- Another is that fog is a lot thicker in real life and more sudden, and with this linear attenuation, it end up sticking out more in the corners (because they are further) and not working for anything else apart from blurring the horizon, or block most of the line of sight if made a bit thick. Also if intended to be used as fog most rooms need to be of similar size and the rest way different and even with that it still does not look like fog. If we could change the attenuation (best would be something like a logaritmic formula where the distance at which it begins can be changed), there would not be even a need for height fog or fog by area, as we could work around it to make it look as intended in each room with a global key.

If i think about it, i still have not seen a Quake map with fog, only blur in the distance, dust in the corners, or tricks with darkness like OTP did in mapjam1. 
I've added new request that would benefit from input of mappers. It boils down to "it would be nice to have a single map that works on engines with and without new features". Technical details are here:

On the topic of fog - I'll have a look at the ability to define arbitrary volumes in the map and specify what should happen in those volumes (e.g. sepia tint; green fog within this volume; etc.). Initial implementation would make it impossible to have crossing volumes (well, behavior would be unspecified) but ultimately I think that falloff around the volume edges and interpolation between adjacent/crossing volumes would be a must. Does this sound like something that directly answers your needs? 
Engine feature requests typically fall into 3 categories.

1. "I really should be using the Q3/HL/whatever engine but I don't want to for some reason. Can you port this feature from it to Q1 so that I can continue not using it?"

This is an arms race nobody can win. Better off working on resolving the reason why the mapper doesn't want to use the other engine.

2. Stuff that's actually content rather than tech. No further comment necessary.

3. Vague, ill-defined stuff; it must be "Quake-ey", if must be "subtle", it must be "tasteful", but it's never actually clearly stated what it actually is. This is also a waste of everybody's time as chances are nobody's going to be happy with the end result.

Getting into detailed discussion about how something might be implemented and how it might interact with light/etc can be useful, but it can also be useful to just throw a working prototype together and see how it looks. Chances are it might look just fine, but even if it doesn't you've now got something to work from, rather than spending more and more time on complex and arcane discussions with nothing to show for it.

The best engine features, the ones that last, are in response to real problems that mappers are actually facing. "How do I deal with format limits without compromising my vision?" "How do I have animated lightstyles on the entire world without performance that sucks?"

Pie-in-the sky wishlists are fun and novel ideas that might otherwise never happen can and do come from them. But mappers - people actually, currently making maps - also need to be talking about what problems and frustrations the Q1 engine is causing for them.

My challenge is: list the one major problem you are having. Don't say what you think the solution is - the actual solution might be something completely different - say what the problem is. If somebody needs to ask "but what would this actually solve for you?" you're probably doing it wrong. Be as specific as possible. Help engine people to actually understand what you actually need.

Enough people do that and we should start getting a nice idea of what kind of engine features are needed to be more useful to mappers. 
Well, firstly I disagree with your "3 Categories" - the most common category I think is this:

"I think it would be awesome if I could just do this one, particular, extra thing, which Quake currently doesn't do, which would really get me excited about making new stuff for Quake."

These people have 99% of what they want in their engine of choice, and are just wondering if they can convince someone to implement that extra 1% of stuff.

They don't want to make a massive Q3 total conversion, or a HL total conversion, they just want to carry on making Quake stuff but with a little extra "something".

As for the second part of your post, I agree with the basic gist of it. An engine request has pretty much zero credibility unless the mapper has thrown something together to prove that he can talk the talk and walk the walk, and a programmer takes a look at it and thinks "yes this rather nifty content that actually exists would really benefit from that one extra thing that the creator would humbly like". 
I'll take the bait.

I am frustrated with the music limitations in id1. I need the ability to play a music track with a unique name. 
Examples Of Features Imo 
Feasible and "correct":
- Add/improve support for X base file format (mdl, iqm, midi, mp3)?
- Add support for a Y way of incrementaly adding mods without having to fuse and recompile a few mods together
- Support for Z basic feature in CSQC

Infeasible and not quite a fit:
- Add support for X flashy effects, shaders, physics
- Add models or Y mapping capabilities for vanilla quake
- Support for Z game engine features in Quake

I think the infeasibility lies on whether the feature should be something particular to a sourceport or something that can improve/add to quake engine across all engines (such as tooling or better control over existing features). Or even extending existing features to allow basic game features such as an user interface. But when you go into the are of flashy effects, models or brushes you should look into engines or mods that support that.
I know it can be a gray area sometimes but I think the "vanilla" mindset should overcome the desire to add that-new-thing-that-engine-or-game-has.
Take a look at Doom foe example. ZDoom is treated as the standard, but it won't support advanced lighting effects, 3d models, volumetric fog or state-of-the-art particles technology, or shaders or anything. GZDoom on the other hand support a number of new features, so users are free to pick and choose.

I think we should think more of:
1) Make easier and more attractive at some level for new modders and mappers to use Qengines
2) Make it compatible across all engines, trying to standardize as much as possible implementations and specs
3) Don't bloat up the "base" engine features with stuff

That's my opinion though, you're all free to disagree. 
My personal wishlist leans toward standardized features like:

- lifting dated memory/count/range limitations
- HUD/menu setup and flashy effects accessible with API expansion (e. g. additional params for particle generation style)
- water transparency, splat decals can change the gameplay, should be mod-controlled && map-controlled 
Pak Files And Stuff 
How about this?

You could open the console and do something like
-load pak99.pak
or a pk3
maybe even do like
-load pak99.pak/progs_for_mod_testing/knight.mdl
to replace an mdl already being used
Maybe even do something like
Imagine a quick model replacing thing to cut down on a bit of time.
Just fire up your engine and load a folde or pak containing a model and then start a map having an entity with that model. 
Re: Pak Files And Stuff 
+1 for that. The Quoth Map Paks basically work on that principle - the map plus all the resources are stored in a single pak file.

In order to make it work without engine support I wrote a batch file that renames the file to pak3.pak, but the idea that engine support could make the method slicker was something I had in mind. Dynamically swapping a map pack in/out would be nice, or just having a GUI to select the pak files. 
Well Well Well 
finally for the firs time in my life i have suggested a valid/appropriate suggestion.
better work on it and suggest better ideas...or make it myself. 
The chance to create colored lights (.lit) in game, like Darkplaces do with RT lights. Same for fog, rain etc.. 
Wow The Spam

But anyway would this be possible? 
q3bsp + lightmap lightstyles exists (fbsp).

DakPlaces doesn't support it but I think FTE does. 
Not what I mean: I mean creating them DURING game (darkplaces can do it for RTlights, but not .lit) 
1 post not shown on this page because it was spam
Post A Reply:
Website copyright © 2002-2019 John Fitzgibbons. All posts are copyright their respective authors.