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?
.. last 2 releases of DarkPlaces engine are buggy and are unable to load my last map, when FQ and aguirRe's engine are able to... though... 
This should be a sticky.

Not everyone wants to have to use a custom engine with different graphics. Some people just want to play Quake as Quake.

You're not interested in Quake any more so don't waste your time worrying about it. 
Here Is A Poll 
maybe someday someone codes an engine using q3 and q1 sources that renders q1 maps faithfully to the pixel but has many of the q3 modernity advantages. That option wasn't in the poll so i didn't vote.

It should be fast and good and get rid of a lot of those pesky q1 map limitations and compile stupidities, but I think maps would need to be recompiled for that to work meaningfully.
Q3 looks a bit washed out for some reason, I don't know why. Q1 has the palette issues but it works pretty well, at least with id textures.

I don't want to start fucking around with shaders and curves and whatnot. 
there are already great compilers - q3map2, its light alone is probably the best quake engine game compiler out there
+ bonus of using quality textures and patches
(shaders are not fully supported afaik)

it means more freedom and less troubles for mappers and better looking maps for players

is requiring DP too much of a price?

bamb: some-day-maybe-in-future engine is out of question, this topic is about what we have now available

sham: no pointless flaming plz 
why should we use darkplaces??? i dont like darkplaces much... why dont release the maps like Zaka make??? normal q1.bsp and then textures set in 24 bits for people that want to use then! 
there are many more benifits of using q3 bsp format (patches, much more complex geometry, detail brushes, bigger maps etc) 
does q3map2 compile q1 .maps? So at least a part of old maps with q1 .map files available could be compiled for the new "standard".

I'm not willing to map in gtkradiant since it doesn't have the shear operator and whatnot.

And what about the palette when making and converting maps? Q3 textures look bad in q1. (just check shine.bsp) 
Heresy !!! 
there are many more benifits of using q3 bsp format (patches, much more complex geometry, detail brushes, bigger maps etc)


Q1 maps are for Q1 game, and Q3 maps are for Q3 game... That's all...

Maybe it is easier to build complex geometry for Q3, while Q1 have less possibilities (regardless the used editor, and also regardless of the embedded macros that differ from an editor to another one)... so, why not do complex stuff by hand ?

When you see some very nice and complex architectural stuff in Q1, you know that the mappers have, let's say a real "talent"... I mean I will be much more impressed by a "fabulous" map that has required many time to build, rather than another one who use "pre-mapped" stuff.... Just note I also like very much Q3 game, and yes, it's helpful to have embedded macros in editors: I'm not against technology progress.. doh !....

As well for detail brushes, that have to be turned into func_wall most of the time in Q1... As you for sure know, in Q1 you have to manage more things in big maps (FPS, r_speeds, packet overflow, edicts, fullvis processing time, etc...) that make a real good map than in Q3...

But I'm pretty sure the complexity level of each engine (Q1/Q3) is very different...

And concerning bigger map possibilities, it already exist some powerfull engines (compared to standard Quake engine ), i.e. FQ, aguirRe's GLQuake, Nehara engine, etc.. etc... in which you just have to set your screen settings to the highest resolution to have "Q3-like ingame effects"...

As well, remember most people do enjoy to play new incoming maps with original Quake engine...

i like to play maps with clients like qrack,tremor or joequake that load the textures of id maps and some extras... if the textures are new i play with gl with no textures... that�s all

q3 maps are poor in textures in my opinion... some Quake maps that have orinal textures in 24 bits are better then q3... look at schloss or skull that were made by Zaka... 
Oh Yeah 
This is going to be awesome 
I think less is usually more, generally in maps and certainly in the case of engines.

Limiting newly released maps to one engine also severely limits the accessability. I'm sure there are a lot of people who still play Quake because their computer isn't powerful enough to play newer games [or rather, they're happy with Quake so don't see the need to upgrade]. 
Mmm.. Worms... 
I think less is usually more, generally in maps and certainly in the case of engines.
i don't :) these days, i like to pour in tons of detail and spend hundreds of brushes on one set piece or one single area. i like putting trim on everything etc etc, but usually this runs up against quake's limit (either clip nodes or faces). that's my latest 'mood' for mapping, and sometimes i'm a little disappointed that i had to cut things down.
ie: i had a great idea for a map, but it was so detailed that keeping it as one map was impossible and splitting it into two maps wasn't an option either because of the layout.

Q1 maps are for Q1 game, and Q3 maps are for Q3 game... That's all...

Maybe it is easier to build complex geometry for Q3, while Q1 have less possibilities (regardless the used editor, and also regardless of the embedded macros that differ from an editor to another one)... so, why not do complex stuff by hand ?

using the q3 bsp format is not just so that you can use curves, but because that format, and the compilers that turn out that format handle complex geometry (whether generated by an outside program (ie: terrain generator) or done by hand) much better than the q1 bsp format.
a good example: make a big slab of terrain (in which ever way you choose-- by hand or terrain generator) and compile it for both quake and quake3. you'll get hung up on bad brush expansion more in quake than q3.

god knows i'd love to use the q3 bsp format (and some of DP's features) to make my maps and coding since it can handle terrain and complex geometry better, and (i believe?) has support for nonstandard sized bboxes for monster collision detection, but i don't like darkplaces, because:
-i dislike the quakeworld movement physics
-it looks washed out, and i don't know how to fix that (and likely others don't either, so any map i make for that will look ass... well not that they don't look ass already, but that's another story :P)
-there's a bug (apparently on all quakeworld based engines?) that will stop you from jumping when bunny hopping randomly. since i move around like that often, it bothers me quite a bit
-poor documentation on all the new stuff, so it takes forever for me to figure out how to turn something i hate off (ie: most of the 'fancy' effects) and i don't like sitting for 10 minutes in the console trying different commands to experiment-- that's a waste of time
-there appear to be builtin effects that get used for no apparent reason/completly automatically (ie: a projectile weapon i coded automatically has a green glow effect applied to it (no flags or anything of the sort are set), but the model is blue, and thus looks moronic)

one thing i'd really love to see in an engine (which i haven't yet) is real rotating brushwork, not the fake version in Hipnotic.
I heard there is rotation code in the engine but it was disabled by iD?

anyway, yeah. 
I'm not willing to map in gtkradiant since it doesn't have the shear operator and whatnot.

that shouldn't be an issue: map in WC (or whatever) then convert to q3 .map format via aguire's compiler, then compile with q3map2.

