 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
like the vertex lighting code from reQuiem. And the light source code for rockets and grenades etc. Couple that with the nice corona effects from DirectQ and we're cooking with gas! Actually DQ has the best menu out of all the engines IMO, get that in there too x
Freshly built Win32, Win64 and OSX versions from svn r881:
http://quakespasm.sf.net/devel/ Thanks, guys.
A question: now that bsp2 support is in, would it be feasible and/or desirable to add support for protocol 999 (RMQ), however rudimentary? And how about 10002 and 10005, the ones from BJP's enhanced GLQuake. Perhaps there are even some others that only slightly derivate from the common standards. I presume DP protocol would be out of the question, though. The reason is having an engine port that supports a wide(r) range of existing protocols would make demo playback (among other things) a lot more convenient for the general user. As it stands, the several different protocols create quite a bit of a mess, and only relatively few people know their way around it. You could say, another step towards a general purpose engine. Not necessarily an actual feature request, more wishful thinking really. If you already have 666, 999 is a superset that gives support for
DPP7 support has a lot of merit, but full compatibility with DP is a major undertaking, but then you don't need full compat for it to be useful. Also needs mvd+qwd playback! :P 999 would be a good idea though, its the simplest way to get larger coords. Thanks a lot guys !
The OSX version works perfectly on my system. I'm finally able to play that freaking Wicked Mod ! 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. 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
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/
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |