#9678 posted by JneeraZ on 2010/04/14 15:15:58
Which editor? If it stores the planes in the MAP file as floats, it might be floating point creep.
#9679 posted by necros on 2010/04/14 20:13:24
it is floating point creep.
i was trying to figure out how to get aguirre's convmap to correct the inaccuracies (that's what it was originally coded for), but i couldn't. :S
#9680 posted by necros on 2010/04/14 20:14:54
that's what it was originally coded for
that's what it was originally used for (by me).
i used it to correct floating point inaccuracy when i was mapping with quark407 way back.
Marksurfaces...
#9681 posted by metlslime on 2010/04/15 11:28:56
This is my first time working on a map that pushes the marksurfaces limit, so i'm learning what exactly that limit means.
1. Other people have said "sometimes you can exceed it a little bit and it's okay". I just now confirmed that this is true, i have a map that doesn't crash win/glquake with 32806 marksurfaces.
2. I used to think that brush entities didn't add marksurfaces, but i just found that adding a func_wall increased my count. So they do.
3. GLQuake doesn't use marksurfaces at all when rendering brush entities, only uses them on world rendering. I wonder about winquake....
THEORY: you will crash only if the world itself has more than 32767 marksurfaces. If it has less, and only adding the brush entity marksurfaces pushes you over the limit, then you're okay.
Metl
#9682 posted by RickyT33 on 2010/04/15 11:51:04
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.
Ricky:
#9683 posted by metlslime on 2010/04/15 11:54:18
all brush entities should work the same way... the only difference is quakec (which the compiler doesn't know anything about)
#9684 posted by Trinca on 2010/04/15 13:03:45
had that problem in tchak... marksurfaces made me cut on some details i wanted to add :|
I've
#9685 posted by ijed on 2010/04/15 13:10:00
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.
Metlslime
#9686 posted by JPL on 2010/04/15 15:06:34
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 ;)
So
#9687 posted by ijed on 2010/04/15 15:43:23
Spawned .bsp's will still add to the total?
#9688 posted by metlslime on 2010/04/16 00:44:01
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.)
#9689 posted by necros on 2010/04/16 04:06:02
i believe that trick where you reuse bsp models inside the map doesn't increase marksurfaces either, just the original.
So It's Releasable?
#9690 posted by Drew on 2010/04/16 04:07:42
#9691 posted by Trinca on 2010/04/16 08:31:44
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 ;)
The Engine Question
#9692 posted by gb on 2010/04/16 14:35:50
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.
Well
#9693 posted by ijed on 2010/04/16 15:05:51
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.
#9694 posted by gb on 2010/04/16 15:26:26
> 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?
Also
#9695 posted by gb on 2010/04/16 15:28:18
engines get used when they're required. Just like Windows.
I Mean
#9696 posted by ijed on 2010/04/16 18:28:15
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 :)
True
#9697 posted by gb on 2010/04/16 19:40:01
but if you *require* DP, isn't it enough if it runs in DP?
(getting hypothetical I guess)
...this Sounds Like An Internal Discussion, But...
#9698 posted by necros on 2010/04/16 19:52:01
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).
Sure DP
#9699 posted by ijed on 2010/04/16 20:27:01
Only is a reasonable requirement, but I prefer to play it safe and support 'lesser' engines as well to hurt the 'customer base'.
I Can Barely Run DP
#9700 posted by meTch on 2010/04/17 02:24:10
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 :/
#9701 posted by gb on 2010/04/17 02:51:15
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.
#9702 posted by ijed on 2010/04/17 06:10:35
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.
|