obviously though, you won't get detail or patches or anything like that, but you could still use skip and hint (since those are just texture names) 
-there's a bug (apparently on all quakeworld based engines?) that will stop you from jumping when bunny hopping randomly. since i move around like that often, it bothers me quite a bit

This is simply not true at all. If bunnyhopping was broken in ANY qw engine, no sane qw player would use said engine for obvious reason. This bunnyhopping issue you are talking about was specific to Darkplaces only and additionally, it has been fixed by LordHavoc a long time ago.

Actually this bug was the sole reason I had stopped using Darkplaces at some point in the past as it was bothering me way too much. However it has been fixed a long time ago now.

P.S: The people whining that Darkplaces doesn't look like GLQuake should take a look at the console variables. You can disable pretty much every single thing Darkplaces adds to the game graphics: bumpmapping, decals, etc, etc and make it look like vanilla GLQuake. 
If you think that's too much of a requirement to make the player go through DP docs to turn everything off, there is an easy solution: if you make a Q1 map that uses Q3BSP and requires DP, make it use a custom gamedir and simply put an autoexec.cfg that turns off all "additional gfx" stuff into the gamedir so the player of the map doesn't have to do any work. 
...because someone would first need to provide some good textures as Q1 replacements that don't look like complete ass. Ikbase would be the only usable set. 
A Lot Of Misconceptions 
Necros: DP is not QuakeWorld based; there is gamma/brightness control. It lacks documentation indeed.

Whoever: Gtk has shear, in 1.5 you just have to operate on edges and verts (you can select several).

JPL: How come you say that q3 editor has autobuild/macros stuff and "pre-mapped" geometry, or were you thinking of UT2k. Q3 has some mapmodels, but no one sais you should use them (especially mapping for quake). BTW Radiant can be used for any quake game. Making good q3 map is as hard, its just that you can make a more complex level, without compiler/engine problems (as Necr said)

scampie: but you dont have to use q1 textures, textures are loaded from pk3, just like in q3

and whoever is calling skull nicely textured map ... uhh 
Good Discussion 
You have other engines besides Dark Places that have Q3 bsps so the limitations of DP does not need to be an issue.

It is up to the mapper really. If Kinn's next map specifically comes with a custom Dark Places executable for it to accomadate the bsp format used, are you not going to play it because of THAT? Because it would crash poor, old, buggy, not a proper implementation of OpenGl standards, GLQuake? At most the additional executable would add a half meg to the download with compression. 
There's no need to start a new thread for this 
Jago, Speedy 
well, all i know is i discussed it with lordhavoc briefly, and he told me it was in all QW engines, or something like that, and that basically i should live with it. i guess that sort of turned me off to DP since it didn't look, at the time, that he was even willing to fix it.

also, if there are new versions up, where can i get them? the DP site always lists the old versions.

P.S: The people whining that Darkplaces doesn't look like GLQuake should take a look at the console variables. You can disable pretty much every single thing Darkplaces adds to the game graphics: bumpmapping, decals, etc, etc and make it look like vanilla GLQuake.
as i already explained, since none of those settings are documented (not even mentioning those effects that seem to be applied automatically) it is difficult to find them.

DP is not QuakeWorld based
Ok, cool, i didn't know that. However: it still feels like QW in that you seem to be able to move faster, and there's also a strange thing like in Q2 where you can 'catch' edges of brushwork and jump again, which i absolutely detest.

ps: lol kinn. :P but you know we like to rehash old threads anyways. ;) 
# 24 
in that thread is particurly good

