reQuiem does it the easy way, but in doing so can become desynced with respect to reliables vs unreliables. really it'll only work reliably where there's no packetloss.
and even then it only selects on a few features.
and even then, there's no guarentee that the client will support svc_version (which is not normally ever used)... 

For those where gamma is not working on linux boxen and the LD_LIBRARY_PATH hack doesn't work because they have a newer SDL, for me this one fixes gamma (with SDL 1.2.15):

export SDL_VIDEO_X11_NODIRECTCOLOR=1

then start quakespasm the usual way. 

I've added that to the subversion doco 

So what are the best bsp2 maps/mods ? 

 

wicked, nyar, rmqwinter11

The rmqwinter11 doesn't really work with the current Quakespasm build, though. Well, e2m1rq seemed to be playable for the few minutes I tested it, but e3m1rq failed to load with a max_edicts exceeded error. 

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.