I was thinking, does a func_illusionary add marksurfaces? I know a func_wall does, and it adds clipnodes aswell, but I'm not sure about func_illusionaries. 

all brush entities should work the same way... the only difference is quakec (which the compiler doesn't know anything about) 

had that problem in tchak... marksurfaces made me cut on some details i wanted to add :| 

Started to implement point versions of all brush entities, which should be able to lower such limits significantly, and make build time quicker as well, since the mapper only needs to make their map's atypical door / crate / cog once. 

Actually it depends of what the engine has to render in real time. If you have a very good occlusion mapping style, then it is not a problem, else you have troubles...
Or you can use an enhanced engine with over-standard limit support.

As example in CDA the max marksurfaces was exceeding 32786 (i.e ~35000 if I remember well), and it requires a decent engine to play the map: i.e WinQuake is definitely not suporting it ;) 

Spawned .bsp's will still add to the total? 

JPL: Well, i should mention that i want this map to play in all engines. So i am actually trying to understand the marksurfaces limit as well as possible. (also to help other people understand it too, of course.) As it turns out i am under the limit again (deleted a couple of less-important details.)

ijed: external bsp models (like ammo and health) should not affect marksurfaces because the problem is the index overflowing (stock engines treat the indexes as signed shorts, meaning 32768 will be loaded as -32767 and when you try to use that negative index on your marksurfaces array it will go outside the array.) External bsp models have their own arrays, so it should work. (to the best of my knowledge.) 

i believe that trick where you reuse bsp models inside the map doesn't increase marksurfaces either, just the original. 

 

metlslime

"i should mention that i want this map to play in all engines"

This one of my goals in all my maps!!!

hope you can kill the bug ;) 

I feel myself going in the direction of simply requiring Darkplaces. What's the problem? It's cross platform and open source, free as in beer... looks better than other engines, supports a crackload of extensions, custom assets in various formats, and gigantic maps, and it's stable enough. SDL and GL versions, too. Can't ask for much more.

I also like how video capture is piss easy in Darkplaces. You can even plug those *.ogvs directly into youtube.

rockin' engine. Sure, quakespasm is nice, too. Just not enough support for things like csqc, and slightly old school graphics...

a problem with many quake engines is the fact that they are just missing features that DP or FTE have had for years. Old school is well and good, but it's 2010. Custom HUD elements via CSQC would be nice. So would squad AI and stick physics or ODE. These things exist, but aren't supported by enough engines. :-/

Wouldn't want to live without .ogg support for the soundtrack either. No idea why other engines don't have that. 

It's a case of multiple support - DP only makes you even more niche if you're on the dev side.

Quakespasm / fitz is a decent standard now with the raised limits. It's not flash looking but not everyone likes Quake to be and any made specifically for it can still be played in DP for those who do. 

> DP only makes you even more niche if you're on the dev side.

How so? Don't most modders, quite some mappers and a lot of players use Darkplaces? 

engines get used when they're required. Just like Windows. 

There's quirks / fixes / features in DP that aren't in other engines, so bugs can slip through the net if you only test in DP.

We've had a few, remember :) 

but if you *require* DP, isn't it enough if it runs in DP?

(getting hypothetical I guess) 

i've skipped all releases that didn't play in fitzquake 080. when 085 was released with increased limits, i went back and played them.

otoh, i was fully ready to require fitzquake for ne_cath if it had been released because the maps didn't load in any other custom engine (it seems not many people bump up max static entities). 

Only is a reasonable requirement, but I prefer to play it safe and support 'lesser' engines as well to hurt the 'customer base'. 

unless i go back to like one of the first releases

then i might as well use rocks instead of hammers, and stone wheels instead of pneumatic tires :/ 

I have a Geforce FX5500, which was like 30 euros. I'm sure they're cheaper on ebay. My machine is a P4 from 2004... the recent DP allows me to put effects and lighting to "Quake" levels very quickly, putting me near 100 FPS most of the time.

> skipped all releases that didn't play in fitzquake 080

Er, why?

> to hurt the 'customer base'.

I see what you mean, but you can't get much friendlier than win/lin/mac and free as in beer. Depending on Fitzquake, or one of its offspring, to implement support for the most basic new features anytime soon is kind of a gamble, seeing where Fitzquake comes from. I had hopes for QSB, but not much is happening there lately.

