Re: [ioquake3] FreeBSD PAE kernel broken vm_x86.c, patch attached
On 30/11/2010 20:20, Nerius Landys wrote: Dominic, you seem to be a tad out of the loop as far as Urban Terror 4.1 binaries go. This is understandable if you're not a hardcore UrT fan like me. :-) Actually, I used to play it a lot back when I was looking for a decent Action Quake 2 successor. Compared to baseq3 the performance in UT sucks (mostly unplayable on my notebook), even though the perceived visual quality of plain old Q3 is superior. I think rq3 might be my thing. I didn't take a thorough look, yet. People on Linux now are using mitsubishi's ioq3-urt client (the plain vanilla version mostly, _not_ bumpy). The source code for this is distributed as one big patch file that you apply to ioquake3 trunk (revision 1803 currently). http://www.www0.org/w/Optimized_executable%3b_builds_of_ioq3_engine_for_urt I have not used this client on FreeBSD, however. You may need to adjust the sound stuff, like for example change some of the defaults to turn specific sound features off for FreeBSD. I think I saw that before and I even tried to find some kind of official source distribution. It appears every feedback that does not consist of pure hero worship will be met with burning hate. Release engineering is their enemy. I don't think I'll ever stick my nose in there again. I'll try that patch, but I don't expect it will meet acceptable standards. Now I _am_ running server binaries on FreeBSD and in fact I pretty much maintain the UrT server code (I like to think of myself that way, and in fact quite a few UrT servers use my code). For server admins it's important to apply some hacky patches to ioquake3 so that exploits would not be triggered. There are 2 versions of the server code that I'm maintaining currently: ioUrTded (older, tried and proven, based on original source released with 4.1) and ioq3ded-UrT (newer, not tested for an extended period of time, based on ioquake3 1.36). I'm now moving all of my servers over to use ioq3ded-UrT (my servers are running FreeBSD of course :-) ). More info about ioUrTded is here: http://daffy.nerius.com/urtserver/ More info about ioq3ded-UrT is here: http://forums.urbanterror.info/topic/24118-ioq3ded-urt-improved-server-binary/ I don't understand this separation of server and client. They /should/ all contain the same game logic, shouldn't they? What's the reason behind this? The 64 bit binaries for the server will run on FreeBSD, but they will consume twice as much CPU as the 32 bit binaries running on a 64 bit OS. Don't ask me why, but it's true (and the same applies to Linux from my tests). When I hypothesized my theories on the IRC channel as to why this might be happening, I nearly got castrated. :-P Well, there's been a discussion about pointer handling here. There's some optimization potential, I even intended to give it a go, it shouldn't be a lot of work, but its priority on my TODO list is not high enough. One last thing. That Frozen Sand announced closing the source - that will only apply far into the future, probably. Don't expect them to release the next version of closed-source UrT anytime soon. Even when they do release the new closed-source version, the old 4.1 may still remain popular for some months. So I wouldn't drop any kind of support for UrT 4.1 in the near future. Recent ioq3 is way better what was in the ports before (something from 2007?). I might spice it up with patches later - or not. Quality must be sufficient so that I won't have to deal with these people. Any way, I don't intend to drop UrT 4.1 support. In deed I feel that my move was is large improvement. However, I strongly doubt that there will be 4.2 support. By the way, I compile all of my FreeBSD server binaries by hand, not using ports. Are you talking about urban terror or about server binaries generally? Regards ___ ioquake3 mailing list ioquake3@lists.ioquake.org http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org By sending this message I agree to love ioquake3 and libsdl.
Re: [ioquake3] FreeBSD PAE kernel broken vm_x86.c, patch attached
On 26/11/2010 12:41, Dominic Fandrey wrote: On 25/11/2010 10:02, Dominic Fandrey wrote: On 24/11/2010 23:31, Nerius Landys wrote: I'm maintaining a custom version of 1.36 for Urban Terror so having any updates to 1.36 would be nice, I'm just not sure where to find those updates. There's a bunch of stuff in /usr/ports/games/ioquake3/files, mostly amd64 fixes backported. As soon as someone gets around to commit the openarena update I'll switch the urbanterror port over to using the ioquake engine, because all the code found in the urbanterror project is a mess and they switched to a closed source model any way. OpenArena actually got committed, yesterday. I expect to submit updates for ioquake3, UrbanTerror and OpenArena on Sunday, including your fix. As announced here is the submission for the FreeBSD ports: http://www.freebsd.org/cgi/query-pr.cgi?pr=152637 On a sidenote, this submission also switches UrbanTerror to use ioq3 SVN snapshots instead of code provided by the UrbanTerror project. I found it's not very difficult to accomplish, just patch the STANDALONE section of q_shared.h and make some simple substitutions in the Makefile. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ ioquake3 mailing list ioquake3@lists.ioquake.org http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org By sending this message I agree to love ioquake3 and libsdl.
Re: [ioquake3] FreeBSD PAE kernel broken vm_x86.c, patch attached
On 25/11/2010 10:02, Dominic Fandrey wrote: On 24/11/2010 23:31, Nerius Landys wrote: I'm maintaining a custom version of 1.36 for Urban Terror so having any updates to 1.36 would be nice, I'm just not sure where to find those updates. There's a bunch of stuff in /usr/ports/games/ioquake3/files, mostly amd64 fixes backported. As soon as someone gets around to commit the openarena update I'll switch the urbanterror port over to using the ioquake engine, because all the code found in the urbanterror project is a mess and they switched to a closed source model any way. OpenArena actually got committed, yesterday. I expect to submit updates for ioquake3, UrbanTerror and OpenArena on Sunday, including your fix. Regards ___ ioquake3 mailing list ioquake3@lists.ioquake.org http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org By sending this message I agree to love ioquake3 and libsdl.
Re: [ioquake3] FreeBSD PAE kernel broken vm_x86.c, patch attached
On 24/11/2010 23:31, Nerius Landys wrote: Isn't PAE abandoned? Or at least as good as? Nope. This is an interesting assertion. I don't think I'd touch PAE. 32bit jails simply work, especially on RELENG_8 where uname returns i386 within 32bit jails and all that automake/configure stuff does no longer get confused about the architecture. The thing looks fine to me. If it gets committed here I'll backport it to the 1.36 release, too. If you do backport it to 1.36, you'll have to change MAP_ANONYMOUS to MAP_ANON for FreeBSD systems because MAP_ANONYMOUS isn't defined on FreeBSD systems. The MAP_ANON problem was handled well in trunk. Look at: /usr/ports/games/ioquake3/files/patch-Makefile By the way, is 1.36 svn://svn.icculus.org/quake3/tags/1.36/ ? This code has a newer revision number than the branch version (branches/1.36/ I think). I don't think I've seen any code committed to the 1.36 branch yet. Am I right? Or am I just finding the 1.36 branch in the wrong location? The ioquake port (1.36) port is based on the latest source file release. The ioquake3-devel port is based on svn snapshots. Note that it hasn't been updated in a long while, because I'm waiting for an openarena commit that turns openarena into an ioquake slave port: http://www.freebsd.org/cgi/query-pr.cgi?pr=146818 As soon as this happens I'll create a more recent snapshot. I'm maintaining a custom version of 1.36 for Urban Terror so having any updates to 1.36 would be nice, I'm just not sure where to find those updates. There's a bunch of stuff in /usr/ports/games/ioquake3/files, mostly amd64 fixes backported. As soon as someone gets around to commit the openarena update I'll switch the urbanterror port over to using the ioquake engine, because all the code found in the urbanterror project is a mess and they switched to a closed source model any way. Regards ___ ioquake3 mailing list ioquake3@lists.ioquake.org http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org By sending this message I agree to love ioquake3 and libsdl.
Re: [ioquake3] FreeBSD PAE kernel broken vm_x86.c, patch attached
Hello again. I have some followup information regarding Rambetter-PAE-FreeBSD-fix.patch. First, let me just state that cross-compiling a 32 bit binary on a 64 bit FreeBSD system is currently not supported (for pretty much any 3rd party software such as ioquake3). In general, cross compiling applications won't work on any released version of FreeBSD. (It actually can work but with a lot of manual tweaking of headers and such.) It's probably possible to cross compile with -CURRENT FreeBSD (an unreleased version) because someone committed patches to this extent earlier this year. So, if you want to compile a 32 bit ioq3 binary on 64 bit FreeBSD, your best bet is to either borrow a 32 bit environment from somewhere or make a chroot environment on your 64 bit FreeBSD system. I imagine that the ioquake3 Makefile can stay the way it is (with regards to cross compiling on FreeBSD); it might actually work on -CURRENT. OK, so I compiled two 32 bit ioq3ded binaries on a 32 bit system, one before my patch and one after the patch. I ran both of these binaries on a 64 bit FreeBSD system. Both ioq3ded binaries were able to start. The binary before my patch segfaulted pretty early, the same as was seen on the PAE kernel system. The patched binary ran fine on the 64 bit system. Also, I imagine that nobody will want to run the 64 bit ioq3 binary (for server at least) on a 64 bit FreeBSD system, because that binary is dog slow (same goes for Linux from what I recall). So, everyone will be running the 32 bit server binary probably. If you don't apply my patch, the 32 bit binary won't run on 64 bit systems. FreeBSD is a great system to run ioquake3 servers on, and I have been doing it for 3 years now. I hope this patch makes it into SVN. Thanks! P.S. I have not done any testing for the client side of things, but if someone needs to step up to the plate for that I may be willing to do it. ___ ioquake3 mailing list ioquake3@lists.ioquake.org http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org By sending this message I agree to love ioquake3 and libsdl.
