Yeah, LordHavoc made his own "BSP2" afaik and MH's is now referred to as "2PSB". So much for having standards :P 

The great thing about standards is that there are so many to choose from! 

http://xkcd.com/927/ 

and then I cried.

Actually the choice of engines is great, but the problem is that people are starting to develop maps for one engine only when really they should develop for like 3 or 4. I tested Deck in about 4 engines before I released it (and it did have various bugs in each, annoyingly, I developed the map mainly testing in Fitz to find that it was horrible broke in DirectQ so I spent days fixing that).
Some maps are impossible to develop cross-engine, like I imagine Nyar and socks latest Zendar would be due to their scope and features. But most "ordinary" maps should be tested in several engines. 

Obligatory Not Safe For Work Warning
http://goatkcd.com/927/ 

"All this engine strife should go away soon, there are a number of engines in the works now."

Yes, more engines - complete with their own sets of bugs and idiosyncrasies - will definitely help. *eye roll* :P 

I was referring to the lack of a universally accepted BSP2 (+2PSB) supporting engine for the various maps either in production or already released.

In order to be universally accepted it will require having idiosyncrasies and bugs that do not offend the general user. 

Let me know when there's a universally accepted BSP29 supporting engine. :P 

what are the odds of getting quake 3 bsp support in a fitzquake-type engine?

I mean if we're going down the road of supporting bsp formats that standard engines can't run, I'd have thought people would be looking at that... 

 

Obviously q3 bsp involves a huge amount of work vs just a "limits raised" q1 bsp. 

I know there is a huge difference in the bsp output. Whenever I turn on showtris, it almost looks like QBSP just hacks brushes into pieces at random, whereas the Q3BSP splits things up intelligently and usually no more than necessary. 

With correct use of detail brushes, a q3bsp will tend to be triangulated pretty much the same as if it had been modelled perfectly in a 3d modelling app.

q1bsp r_drawflat 1 looks like someone dropped a stained glass window on the floor then assembled the pieces back together at random.

I'm just a bit of of a ocd 'sperg when it comes to neat triangulation of geometry :} 

The patchwork appearance of a q1 bsp is due to the qbsp splitting up faces to keep them below the 18*18 lightmap sample limit.
Many (gl) engines already bump that up to 256*256 (same as q3), but qbsps don't output for that raised limit by default.
also, q3bsp isn't so scared of overdraw, allowing it to avoid cutting out holes because of a brush sitting above. q1bsp compilers could also do the same, which would help reduce the cuts. engines should be okay with edges with a single side. might need to keep such edges axial though. 

another major argument against q3bsp, when bsp2 was discussed, was that most quake editors don't support it and mappers are generally unwilling to switch tools (unless it's Trenchbroom apparently.)

q3bsp offers so many improvements it's not even funny, and it can still be made to look just like quake. You'll need to drop in a few hint portals of course because q3 vis isn't as "tight" as q1 vis.

The possibility of baking models into the bsp (and have them lightmapped etc) instead of having them be entities is worth the price of admission alone.

Technology by itself isn't "evil", really, so I doubt q3bsp on its own would "kill quake".

but I guess otp is absolutely correct. :-> 

I tracked down a bug in sound looping last night, which appears to have been in Quake since the source release. It causes an intermittent 'pop' when looping sounds wrap around - this has been driving me crazy for years!

https://sourceforge.net/p/quakespasm/patches/12/

This will have good synergy with my "audiophile resampling" patch when I finally dust that off and finish it 

... I did look through and didn't find anything.
RMQ works wonders for me
Whenever I load maps in Quakespasm, however, they almost invariably slow to a choppy crawly barely playable state.
Thus my apparently ungainly habit of not using Quakespasm, and instead using RMQ engine, to record demos and so forth.
I am a luddite. Keep that in mind.
And yes, I did use a big heap size. 

that RMQ has created that Quakespasm doesn't like.

Try running quakespasm on a clean install with no .cfg files to start with and then build your settings from there. 

Try r_dynamic 0 and if that solves your problem, move to Fitz Mark V which fixes that behavior. 

Are the exes compiled to include the ultimate patches? If so are they on the Quakespasm site?

I checked the changelogs but can't see anything mentioned. 

Sorry, I don't have an exe with the patch applied. The QS guys haven't had a chance to review the sound loop one yet. 

I have an engine to test on, although it's not 100% feature complete. 

but szo made windows and osx builds on dec 25 with my bsp2 patch (runs telefragged.bsp). They're here:
http://quakespasm.sourceforge.net/devel/