#28, sorry fella, you sound a bit naive there. 
.. #24 and #28 in which thread ? 
I for one would use q3 bsp format for quake right away if I could (I don't like DP so much), but mostly for the actual bsp stuff, details, hints, etc. For lighting, textures, and the rest, I like the old school quake feel better. I just want to be able to make more complex maps that run and compile faster. 
Back To The Topic... 
I think it's a good idea; it automatically nets us all the compiler goodies that exist in q3map2 but would be difficult to add to qbsp (or are impossible due to the q1 bsp format.)

I think any mapper who wants to make his map look like authentic quake 1 could probably still do it by using appropriate textures and doing the lighting in a certain way (the lighting is a question... i don't know if it's possible to make it look quakey.)

I think the only real obstacle to this is that you currently have to use darkplaces, which is too restrictive for players who each have a preferred engine. If enough other engines (like fitzquake... gulp) could load q3bsps, this would become a legitimate option. But you'll never get the level of compatability that vanilla quake bsps provide.

I agree that darkplaces has problems that make it not a good choice for some players... such as the headache of figuring out how to configure it to turn off the arbitrary features. As a contrast, I've noticed fuhquake has changed over the past few years so that the default settings have most of the weird stuff turned off. 
Petition LordHavoc to make the future releases of Darplaces look as close to vanilla GLQuake as possible by default (by turning off all the new / "improved" custom gfx) and write proper console variable documentation so that people will be able to figure out things they could possibly want to enable by themselves? 
Good luck.

Really though what's the point with these flashy engines? The effects might be nice, but these engines are usually cluttered, over-the-top, and change the feel of Quake.

I think the soul of Quake is often lost in the translation and you're often experiencing the game content in a way that was never intended (that is to say, they are visually divorced from the original as to be, in a word, 'silly').

Not to mention, said engines cluttered with features often misbehave and lack consistency.

The question on my mind is when is enough enough? 
why not indeed.
this is a good idea for the designer who wants complex q1 level w/o any difficulties making it.

that'll make our half-dead quake suffer in agony 1 year more. 
I'm fine with Q3BSP for Quake as long as is just a new, better data structure for level geometry and lighting. If people insist on packaging that with new particle explosions and glinty water and hideous 24-bit textures then they can fuck off. 
For some odd reason I couldn't find the 'I won't use darkplaces as it is a crap, bloated, sluggish pig of an engine with a bunch of wank effects' option, so I couldn't vote. 
The people whining that Darkplaces doesn't look like GLQuake should take a look at the console variables.


The person/s coding the engine should

1. disable all of the new shit by default,

2. provide detailed documentation of cvars etc,

and now that I think of it, even better,

3. provide configs to quickly switch between vanilla quake mode and 'all fancy new shit' modes. That way everyone can easily try both extremes and then tweak their preferred config from there.

Petition LordHavoc to make the future releases of Darplaces look as close to vanilla GLQuake as possible by default (by turning off all the new / "improved" custom gfx) and write proper console variable documentation so that people will be able to figure out things they could possibly want to enable by themselves?

You may recall that this issue has come up before in the past, probably more than once on this board. LordHavoc read and posted at the time so I can safely assume he understands our thoughts on the matter.

If nothing has been done to address these issues in recent releases, I can only assume that he doesn't give a shit. 
For Whoever Cant Find DP Site

Frib: you are purist then? Or just want to use some other engine

Mindcrime: the point was stated several times, (maybe it not obviuos for non-mappers) compiling to q3 .bsp you can make thigs that are not possible within q1 map format.
Also its funny to hear such things from a man who built TC on a custom engine with many new effects. 'Soul of Quake' is not engine dependant

metlslime: whats the big difference of q3 lighting? Overbrights is engine stuff, color and falloff can be set whatever you want 
Speeds, is you really want to know... for me, there is no real need or desire to use any engine other than FitzQuake.

It is the only engine which seeks to enhance Quake and maintain the spirit of the original game. Metlslime understands stuff. This is why he created FQ. It is a thing of joy to be able to play in this engine. 
i don't know what the big difference is. that's why i said it was a question. I know from my q3 experiments that the falloff is inverse or inverse squared instead of linear. I also remember that the sane light values were much different for ordinary lights than they were in quake 1. Beyond this, I don't know, and I don't know how much control/flexibility there really is. Since you seem to know, can you emulate light.exe style lighting in q3map? 
Shambler Is The Wise Man Of Quake 
Beware dedicating your work to a single engine. We know not what Quake engines will be in fashion 10 years from now. 3 years ago, Tenebrae-only works were in fashion and who uses those now? Seemed like the smart money bet at that time. Today those works are an obscurity.

And beware marrying an OpenGL only engine. An engine without a non-OpenGL build simply cannot be run on the same wide array of computers.

Even some computers with the prerequisite hardware to run OpenGL Quake engines cannot: video card driver problems.

And also, there are the Mac users. An engine "having" a Mac build doesn't mean it is as good and supported as the Windows build. I haven't run across a Mac user that uses anything except for Mac GLQuake or the Fruitz of Dojo port.

Small tweaks like edict counts and other simple changes to an engine to allow larger sized maps to avoid packet overflow are one thing.

But marrying an engine is another matter entirely. Get married to an engine and your work's future is married to the engine too. 
OpenGL is a competitor to Microsoft's Direct3D (DirectX).

There is a headline on the OpenGL site ( ) about some sort of performance-impairing implementation of OpenGL in the Windows Vista, the next version of Windows shipping in December they say.

The headline has been there over a month, so it has to be a concern. 
You forgot console kiddies - they cant run quake at all, what a pity

BTW, speaking of Tenebrae, there was Tiger`s project Industry, wonder how many skipped it just cause they didnt want to play in Tenebrae, even if they could (at that time I had a puter that could barely run Tenebrae at 5-10 fps)

metlslime: I`v been tyrlite guy almost from the start, and using inverse square falloff mostly. Never liked original light.exe

I think overbrights is the most important difference of q3 lighting, the textures get very washed out if the light is bright. But Im not q3 mapper, really 
So Far, BlackDog Has Said It Best: 
I'm fine with Q3BSP for Quake as long as is just a new, better data structure for level geometry and lighting. If people insist on packaging that with new particle explosions and glinty water and hideous 24-bit textures then they can fuck off.

At the end of the day, if I could pick only one feature, it would be the ability to use mesh models as proper world geometry with collision and all, as q3map2 does with .ASE models. 
Speed: The Nehahra engine barely added a thing comparitively... Doubly so when you look at Bengt's new engine, which is the best quake engine in existence (not too much, not too little, and it doesn't choke on epolys.. even when there's an orgy of them. It is hands-down the best enhancement of GL there is, and I don't mind saying that categorically).

All in all, how many "effects" are we talking about here? A couple flags for dynamic colored lighting, a colored flash of light if desired, transparency, global fog, skyboxes, model interpolation? A few extra cvars and some upped limits here or there?

Whoop-dee-do-shit. The way people talk they make the Nehahra engine sound like Tenebrae. Christ. The problem is of course.. the people who balk.. are the people who haven't gone to Bengt's site and DLed it.. and probably never gave nehahra.exe a chance to begin with.

Even with Ender's original engine... It is no fault of mine that so many opted to use dpnehahra.exe instead, which had a plethora of other bells and whistles (that they could bitch about of course!).

Or is it all about Nehahra being the first to do any of it? Or is it because the Neh engine only sought to enhance the GL experience rather than try to emulate software Quake? (which I have/had no interest in).

And I'm afraid the "soul of quake" *is* engine dependent. In some engines, it remains victoriously. In some, certain aspects of its feel are enhanced while others remain the same.

But yes.. in some.. the feeling is LOST. And it's blatant when this is so. You might lie to yourself and say it had no effect. But it does. You know it, I know it, everyone knows it, yet some won't admit it (because ooh-ah look at that new particle effect.. or this new lighting effect.. or oooh a different map format... yay whoop-de-do-shit).

In the end, when Quake is stripped of its feel and atmospheric charm ... it's just fucking embarassing. 
The Developers 
need to be mappers themselves.

Just like fitzquake is successful because of metlslime's gentle hands and fuhquake because of fuh's dm and tf background. 
Well To Be Frank 
Just like fitzquake is successful because of metlslime's gentle hands and fuhquake because of fuh's dm and tf background.

I only use fuhquake for qw because of a winxp/driver issue when I first installed that OS - screen flashes in glquake engines halved my frame rate for some odd reason - and fuhquake was the first client I could find that allowed me to disable damage flashes, pickup flashes etc.

If I had not had that particular issue, I would have never switched from Zquake. Fuquake suffers from the same thing most other modified engines do - it seeks to change too much. Zquake was (at least at the time) the quakeworld equivalent of FitzQuake - bugfixes, small enhancements, etc - lots of stuff to improve the user experience without detracting from it.

FuhQuake is (or at least, was) just Zquake with added fluff.

Here's the important point though: I could tolerate and use FuhQuake, even though I don't necessarily like it or appreciate the author's direction on it, because all of the dodgy shit can be turned off, and there's documentation telling me how to do it. 
veering off topic, but I have to answer.
Fuhquake is based on zquake, but adds a lot of very useful teamplay stuff that is essential for real 2on2 and 4on4 play. (ezquake is based on fuhquake and has most graphics stuff easily configurable from menu)

I couldn't care less about most of the fuh graphics improvements. Although a couple ones are such that they allow bypassing having to edit pak files / gfx.wad etc., so they are effort savers (use command line -no24bit to toggle this kind of stuff).

