You wouldn't see me complaining if my crappy original Quake effects were replaced by some truly great effects that were undeniably better.

Nothing I've seen comes even remotely close to satisfying that statement though, so until then I'd rather look at the dull old stock Quake effects. At least I'm used to them and don't even notice them anymore. That's far better than being pulled out of my game experience when I shoot a shotgun and notice 'omg my shotgun fires bright orange sparks which spread out in a 500m radius and bounce of all the walls and floors 7 times'.

Or for a real world example, I'd rather wear a tattered old brown shirt, worn thin with age, which is at least comfortable, than to wear a nice new flouro pink tye-dyed shirt which has "I'm a wanker" printed in 72 point font on the front, and has blinking lights and LEDs attached to it that light up when I move...

...if you see what I mean. 

I wholeheartedly agree with everything you have said and wish to subscribe to your newsletter. 

"I can add back all the glquake particle effects as an option, but it can not be on by default."

Why not ? It gives the user more flexibility and for those that dont agree with your view, at least it provides an option. 

"Why not ? It gives the user more flexibility and for those that dont agree with your view, at least it provides an option."

Because LordHavoc said:

I've observed that there are many people outside the mapping and modding communities that often judge engines by their particle effects and nothing else, they reject glquake for looking 'too old', and they reject fitzquake as well because it doesn't have particle effects like they want.

and

I have observed that these people often reject engines that don't have most of their effects on from the beginning (some even go as far as to say per pixel lighting should be on by default, a request that I ignore), so none of these people would choose darkplaces if I disabled these things by default. 

he said he could add it back but make it not a default option (ie fancy effect on, but original effects can be enabled). 

fribs said it. 

Perhaps you could add a launch executable that sets the configurations through a GUI with a ton of expanatory material before start up; of course, that is what the Tenebrae team did, but I thought that particular device was effective. 

How about if in something like Darkplaces when you started the game you got a checkbox choice between "classic quake" where things are largely unchanged except for where they are undeniably improved (such as increased limits) and one for "mega 1337 Quake 2k6" where all the fancy effects are turned on? 

Mr Fribbles:
I would like to hear how you think the effects should look, I think it would be insightful to all engine programmers who may be reading this thread.

Many of the darkplaces effects are not how I wanted them to be, because of performance goals (like being faster than glquake particles most of the time), which have lead to a number of glowing blob trails and things that simply are faster to render rather than aesthetically pleasing.

I'm not at all opposed to changing darkplaces effects, I do think they are some of the most reasonable non-stock effects when compared to the other engines, but they are far from what I really want them to be, they are also rather difficult to control (developing particle effects in any game is 90% trial and error due to the intentionally chaotic nature of the effects).

Regarding the comments about talented artists designing effects, I find this statement rather insulting to my art skills, however I am strictly a texture artist and level designer, I do not claim to be a good 'particle effects designer' and do not think particle effects are much of an artform considering how much trial and error is involved.

Regarding the comments about 24bit textures that look like shambler dung, I am in complete agreement, this is why the darkplaces website screenshots are using stock id1 textures, they are simply brilliant textures. (exception: there is one batch of screenshots using qe1 textures, but only due to popular request, and they have a corresponding note above them about me not liking them)

HeadThump:
Yes except that's basically what the options menus are, which sadly people seem to ignore - and I don't think forcing the game to start in the options menu would be a good thing :)

Tron:
While everyone pretty much agrees on what 'Classic Quake' is, I think many people would prefer to have some of the options on, it's really more reasonable to go through the options menu (as long as the effects of the options are obvious), but you're right that choosing a basic profile before starting to change things may be useful. 

Where can I get this "Darkplaces for OS X" thing I hear about. The most recent source release didn't compile (missing vid_agl.c). A binary would be nice :) 

You can compile using make sdl-release, the native Mac OSX AGL/CoreAudio port is still in development, though it supposedly works in the latest beta sources, I'd trust only the SDL version at this time.

