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. 

The basic problem is Dark Places starts up in 32 bit per pixel mode, and for low end machines this chokes the frame rate, and you have to spend several minutes slowly changing the configurations in screen as each cycle update runs through at molasses speed.

Once 32 bits per pixel is changed to 16 bits, it does speed up to a normal clocking speed and I can use Dark Places for any Quake task.

It isn't a big problem for me as I usually just edit the configuration file before start up if I need to do so, but I could see someone that isn't familar with Dark Places getting the mistaken impression that DP is too next generation to operate on their machines. 

I must disagree about func_wall2, it should be a field in a normal func_wall entity, not a new entity, because a new entity won't work with stock id1 progs.dat, and this is purely a lighting compiler issue so requiring a new progs.dat would be a bad idea.

I don't worry about this as much anymore because I mostly play with realtime lighting on, so I just use the id workaround if I'm concerned about lightmaps.

id workaround: place func_walls such that there are no lights shining out from behind them.

note that using func_walls for detail in a room is just a workaround for another q1bsp limitation, I'd recommend q3bsp instead as it can handle this properly. (which is the subject of this thread)

I don't use func_wall for detail, high bsp leaf/node counts don't matter much to darkplaces, and other engines can be similarly optimized.

Big tip to engine coders: ditch RecursiveWorldNode, build a list of surfaces visible in the current pvs each time the view leaf changes, then just R_CullBox the surfaces each frame, or if you want even more performance merge all the surfaces into one triangle mesh and skip the R_CullBox, so each frame you're just doing one glDrawRangeElements call per texture in the scene, this gives jaw dropping framerates in q1bsp. I haven't implemented this method in darkplaces yet as it uses additional portal culling (which is view angle dependent unlike the pvs), which is how it gets such good r_novis 1 performance compared to other engines, and this additional culling matters more in rtlighting mode. 

The only graphics cards I know of that can't run 32bit color are 3Dfx Voodoo1/2/3/Rush/Banshee, ATI Rage LT Pro (the normal Rage Pro can run 32bit), and Matrox G200, and very few people still use these cards, so I default it to 32bit since everyone else can run it quite playably at 32bit color.

Use -bpp 16 to start it in 16bit color, and this is saved to config so you don't have to do it very often (just when you play a mod that has an existing config for another engine).

There are 4 reasons DarkPlaces prefers 32bit color: 1. stencil shadows don't work without it
2. high per pixel lighting doesn't work in 16bit on cards without OpenGL 2.0
3. bloom looks horrible in 16bit
4. it looks a lot better

Not everyone uses these features, but they are often puzzled when these features run in a reduced mode (no shadows, poor quality lighting, bad bloom) just because the game started in a bit depth that does not support these features properly.

It doesn't take a very powerful card to play 32bit color mode very fast, I started out on a TNT 16mb PCI and it got 50fps 1024x768x32bit in dm3, which was fine.

So I'd recommend upgrading to a TNT at least. 

Err, fixing some typos in that last post:
There are 4 reasons DarkPlaces prefers 32bit color:
1. stencil shadows don't work without it
2. high quality per pixel lighting (including dlights) doesn't work in 16bit on cards without OpenGL 2.0 (although high quality per pixel lighting is really slow on cards without OpenGL 2.0 anyway... I need to add lighting quality settings)
3. bloom looks horrible in 16bit
4. it looks a lot better 

-classic/-fancy sounds fine to me, assuming other engines also adopt this

However I think a profile selector in the menu would be more useful to people who don't read the readme (a lot of people seem to ignore the readme already). 

Yeap, on this system it is an ATI Rage Pro. You make a very convinving argument.

I really should switch up the GeForce 4 MX that I have on my crapped out machine someday, except it is at my brother's and we have been playing a game of 'who'll blink first' and expend a half a tank of gas to visit the other. 

With gas prices how they are, sometimes it costs less to buy a new card than to visit a relative, scary isn't it :) 

I think I finally understand the reasons for the friction there has been for so long between the coders and mappers of the quake community. It's all down to different ways of loving quake.

The mappers, here and elsewhere, love quake for it's art design, it's gameplay and immersion. They love quake as it is and always has been, as id intended. They build new levels in fitting with it's style, to try to extend the quake experience, all fitting within the quake world. If they didn't love quake for these reasons, then many of the mappers here would leave and take their considerable skills elsewhere in the modding community, moving on to pastures new as it were.

The coders over on quakesrc.org and elsewhere mostly love quake for a different reason. They see quake as a blank slate, an open source engine on which to experiment and build their dreams. For them, and many of the QC coders on inside3d and #qc, quake is a modder's dream, a plaform to build from. Most are happiest using quake to develop new games that are wildly different from the original. It is the moddability and open source nature of quake that they love, the endless opertunities it presents. The original art design matters far less to them, it's modability that matters.

There is a clear difference of opinion. Both sides love quake, but for different reasons. Neither is wrong, it's just a case of looking at it differently.

Stuck somewhere between these camps is LordHavoc and a few others. They have the same love of quake's style and design that drives the mappers, but also the desire for modernisation of the coding camp. This leads to DarkPlaces, which as LordHavoc has said before now is an attempt to capture the feel of Quake in a modern engine. He also builds it as a platform for modders to work on, adding many new QC features for people to be able to use it to develop new games based off it.

Darkplaces is faithful to quake, not to the pixel, but to the spirit.

Perhaps I've over-simplified, perhaps I've over-generalised. This is only my view of the situation.

I know this is perhaps slightly off topic, but I think it's important that everyone understand each other's viewpoint. We all love quake, just in different ways. 

I have posted a new darkplaces beta which includes mac binaries. (agl+coreaudio and dedicated server, could not get sdl version to build on my friend's mac, libstdc++ linking problems - SDL for Mac OSX is C++)

I do not have a machine to test the agl binary on, good luck. 

Good clarification, I knew this but hadn't thought to explain it.

There is however a third group not represented in your post, there are artists who treat Quake as a blank slate like the modders do, unfortunately almost all of them have moved on to other games now, they were involved in many of the mods of old. 

can I quote your awesome post in the quakesrc thread? 

Feel free 

Thank you :) 

Mappers (and map fans) want to embrace it and snuggle it.

Coders (and coding fans) want to rape it and deface it's battered body.



....different kinds of love.... 

I was waiting for the shambler input.

and I agree 100% with Mauvebib, though you get the 4th group of people too I think, The "Mindcrimes" of the Qmunity (lol) who love both sides, art and code, just as much and end up with something like Nehahra, which imo is the single greatest achievement Quake has ever seen. 

It is worth mentioning that addons like Nehahra etc would not have been possible without mappers and coders working together on a common goal.

I wonder what was different about Nehahra that made the 2 "camps" think and work collectively on the project? Its a shame it doesn't happen more as Nehahra is testament to what we can acheive. 

I think it worked ok for Nehahra cause mindcrime was a story teller before actually being a coder, and had a good idea of what he wanted to achieve, without imposing much on us the mappers. He came at us saying something like "look, I added lots of funky stuff to quake that you don't really need to use if you don't want to, and I'll add a cool story to whatever maps you build, and pretty much add whatever else you want me to, interested?".
That being said, I still think there are many things we could have done better in nehahra, hopefully the revamp will fix those though. =)

About this whole coder/mapper issue, I think most mappers don't even really want much new visuals, I know I don't, I like quake as it is already, when I want fancier stuff I just go play new games. My only interest is in possibly enhancing the, uh, "mapping experience", such as with details and hints, fewer limits, etc, but even those things aren't really necessary I guess. 

You really don't get it, do you?