All the goodness in fuhquake is precisely because fuh himself was at least a somewhat serious player. Which was my original point. (He was/is not a mapper I think, so you get... stuff) 
Frib, you forgot to mention FuhQuake used to be pre-packaged with dozens of MBs of crap (new textures and shit ...colored light files?)
Not sure if it changed.
Im still playing Elecro`s version of FQ that I got from him directly (just exe) :)

Mind: wow, some overreaction there.
1) I wasnt bashing Neh (I recon you got alot of shit for having own engine). It really benifited from the new features, like fog and skyboxes, despite those making Neh differ from standard quake significantly.

2) " how many "effects" are we talking about here?" - thats the thing. As many as mapper wants to have. Usage of q3 bsp doesnt mean the map will automaticly look like q3.
DP doesnt even support half the shaders, so you cant make everything shiny.
And most engine effects can be turned off. 
No overreaction. The inherent problem with communicating on-line is you can't see the other person's expression or hear their vocal tone. I didn't take offense. I just meant that I do indeed get a fair amount of crap about Neh, when really it is quite light in features compared to many other engines.

As for the Q3 BSP... well, I went off-topic a bit ... but as I said earlier... Q3 map format is fine. Format shmormat. I said so long as it doesn't also bring along that plastic bubblegum feel from the q3 engine renderer, or one risks contaminating the Quake atmosphere with Q3 bleghery. 
No overreaction. The inherent problem with communicating on-line is you can't see the other person's expression or hear their vocal tone. I didn't take offense. I just meant that I do indeed get a fair amount of crap about Neh, when really it is quite light in features compared to many other engines.

As for the Q3 BSP... well, I went off-topic a bit ... but as I said earlier... Q3 map format is fine. Format shmormat. I said so long as it doesn't also bring along that plastic bubblegum feel from the q3 engine renderer, or one risks contaminating the Quake atmosphere with Q3 bleghery. 
Frib, you forgot to mention FuhQuake used to be pre-packaged with dozens of MBs of crap (new textures and shit ...colored light files?)
Not sure if it changed.

This, of course, was eQuake, a package designed to be a one-step-install for new quakeworld players. It came with fuhquake.exe, new graphics, and maps, etc.

Also, fuhquake is honestly a godsend for serious qw players. As bambuz mentioned, the benefits of a logical and easy to use .cfg system, to the graphical optimizations, are astounding. Lastly, its so nice to have developers who are *still* working on the engine (in the form of ezquake), a decade after quake was released! Makes it feel special, in a way.

metl: I love fitzquake for sp play. I think, though, that it would be quite beneficial for you to take fitzquake one step farther and include UI improvements, such as fuhquake configs and such. Just my 2 cents of course :) 
Meanwhile At #tf... 
<inertia> do you find yourself feeling that q1sp is too limiting?
<distrans> inertia: no, I find limitations quite enabling/liberating.
<inertia> philosophically what are the implications of that?
<distrans> the engine and it's limitations serve to both mark and de-limit the play of QSP mapping, they act as transcendental signifier if you like
<inertia> hm, go on
<distrans> infinite extension in the play of QSP mapping is both impossible and unwanted
<inertia> distrans: because neither our imaginations nor capabilities are infinite? Thus we dont feel we will be maximizing the possibility of the things we are creating?
<distrans> rather, the mapper must work to re-instill jouissance at each reconfiguration that the transcendental signifier both enables and limits
* misc_ELEK has joined #terrafusion
<distrans> infinite extension in the play of QSP mapping is unwanted because opening up to this possibility is opening up to mapping for something other than QSP
<distrans> CHIVES! 
tf is dumb until we talk about moms and dicks 
One Clarification 
from -> download -> installer
"a cross-platform installer that not only installs FuhQuake executables but also 24bit map textures, hud elements and menu graphics required to take advantage of FuhQuake's features." So it's not just equake that included extras.

But usually people just got the fuh zips which had the executables, dlls (needed for ex png screenshots), some progfiles and a 3 meg pakfile containing something, dunno what, maybe just the alt hud.

And updating usually needs just the exe.

Btw, would the physics stay exactly the same if some new fancy engine was used? So that all old speedrunning records would stand? Does darkplaces do that? What about FTE? 
they are no allowed to use 
Who's gonna convert a couple old q1 .maps to q3 (via q3map2 and/or something) and have a test run in darkplaces?
Ant at least had a .map... :) 
Takes About Two Minutes 
to do that -- I imagine everyone who is interested in that sort of thing has already done it. If you want to compile a bunch of old maps to test q2bsp2 with, grab the bspc tool for Quake3 Arena, set for decompile, target to a Q1 bsp. If it decompiles correctly, recompiling with q3bsp2 presents no problems. 
Why Not Use Q3 Bsp For Q1 Sp
Speeds, a better question would be: why do you feel its necessary for this to be a wide adoption in quake mappers if using q3 technology for q1 is something you obviously want to do yourself? (seems that way from your posts at least)

Are you trying to make sure people will play your maps if you do so? Theres alot of opportunity here for you to prove some people wrong; that it can be done and done well. Go map. 
that too
and just cheking if things have changed much :)
Go map yourself.

btw Still, no one said about 'industry'... 
I would like to use q3 bsp purely for the curved surfaces, detail brushes etc side, not for tga textures etc. It would certainly offer more flexibility to the mapper. I'm not sure if you can use standard quake textures in a q3 bsp though. 
What's to prevent you from exporting your existing Quake WAD's into 24bit tga format? They would look exactly the same. 
i've experimented a bit with this, but if you're using tga textures, you can shrink the oversized textures to match up with quake's texture scale, that way, you still get all the nice colours from the original textures, but don't have the inconsistency you would normally get with 1x scaled skins against 0.5x scaled textures. 
We're Being Watched

yeah, fitzquake is their god

All Hail, Fitzquake. Ye Lord and Majesty Metlslime!

I reread the previous 59 posts of the thread. The discussion contained just about every point of view that is relevant to the topic, with pro adding Q3bsp format actually dominating in terms of agreement among the discusees, FitzQuake doesn't really get mentioned until post #34, yet, once again, we are being made out to be a little enclave of purist and elitist. 
All I Can Say Is... 
Wow. Some people are far too concerned about what other people are doing. I mean, who really gives a shit? 
Yeah, Like, 
I'm really a font of self-consciousness . . . 
Those guys are engine coders, right? So they hate the idea that no-one will use their engines they spend so much time on. The thing is, if they actually had a decent sense of aestheics between them, more mappers - and players - would use their engines.
metlslime is undoubtedly extremely fucking good at what he does. It's not because FitzQuake is 'pure' that people use it - it isn't that pure and it certainly isn't pixelated 8bit or whatever drivelsome excuse those coders use to cover their lack of ability.
It's because metl sets out with the right intention and sticks with it, producing an engine that does as much of what people actually want as possible, as accessibly as possible.

Here's what metl wrote previously:

my job is to render the content accurately. If you play stock id, it'll always look like stock id. But if you play a new map with new features, such as fog or skyboxes, those features will appear as the mapper intended.

FitzQuake owns as an engine because metlslime has a mature sense of design. If the other engine coders don't, that's their problem, not mine.

The root misconception is that engine coders see their personal project as an end in itself, which for their own satisfaction as coders is fine. But in terms of other people using their work, an engine is not an end in itself, it is only a means to an end - an engine is there to render someone else's content, for someone else's entertainment. If you're not comfortable with that, maybe engine coding isn't for you. 
Well said, even if you are a q3dm10 thief :D 
I repeat my belief that it really helps if the coder is a mapper too... or if the developers are a close-knit small real-world communicating team of coders, mappers, texture artists, modellers, game designers and whatever.

People often seem to rail against things they don't understand. Someone mentioned the nice blue highlights in the metal textures and how colored lighting fucks those up. I had not thought of it, but now, it makes some sense.

If some technology A is replaced with some other technology B with a different way of doing things, sometimes all the features don't work as well as they were supposed to. The old technology's A's hacks for realism don't work as intended in the new tech B... Until then a third wave, tech C (like doom3 with again different approach) where it's possible to do those things "properly", entirely disposing of the hacks. That though most certainly feels totally different and requires new artwork from scratch, and maybe even gameplay.

I remember John Carmack telling in a .plan in the nineties that 16bit quake actually looked worse than the 8-bit one (so they didn't release it). This seems also counterintuitive at first, but if it's revealed that the "8-bit" colors are actually a carefully selected 256-color palette of 16 million colors (3x8=24 bits), it starts making sense - after all, all the art was created with this palette too - pixel by pixel by hand!
(Anyone who's done stuff with deluxe paint should be familiar with this, how, although there are not that many colors available at one time, they can pretty precisely be tuned and more colors be allocated to different shades of the most important colors)

All this means that it's not obvious adding features improves the artistic impression of the game or fits in. 
Well Said, Kell 
I use different engines, and change up frequently depending on what type of feel I'm exploring at a given time. It isn't a matter of being more Neoleothic than the next guy, it is what in terms of aesthetics and gameplay fits the game that is in front of you.
I was frankly shocked at the acceptance of the Areowalk replacement textures that pervaded (before the site went down) by players and coders. Those were truly bad, and it may be the roll of mappers have to be a bit more 'elitist; than others to maintain a high standard. 
Heh, 'roll' 
Freudian slip 
if they care so much about our opinions, they should change their engines to suit our wishes. XD 
no need, dude, you've already demonstrated you're a second-rate moron. 
Always Good 
to talk about each other instead of between groups! 
I concur with Kell & Post 63 
Engine Bleh 
Kell: Well said. Agree 110%.

It's also worth drawing attention to the fact that not only does FitzQuake render Quake much more accurately than GlQuake, but it actually does it considerably fucking faster than GlQuake.

Ok, I'm drunk and I'm horny at the moment, but I'm still prepared to suggest that maybe the guys on that forum should bear this in mind the next time they get their knickers in a twist because the latest bloom-wanking, lensflare-whoring, texture-raping BloatQuake-du-jour doesn't get the attention they expect from us mappers, especially from those amongst us that like to push the .bsp format that little bit further, where rendering efficiency actually becomes a factor to take into consideration, even on modern systems.

Word. ^_~ 
Mappers VS Coders Inertia managed to actually find a discussion about *THIS* thread on a forum for engine coders. Hilarity ensues. 
A Quick Note On Engine Popularity 
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.

Personally I think it's extremely silly to choose an engine purely based on particle effects, but that is what these people do, and they seem to comprise a substantial portion of the userbase of each engine other than the few engines that kept glquake particle effects (fitzquake and others).

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.

I personally like the particle effects in darkplaces or else I would not have them that way, I can add back all the glquake particle effects as an option, but it can not be on by default.

Regarding documentation, yes I know the documentation is weak, the readme needs another update (for instance I have removed detail texturing entirely, so that part is no longer relevant), and ingame cvar and command documentation has been planned for a long time but I haven't been reminded of it very often by users.

However, I tried to make darkplaces' menu system self explanatory, and all options that people ask me about are quickly added to the options menu or its multiple submenus.

I do not personally see the reasoning for wanting the particle effects to stay the same, darkplaces mod was designed from the beginning to make quake look 'better', the engine has followed the same line of thinking. 
I do not personally see the reasoning for wanting the particle effects to stay the same, darkplaces mod was designed from the beginning to make quake look 'better', the engine has followed the same line of thinking.

I don't see any reason to keep the same original effects either - especially since they simply aren't that great (lets be serious here).

I would actually love to see a Quake engine with 'better' effects. Therein lies the problem.

It takes the careful eye of a talented artist to put together great art and effects in a cohesive style that ties everything together nicely.

From what I've seen of most modified Quake engines, I can guarantee you none of those engines do have a talented artist or anyone else even moderately competent looking after the effects.

What I do see is a bunch of fancy coloured wank effects, most of which are just plain bad, or overdone. Very occasionally you'll see a nice, well done effect, but it certainly won't work together well with the rest of the effects, and probably doesn't feel 'right' inside the Quake universe anyways. Every single 'enhanced' engine I've seen just has a mish-mash of (mostly bad) effects with no thought given to the overall art style of the game.

Its like the whole thing with 24 bit textures. Many people just seem to think 'its better because its 24 bits, so its better'. They can't understand why we don't jump for joy when they replace some fairly decent 8 bit textures with a bunch of arse flavoured 24 bit textures, which don't resemble the originals and (surprise surprise) don't work well together.

Again, it takes the careful eye of an artist to put together a coherent set of textures. And just because you aren't restricted to a particular palette does not mean that you shouldn't use one. 
Back To The Real Point 
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. 
Mr Fribbles 
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.


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. 
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? 
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)

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 :)

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. 
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... 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, 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 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. 
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. 
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. 
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. 
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. 
About All Suggestions 
Text_Fish, Kinn: I'll be posting your suggestions at 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. 
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). 
Thanks LH, 
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 Understand 
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 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 :) 
Loving Quake. 
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. 
Or Taking It Even A Step Furthur 
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 
Btw Coder`s Problem 
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 
Good Point Speedy... 
...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. 
Back To The Topic... 
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? 
Just A Lack Of Collaboration 
Even despite the QSG... 
The QSG died a long time ago. 
If I want details casting shadows but the game still to be fast (you need that in dm) using func walls, I had better to make the whole map in q3 bsp? There aren't necessarily that many unique models in dm maps so the shadow-casting func_wall would work and would need just a light.exe mod, but I can see the models running out in sp maps a lot, so the compiler coders don't think it's worth the trouble.

