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? 

lol, take no notice of smabler - it's his job here to provide "controversial" viewpoints - it spices things up a little 

what i think would totally roxor would be for there to be a way to use 'real' rotation stuff from custom engines, but still have it work in normal quake/glquake... maybe have the custom engine automatically remove func_movewalls and just use the new collision system or something like that.

that way, the stock id engines will still have the fake collision, but the custom engines that support it will automatically 'convert' it to the new real rotation, thus making it completly transparent to the player. 

as i use func_togglewalls sometimes for larger rotation brushes (ie: a large drawbridge or somesuch) and have only two togglewalls, one for the first position, and the other for the second position, and simply switch between the two whenever the rotating bit gets triggered.

you could have some kind of key, like "_rotationobject" and, when set to '1', custom engines that support the real rotation collision would just remove those as well.

perhaps it would be better to ONLY use that method instead of automatically removing func_movewalls, even, since there's always the possibility that the func_movewalls could be used for something else.

i guess this isn't really on topic, so apologies for that, but these things just come to me out of nowhere. :P 

no one wanted to follow any standards to make engines somewhat compatible
its one of the big reasons mappers dont take advantage of engines new features 

...but having said that, mauvebib - thank you for putting things into perspective. Bal probably put my position best. If I was to pick one new visual that I would like included, I'd have to admit that I like using the lightning gun in JoeQuake. I think this is a good example of an enhanced effect, that adds rather than detracts from the original ethos. 

what is the main thing keeping engines (qw and netquake) from jumping into 2005? the map format and the aesthetic quality of the engines?

or just a lack of collaboration? 

Even despite the QSG...