We'll Check Out ReQuiem
when you fix the bloody widescreen!
Fifth
It's open source, and Spirit is not the author.
Checked it. It's awesome. :)
Re Protocols
#584 posted by Spirit on 2013/12/25 21:06:57
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!
#585 posted by Spike on 2013/12/26 05:18:45
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)...
Linux And Gamma
#586 posted by LeopolD on 2013/12/26 11:31:29
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.
Cheers
I've added that to the subversion doco
Bsp2
So what are the best bsp2 maps/mods ?
These
#589 posted by Spirit on 2013/12/31 10:33:01
Only BSP2 Releases I'm Aware Of
#590 posted by ericw on 2014/01/01 00:04:28
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.
#591 posted by Spiney on 2014/01/01 02:55:45
Yeah, LordHavoc made his own "BSP2" afaik and MH's is now referred to as "2PSB". So much for having standards :P
#592 posted by Spike on 2014/01/01 22:05:06
The great thing about standards is that there are so many to choose from!
Obligatory Xkcd
#593 posted by Spiney on 2014/01/02 01:25:02
I Laughed...
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 Goatkcd
#595 posted by czg on 2014/01/02 10:07:58
Obligatory Not Safe For Work Warning
http://goatkcd.com/927/
#596 posted by JneeraZ on 2014/01/03 14:58:45
"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
Don't Be A Drama Queen
#597 posted by ijed on 2014/01/03 15:23:30
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.
#598 posted by Spike on 2014/01/03 20:18:00
Let me know when there's a universally accepted BSP29 supporting engine. :P
Probably Regret Asking This
#599 posted by Kinn on 2014/01/04 13:03:38
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...
None
Fair Enough
#601 posted by Kinn on 2014/01/04 13:58:34
Obviously q3 bsp involves a huge amount of work vs just a "limits raised" q1 bsp.
#602 posted by Rick on 2014/01/04 16:05:08
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.
Yeah
#603 posted by Kinn on 2014/01/04 16:15:47
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 :}
#604 posted by Spike on 2014/01/04 18:09:47
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.
#605 posted by gb on 2014/01/04 18:43:29
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. :->
|