Would it be that hard to try an example q1 .map -> q3 .bsp with q1 ents?

There are tons of q1 .map files that can be edited in gtkradiant and converted to q3 maps and bsp:s. (metl's ant or czg's terra for example)

Then people (mappers) can load them up in fte or darkplaces and start listing the things that look right / don't look right and we see where we can move from there. And what the fps really is there... You really need solid 77 for dm. And physics must be similar to current q1 bsp.

If the whole thing works, someone like the ezquake people can port it to their engine and you can play qw in bigger better maps too. Now it's mostly just boxroom-L-corridor-boxroom.

I've never mapped for q3 so I don't know how to do all that but someone most certainly can. Hell, I don't even have internet at home. 
That is a bloody good idea. I've actually loaded up a lot of existing Q3DM maps in DarkPlaces and run them with Aard's DMSP mod - the monsters run around no problem, although at the time, patches didn't block tracelines (so monsters "see" straight through patches), so there still needs to be some tweaking done(unless that's been fixed already) 
Q3 Bsp 
for SP only. Forget dm-online. DP is not QW (thats 1 of the many reasons) 
How things are is no indication of how they should be.

And fteqw is qw. Go check #fte. 
point is, there is not much need for q3 tech in qw
but there is in SP 
But There Is 
need for q3 tech in qw as much as there is in sp.