A local friend gave me an account on his OSX machine so I can compile darkplaces builds and put them in the normal release zips (as proper .app directories), I just haven't gotten around to setting it up, I may do this today. 

I've managed to bodge the executable from nexuiz into working, which will do for now.

I'll give the beta sources a whirl when I'm next back at this computer (a couple of weeks, at a guess).

Would vid_agl perform better than SDL? The performace of the darkplaces-sdl isn't that good here, though I don't have that beefy a gfx card. 

...to both groups (mappers AND coders) to exchange some ideas and contribute with each other. I really would like to have some feedback from artists to give some direction in the development. When I mentioned this thread on QuakeSrc.org, wasn't meant to bash anyone; my feeling was more a great surprise (and some disappointment, sure: as someone already said, we put a lot of effort on our engines). Yeah, I totally agree that 24-bit textures DOES NOT mean automatically better than the original 8-bit textures alone; yeah, a lot of engines have exagerated emphasys on particle effects (and as pointed out, without much if any artistic sense). As a coder, and I truly believe I am not alone on this, I feel a lot the lack of construtive feedback - especially from mappers and from texture artists. So, instead of mumbling about how ugly looks the orange particles, why not help us to make things look better (and if this really cares, keeping the Quakey look & feel) ?

To sum up, I believe that both groups need to talk more *CONSTRUTIVELY* to each other. Different views are inevitable (and a good thing), but we can work out that without need to bash each other.

So, I suggest to you guys to enroll here what you like and what you don't like in every engine you know. But remember, constructive criticism only, please. Saying "engine X's particles just sucks" won't help. I will sumarize and post your feedback, although I think you guys could pay us a visit at QuakeSrc.org with more regularity, too ;) 

Thanks for taking the time, extending the olive branch and all that. I'll give some thought to your request and post what I have that's useful. Maybe some of the others will do the same. 

1) SUBTLE particle effects. A single spark needn't light up the entire room. Infact, if you ask me particle effects should be almost unnoticeable. It makes me nauseous trying to play a game and being distracted by some tarted up glowing effects at the same time, and to be honest it just stinks of a coder who wants to be noticed.

So lose the bright colours [the dayglo green Scrag trails in Dark Places being one such offender], take some of the bloom/glow off and make them fade away much quicker [I'm speaking in generalities here].

2) Either get underwater caustics right, or lose them completely. Those rippling lights you get underwater are a distortion of the light from above, and as such should depend upon the brightness of said lights and their falloff. Underwater Caustics just look stupid in dark areas.

3) Detail textures and Bumpmapping: NO! The reason many coders scoff about the ID1 textures is because they've grown accustomed to this hideous distortion of the originals which completely overrides any definition they once had and conflicts with the shading that's been drawn in originally.

4) Coloured lighting effects around rockets and such should be toned down. A rocket shouldn't emit a bright orange light that illuminates a huge area. If you think about it, the only bit that's emitting light is the flame at the back, which for the most part will be burning so bright as to emitt a white or bluish glow.

5) So you've pilfered [sorry -- 'innovated'] ideas/tech/features from Q3A and Doom 3, now let's have something 'useful' such as physics, or the displacement brushes from Half-Life 2. That would open up plenty of opportunities for mappers and players alike. 

5) So you've pilfered [sorry -- 'innovated'] ideas/tech/features from Q3A and Doom 3, now let's have something 'useful' such as physics, or the displacement brushes from Half-Life 2. That would open up plenty of opportunities for mappers and players alike.

Do not EVER fuck around with physics of the Quake and QuakeWorld engines. The day I noticed that bunnyhopping was broken in Darkplaces was the day I stopped using it. Fortunately enough it has been fixed now so I can use DP again. 

I think he means stuff like accurately tumbling collision objects and stuff, not player movement :} 

Ok, you asked what particle fx us mappers want.

