News | Forum | People | FAQ | Links | Search | Register | Log in
Why Not Use Q3 Bsp For Q1 Sp
It's possible to load q3 bsp in darkplaces, and play the normal quake game.
I dont think anyone have used this possibility (zombie had tried, but didnt release afaik)

IMHO its a good way to overcome quake map/compiler limits and bring advanced graphics to q1. And darkplaces is pretty stable and powerfull engine that can be tuned to run pretty fast even on old cards (like GF1)
Why not?
First | Previous | Next | Last
Jago 
he said he could add it back but make it not a default option (ie fancy effect on, but original effects can be enabled). 
Yay 
fribs said it. 
LH 
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. 
Would It Be Possible... 
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? 
Configuration 
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. 
Now 
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 :) 
Mwh 
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. 
Aah, Ok 
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. 
This Can Be A Start Point... 
...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 ;) 
Frag.m 
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. 
Hi Coders. Here's What I'd Like To See In A New Engine: 
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. 
No 
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. 
Eh? 
I think he means stuff like accurately tumbling collision objects and stuff, not player movement :} 
Particles 
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) 
Jago. 
What Kinn said. 
Regarding Working With Coders 
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. 
Suggestions 
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. 
Bambuz 
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. 
About All Suggestions 
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... 
-classic / -fancy 
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. 
You See, 
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. 
Bambuz 
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. 
HeadThump 
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. 
HeadThump 
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 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.