Look - it's like this:

1) sp maps generate fps etc problems since they are so huge and detailed. q3 tech to the rescue.

2) dm maps must have very stable and high fps, so even moderate maps generate fps problems. q3 tech to the rescue. 
Q3 Maps 
I rarely play Quake 3, mostly because Q1 is a lot more fun, but I can't recall seeing ...

1) Any lifts, trains or moving parts in Quake 3 maps. It's always jump pads.

2) Any holes in the walls like on DM1 or DM2

3) Very many objects. The maps are all flat surfaces, no braziers or torches or anything.

4) Can't recall seeing any buttons.

My stereotype of a Quake 3 map is one that looks good in a screenshot but is devoid of the little things that keep them from feeling sterile.

It is my perception that, if Quake 3 gets good FPS in multiplayer, they did it largely by making the maps flat-like and featureless.

Bases, garages, tunnels ... not complicated stuff like the rocky terrains in Lunaran, for example.

Again, I'm no Quake 3 map expert but I was never impressed by the terrain in any of them. 
Better play Quake 3 and it's custom maps... At least as long as until you find those things ;) 
with all due respect...

can I have a toke of whatever it is you're smoking? :} 
I don't really see what the maps from Quake 3 have at all to do with q3bsp support for Quake. *WOOSH* was apparently the sound of point, flying at sonic speeds high above your head. Besides, the even the stock Quake 3 maps have the things you are listing, you aren't looking hard enough. 
q3bsp format in quake just means better tools, for the most part. the game would play almost exactly the same. 
Maybe Someone Can Break My Stereotype 
re-read this thread a bit plz 
My Own Observations On Q3BSP 
I have consistently seen significantly more performance in q1 .map files recompiled as q3bsp using q3map2, despite both using the same renderer in darkplaces, it is simply a matter of the compiler being more effective.

I recommend -meta when compiling maps with q3map2, and you can also mark materials as terrain, which causes them to be merged together and smoothed (this can be really great for detailed walls and things, not just terrain, keep your mind open to new ideas :).

I recommend using the terrain grouping in q3map2 very heavily for performance, it can get the surfaces (wpolys in q1 terminology) in r_speeds down to double digits while having thousands of actual polygons visible, effectively this is telling the engine to render things as models, just a lot of polygons to throw to the graphics card without much thought about it.

I'm sure everyone here knows that wpolys are the biggest fps killer in a q1bsp map, and q3bsp offers a way to reduce wpolys without sacrificing detail.

Make no mistake about it, q3bsp is more difficult to map for, it's much more technical with all the detail/structural flags and CAULK texturing of all hidden surfaces, this I consider to be the worst thing about q3bsp.

However when you are already packing so much detail into a map that it runs poorly in q1bsp, the extra work is not that annoying when it makes your creation actually play well as you envisioned it, rather than cutting back on detail.

Now some facts about q3bsp compared to q1bsp:
Physics - no differences, except that modders can add things like crouching (which never works right in q1bsp because it only understands bullets, players, and shamblers).

Lighting - q3map2 has much nicer lighting features than any of the lighting utilities for q1bsp, it even has optional radiosity.

Vis - detail brushes are a better alternative to func_wall for keeping down vis times, you can easily have vis times under 1 second if you build most of a map out of detail brushes, the structural brushes only need to define the room shapes for vis. You can also do hint brushes to tweak vis behavior a bit (rather than using various visible brushes sticking out into a hallway to cause an intentional bsp split, you can use invisible hint brushes for the purpose).

BSpline Patches - curves can be more convenient than making a lot of brushes, they should be used in moderation however (when overused they become merely a gimmick, serving no useful purpose), they can be useful for terrain because they are easy to edit.

Models - the ability to embed models and have them be properly lit and shadowed by the light utility is quite cool, they can even be made solid with a spawnflag in the misc_model entity, allowing you to model large pieces of architecture that would be more difficult to build/texture as brushes and stick them in a map, they render really fast too.

Model lighting - as mentioned any models you embed in the map are properly lit, but that is not all - dynamic models are lit by a q3bsp technology known as the lightgrid which applies directional shading (a big visual improvement) and works properly for airborn entities, curing the 'very bright player while jumping over a lava pit' problems in q1bsp.

Q3 shaders - FTEQW supports Q3 shaders fully, DarkPlaces supports some very basic features of q3 shaders such as:
blendfunc - you can make 'light cones' by simply making a brush with a gradient texture and blendfunc one one, also known as blendfunc add.
deformvertexes autosprite - makes a brush face look at the viewer at all times, a sprite.
deformvertexes autosprite2 - similar but stays upright, like doom sprites, useful for torch flames.
Several others are also supported, but those are the most useful Q3 shader features supported by DarkPlaces.