Here's my personal wishlist.

The option to choose between:

1) As close an emulation as possible to the original particle fx in WinQuake/GLQuake.

2) Whatever other alternative particle fx the engine coder wants to do. I honestly don't mind what they are like because I should always have the option of using the classic fx (see above) 

What Kinn said. 

I have stopped trying to give feedback to coders. I simply don't care anymore because I have FitzQuake and the stock id1 progs.dat--that's everything I need. Every time I've tried to point out problems or suggest improvements to coders it has been exceedingly frustrating and in the end nothing was changed. When I find a bug, it's my fault as a mapper. When I suggest an improvement, it's unfeasible, or it's not important, or I'm not qualifed to suggest something like that because coders know more about gameplay and I'm not an artist, or the coder comes up with a convenient but half-hearted excuse to not use it. When I point out something is not working well or doesn't fit in, I'm told "that's just my opinion" and the coder wants to keep it because he "thinks it's cool." I'm not talking only about engine programmers, either. When I try to point out logical errors, they talk down to me because I'm too stupid to understand basic mathematical operators. Whenever my opinion is so blatantly disregarded and stomped upon, I give up, I get spiteful, and I don't care anymore. I have all I need already, and I don't have to put up with people who are so disrespectful and lack basic communicative skills.

Now, it may be the case that coders get upset when I don't use things they have made, but I get very upset when people insult me because I won't use their stuff--or collaborate with them-because they're too obstinate to fix their stuff that doesn't work well or that looks atrocious.

I can take feedback, and I ask for it regularly. If you want to offer feedback on my work, go ahead. But do not complain when I offer feedback on yours--not if you want me to use your stuff. When people start taking into account these very reasonable suggestions that these mappers have offered, I may reconsider offering my own feedback. But until then, I can say with absolute certainty that every single coder I have attempted to work with has had more pride than is healthy for anyone to have.

frag.machine, I don't know you at all, so I don't have any problems with you. I appreciate your post and that you agreed with many mappers' sentiments. I hope you don't take this as an insult. However, this is how I feel about every coder with whom I have worked, and I don't see any signs of improvement. 

Make a func_wall2 that acts just like func_wall but is taken into account when lighting the level. This way all small details can be made as entities and they don't break up leafs and fuckup vis etc.

Nobody has ever commented on this. 

The problem with such a func_wall would be that you would be running out of bmodels FAST (brush entities like func_door, func_button, a maximum of 256). Unless I am not mistaken, adding an entity you are describing would only involved some QuakeC changes and thus, a custom progs.dat. However pushing the amount of maximum bmodels would also require engine changes. 

Text_Fish, Kinn: I'll be posting your suggestions at QuakeSrc.org. I honestly can't say about other projects, but I'll try to take what you've said in account in the upcoming versions of my engine (mainly the idea of a "classic mode" to turn off all extra bells & whistles).

R.P.G.: no hard feelings. I hope you change your mind soon though :D

bambuz: the idea is interesting, but as pointed out there are technical limitations. ATM I can't see a solution that does not break compatibility with stock WinQuake/GLQuake.

Thanks all for the responses and not turning the discussion in a inter-forum war :D. 

i'm not saying it's a good idea, but what you could maybe do is have them called func_wall2 in the editor, but when it gets compiled, the light program does the light calculations as suggested above, then renames the entity to func_wall... 

I don't think there needs to be a GUI frontend for Quake engines to allow for configuration, especially since that would be a pain in the ass to do for engines (like DP) that run across multiple operating systems. I think the perfect solution would be to have 2 command-line parameters in the engine: "-classic" runs the engine setting all cvars and other settings to values resembling vanilla GLQuake as close as possible (saving those settings into the CFG upon exiting the game) and "-fancy" that turns on all the bells and whistles and also saves the settings into the CFG.

This way you would be able to choose the option you prefer and start experimenting and tweaking your CFG from that point.