A general discussion btw, not strictly RMQ related. I just want to use csqc and a couple other things for my projects. I see that my options are limited. 

Not a RMQ discussion. Didn't want to go down the singular engine route, otherwise would have gone for some genuinely more advanced engine. Would have been much more work but visually far beyond even DP's capabilities.

Talking about something like Doom3 or Crysis.

Something would have been lost though. It's one reason why no hirez. At least yet. 

Er, why?
because they didn't play in fq080.

i think i weathered through tronyn's masque in dp (both when testing and then to play properly), because the map was ridiculously cool, but i enjoyed it a lot more when i was able to replay it in fq085. mind you, dp wasn't as good in 07 as it is now. it was generally slower and the version i used back then had some weird bugs which are all fixed now.

i shall address your initial points:
It's cross platform and open source
i'm on windows and i can only compile source files on my work machine with microsoft visual studio. completely indifferent.

free as in beer
all engines are, and if they aren't i wouldn't even look twice at it. this isn't really a plus or minus.

looks better than other engines
subjective and debatable. it's not ugly though, and the presets in the menu do a good job of setting things up.
still, i prefer FQ because it has cleaner, solid particles. DP at 'quake settings' has fuzzy particles like they are covered in fur.

supports a crackload of extensions
i haven't really wanted to mod anything that can't be done in normal qc. indifferent.

custom assets in various formats
all i really need is external tga textures to circumvent the quake palette and skyboxes, which FQ already does. indifferent.

gigantic maps
not sure if it's changed recently, but FQ has higher limits for static entities which prevented a map i was making from loading in DP.

it's stable enough.
no arguments there, i've never had the engine crash during gameplay. but neither does FQ. indifferent.

SDL and GL versions
i suspect this is more to do with portability? i am using quakespasm atm because it fixes the 64 bit + dual core + w7 problem in fitzquake. not because it's sdl.
whether it's sdl or not, opengl or directx, really doesn't affect me in any way since it either works or it doesn't. indifferent.

there is one thing that i care about that DP has over FQ though, and that is the increased accuracy on angles. or maybe the engine interpolates angle changes. the point is my cogs and gears accelerate to full rotation speed very very smoothly and slowly rotating brushes don't have to deal with low precision angles. :)
oh, and snd_spatialization is pretty sweet and easy on the ears.

finally, and i hesitate to bring it up because it's not very quantifiable, but even at 'quake settings', DP runs slower than FQ. when developing maps, i'm routinely running around with 20k wpoly and maybe 50-90k epoly. DP slows down to a crawl, and no way would i use one engine to develop on and another to play.

your later post:
Custom HUD elements via CSQC would be nice. So would squad AI and stick physics or ODE.
for this stuff, wouldn't you be better off in idtech4? it's 2010 after all. ;)
the AAS system makes ai and pathfinding very simple and the gui stuff is one of the 'big' things about idtech4. the physics engine leaves something to be desired though, it's pretty shit. :\ (what's ODE physics?)

anyway, you shouldn't be so worried about if 100% of the community will play your mod or not. i'm sure there are people who hate quoth with a passion and curse every map that comes out that requires it.
just do your idea for DP and if it's awesome enough, it might even entice other engine coders to update their stuff to be compatible with it. or it might not. but at least you made something bad ass, that's really what's important, no? 

I have three entities that will move during in the game. They are equally spaced and between and around them I have lights. The two outer entites are lit correctly but the middle one is not lit.

Are there special considerations when lighting certain types of entity? I though that they picked up their lighting characteristics from the surface below them so was expecting all three to be lit the same. 

you're talking about point entities?
it also depends if you have sky brushes below. you have to bury a normal brush inside the sky brush.
also, the original quake engine only checked a certain amount below them, if the floor was further than that amount, they would just be full dark.
that's all i can think of. 

So I know that the 'kin' entity takes its 'kin' light from the 'kin' surface below, so why the 'kin' hell did I 'kin' delete the 'kin' brush before I compiled the 'kin' test map!

I need to stop drinking... no, I need another drink...

(thanks anyway necros)