I hope this clarifies the thread subject (Q3BSP for Q1 SP).

Kinn: curve collisions were added to darkplaces back in mid-2004.

Baker: ever checked the r_speeds in those q3 maps? the triangle count is quite a bit higher than most q1bsp maps, and they DO have a lot of light fixtures (including wall sconchs, glowing skulls, burning barrels, among other things) and other detail on the walls. I don't contest the fact they are overall rather boxy though. How about taking a look at Nexuiz nexdm02, which has curving hallways and other varied architecture, and comprises over 300,000 triangles (which would simply not be even remotely possible in q1bsp). 
do the compilers / darkplaces / fte / support q1 ents in q3 maps? If yes, what are you waiting for?

We need examples:

1) a q1sp .map -> q3 bsp.

2) a q3 .map with some added q1 sp ents. Either from scratch or a q3 dm map. -> q3 bsp.
(someone who plays/maps q3 paste .map url here)

Upload the bsp's to a site. Paste url here.
Let people play with dp/fte to test. 
just load any q3dm map with DMSP mod 
it's not the same, entities in the bsp, triggers etc! 
Uh, who cares? There's little chance of that not working correctly, it's the visuals people are interested in here at the moment anyways. 
and u didnt even try 
The entities and triggers etc are completely detatched from the engine and compilers.
If you make a Q3 bsp with Q1 entities, you get a Q3 bsp with Q1 entities.
Nothing in the compilers or engine gives a crap about that. 
Begs A Question 
"what are YOU waiting for?" bambuz 
Some of my older maps were built in Q3Radiant, and I released both the q3 source .map plus a q1 .map. The only thing you need to do there is recompile the Q3 .map with q3map2 (no need to convert it) and convert the textures to .jpg or .tga (easy to do with TexMex). Try RPGSP1. 
what czg said.

Play DMSP and all the entities in the q3 map that share the same name as the corresponding q1 entities work as you would expect them too. 
Q3->q1 Entities 
You can take the .ent file from a Q3 .bsp and rename the map items to fit with Q1. I've done this with a couple of Q3 maps so far (q3tourney2, ospdm2, & cpm23. FTEquake will load the .ent and (netquake).progs so DM vs. bots is playable. Omicron bots don't work with FTE but Zeusbots work somewhat. 
tested a bit. I don't have q3 so I downloaded some of lunaran's q3 maps from They use some baseq3 textures so they're mostly white for me though. :(

I downloaded aardappel's dmsp mod:

put the pk3s in the dmsp dir.

darkplaces: just started with -game dmsp, and after getting rid of a lot of fps killer stuff and hanging the client a couple of times in the process, i loaded up the map. It complained of no info_player_start so (thanks spike) i tried with deathmatch 1. That did the trick.

fte: if i ran with deathmatch 1, it used qw style, so i had to type "progs progs" and then it ran fine.

Lun3dm1 didn't spawn any weapons except the lg (funny that that entity is the same then) and stuff generally worked somewhat.

Teleports didn't work in fte at least yet.

The monsters seemed to work pretty ok, and didn't feel that out of place... though i had mostly no level textures and it was a brief stint anyway.

Could someone point to a q3 level pk3 that contains all it's textures?

All in all, i'm surprised how well it worked and think that q1sp and qw with q3bsp might have a future! 
I think both of my Q3 maps contain all their own textures. 
your nick proved to be tough googlable... i assume it's not on spawnpoint (down). 
googled rpg3dm1 & 2 and found on 
Some More Precise Problems 
A better list and accompanying screenshots at
check 29..

-monsters drop into brushes?
-teles don't work (fte, acknowledged)
-some teles don't work (dp)
-teletex borked (fte)
-lamps don't work (both) dunno what precise tech problem
-jumppads don't work, player is stuck slowly (both)
-healthboxes don't always render right, sometimes get just luma (fte at least)
-really low fps at times when many monsters (dp at least)
-skybox doesn't work, is shaded (missing texture or tech prob?)

