you are supposed to checkout reQuiem, everyone! 

when you fix the bloody widescreen! 

It's open source, and Spirit is not the author. 

Checked it. It's awesome. :) 

Protocol 999 sounds useful, but the others are deprecated and in my opinion should not be added. Maybe only for playback but recording in them should not be possible. Focusing/Forcing less is better!

Is there any reason to use aguirRe's engines anymore?

Could maps/mods hint to the engines about their needed capatibilities? I don't know how reQuiem detects what protocol to use but I am sure it is not flawless. It would be kinda bad if 666 or 999 are used when they are not actually needed. Backwards compatibility is nice! 

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.