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/ 

 

 

Does my cross-compiled soundloop exe work ?
http://quakespasm.sourceforge.net/devel/quakespasm_soundloopfix.exe 

 

My mouse gets stuck if I alt-tab out of the engine to do a level hotfix. 

to open the menu. That should free the mouse. 

 

I enabled wheel mouse to scroll the console, so please document any nasty issues. 

Is still locked in top left corner if I alt-tab out, from the menu, console or otherwise. 

 

 

Having to close the engine to do map fixes, I'm pretty happy with the engine. All features are in and working, everything looks crisp, and it's multi-platform.

Cool.