need baseq3 textures or some basic repository (not tech but mapper responsibility, must be organized)
OR id1 etc texes loaded from a wad or something. (since ppl prolly can't distribute id etc texes as jpegs)

Or then just custom texes but that partly defeats the purpose.

It would be nice to do proper tests since now it's a bit hard to know if it's just the dmsp mod that fucks up or the engine. 
The teleporter, jumppads, and other entity problems you listed are not actual problems due to the q3bsp format.

These problems are due to the way the entities are set up for Quake 3, which in most cases differs from their Q1 equivalents. 
i'm ignorant as ever, just trying to get this thing moving a bit...

I still think the only real way is to make a proper q1-entified q3bsp. Then you can say what works and what not. 
Here are .ent files for q3tourney2, ospdm2, & cpm23.
They are 90% done. If you don't have Q3 get the demo which has q3tourney2,q3dm1,7,17. 
Id1 Etc Texes Loaded From A Wad 
My experiments with TGA files -- and I believe someone said earlier in this thread that the Q3 format can use jpg or tga -- indicate that TGA files with an 8 bit (aka 256 color) palette have around the same, if not smaller, file size than PCX files.

In otherwords, a WAD --> LMP --> PCX --> TGA (8 bit, 256 color palette) would be the same filesize with no loss or change in textures. 
Bake: nobrainer. they are still 8 bit bitmaps
bambuz: the white polys are shaders that DP or fte fails to parse, you are not missing the textures (or actually could be either) 
Why Would I Want To Work At Home Where I'd Be All Alone Forever Inste 
ad of going to the office and actually meeting people for a change. Maybe you shouldn't try to be such a fucking antisocial slut! 
First spam in months. The spam menace is growing... adapting... 
I Found 
an interesting post at one spam-ridden board, RetroQuake:

This was posted by a spambot, but a non-malicious one. Follow the links and read about the project. 
Thanks for the link. This seems to be specifically geared towards securing phpbb, though. Some of the general ideas would apply to this board but I'm not willing to give up anonymous posting, which I think is important for encouraging casual visitors to post.

So my tricks area all attempts to foil the bot in ways (almost) invisible to the user, such as IP address checks, javascript, cookies... 
wrong thread ...

It wasn't really a suggestion to secure this board, since it's pretty spam-free. It was more of a consoling feeling that someone's actually trying to put a spotlight on this issue from a spammer's perspective.

The online world seems otherwise to be rapidly drowning in a diarrhea of nonsensical noise ... 
Does Fitzquake Load Q3 BSP's? 
I'm assuming no. 
just darkplaces as far as i know... 
and fte apparently... 
Great Idea! 
Fitzquake should load q3 maps too!
cause darkplaces doesnt support shaders 
It doesn't? Wow, I musta misunderstood all the pretty effects in my maps. 
I think lordhavoc has invented his own shader language. But, I think darkplaces also supports most aspects of q3 shaders... maybe. I can't remember :P 
It interprets many of the q3 shaders, one pass only though, but that's enough to do a bunch of simple yet effective animations. 
Q3 Bsp's Teleports And Jump-pads Work Well 
At least in DPmod's deathmatch 7 mode (similar to dmsp, but much more brutal I think).

If loaded in normal deathmatch mode, the jump-pad will glue your feet and the teleports will port you into void (tested in map q3dm7 of Q3Ademo).

And I tried to edit a ent file for map q3dm1. So far I have succeeded in replacing Q3 weapons with Q1 ones, but have failed to add any monster entity. Any body knows why?

It seems to be a lot of fun editing the ent. I am thinking of transforming normal single bsp maps into something with nehahra or quoth monsters, if replacing or changing monster entity is possible at all. 
It seems to be a lot of fun editing the ent. I am thinking of transforming normal single bsp maps into something with nehahra or quoth monsters, if replacing or changing monster entity is possible at all.
Be aware that only few mappers allow something like that in their readme, at least if you plan to spread it (as in non-personal use only). 
If He Is Using An External File 
that overrides the info in the bsp file and not repackaging the bsp for download with the file, we really have no say in it. It would be no more intrusive than if he were to record a demo and post it. It may rely on the bsp in order to function but it in no way intrudes upon that file which is the only material we would have a legitimate claim.

If the mapper did express an opposition to this in his readme, it doesn't really matter. Just like the NFL disclaimer before each broadcast, the mapper is claiming far more in the way of rights than the law actually allows. 
Of Course, 
copyright is rarely a big concern with mod mappers, but more importantly, it is just douchebaggary to put a lot of nonsense in a readme disclaimer. 
so... can I take other`s map and do anything with them? 
Yeah. But it won't win you any popularity awards and most in the community won't even look at your creation if its seen as ripped off.

If its with mapper's permission and / or collaberation thats a different story - I'd love to see someone else's ideas on how my maps should play.

Basicly as a mapper you have very little control over your creation, since it is already inside the various licences of id software. By making it in the first place you're relinquishing many of the standard rights you'd have if you made, for example, a standalone EXE game from scratch where you shoot at bricks.

Occasionally someone does steal someone else's content, and when that happens (and they don't credit the original author / play fair) the review sites won't even touch it, and few players. Although I'm sure I can be contradicted on that. 
so... can I take other`s map and do anything with them?

I guess the answer is it depends. There is some precedent for what Spirit mentioned. On the QuakeWorld site they have posted some incredibly bad re-textures of some mapper's levels. I mean really hideous neon glowing shit that made you wonder what these people had in place of eyes.

However, I just don't see anyone getting all worked up about an .ent file to an already familiar level though everyone's opinion will naturally vary. Personally, I would like to see a reworking of a ton of levels from the 90's with Quoth or Nehahra entities. 
Editing External Ent File 
Well, I made ent files with text editor, and I don't want to change the bsp file permanently.

So I don't actually change the author's work, but adding a removable flavor of my personal preference to it. I guess this infringes no one's copyright.

For example, there is a world famous painting, and some guy comes up with an idea and produces a pair of glasses, with which, you see the painting to be of totally different colors or shapes. 
A circular . . . discussion. There are alot of errors in warp that only need a .ent or three to correct them all. Shamblers facing the wrong way, Vorelings not on the ceiling, Ogres lost without a cause.

I could have rerereleased the pack, but you've got to let it go sometime.

dooomer, if you make an ent file for a map then I bet that most who know that map would want to see it.

And, ultimately, recognition is the one thing thing a mapper will never dislike. 
...Ogres Lost without a Cause.

Coming to a theatre near you soon! 
Ogres in Black

An Ogre Called Wanda

Reservoir Ogres

Olgivre Twist

Uh, Ogre Potter?

Thinking of the Nehahra movie now - "He was my son!" 
Reservoir Stroggs... them all. It was a deathmatch map in one of the two official quake 2 mission packs. 
Beat Me To It 
always liked that name, metl :) 
Recent Q3 Maps Look So Gorgeous 
But not in Darkplaces.

<Spirit> how complete is q3bsp/shaders/whatever support considered in darkplaces? i noticed differences between q3 and dp in some maps, should i report those or are those a given
<divVerent> no multilayer
<divVerent> some two-layer shaders 
apparently q3bsp has no lightstyles, which is dumb, because flickering torches and broken strobing lights add a lot to a map IMO. 
But there's the SP / MP difference to consider. 
The What? Elaborate 
I'm guessing he means that flickering, strobing or pulsing lights are very atmospheric in a SP game, but in a bright, fast MP game like Q3 they are at best unnecessary and at worst annoying :E 
that is true, but when we talk about using q3bsp for q1 SP, the lack of lightstyles is a minus point. 
eep, double post, but:

we did some talking about this internally, and it seems q2bsp would be a better candidate to base a new bsp format for Quake on.

Surface flags, for one.

q2bsp is also technically similar to q1bsp, I hear.

So theoretically, you could take q2bsp and add patches from q3bsp. I think. I'm no expert on these things.

Of course anyone could simply go and map for a newer game, where features like these are a given. If you want Quake monsters and weapons, you can still finish Shambler's Castle and use idtech4. The Doom3 Hell maps (the ROE Hell themed MP maps as well) are more Quakeish than Quake, I think.

Why reinvent the wheel. Maybe Quake is just too old. 
I Wish Quake Could Use The Q3 Bsp 
If it were possible to use the actual bsp part from Q3 with Quake maps that would be incredible. I have both a Q3Arena map and a Quake map in progress and the difference between the two with respect to how the brushes get chopped up is ridiculous. I'm pretty sure the quake map r_speeds would get reduced to 1/3 or less if BSPed like Q3. 
well, from what i understand, isn't this what darkplaces does? it can load a q3bsp map file with q1 progs and such. 
Yeah, I think so. Try Darkplaces or FTE. 
This is a pretty good find Spirit, thanks for the link.

So "no light styles" isn't strictly true. Hmm. 
as dp only has basic shader support, i guess these aren't supported? 
5 posts not shown on this page because they were spam
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.