sthalik

> I'm using it 8 years and I _never_ had such performance problems with X server. Have you ever tried it or are you just making it up? I used X11 on a Celeron 400MHz for a few years. Sad, tragic experience. Believe it was FreeBSD 6.x. > All 10 Linux users will keep not giving a damn. Fix'd

> I assume you just read some comparison of Wayland and X11 No. I heard it from a MSFT dude on EFNet years ago, and validated it against my own knowledge. > X server doesn't do GUI. It displays it on a physical or virtual device. Poorly. It's better now, because of multicore CPUs. It was way worse when UP was standard. Waiting for Xorg getting its 'tick' was getting it latency. Not that clicking buttons was slow, but dragging windows, scrolling with the middle mouse button, etc. > Programmers of userspace don't give a flying f*ck because they use library functions and the overhead from talking to X server is minimal. Just because you got the MIT-SHM extension it doesn't magically get better. X11 sucks, and always will.

My solution: borrow ArmA CD from a friend, install using Steam CD-key, uninstall Steam. Like it never existed in the first place. I hope Bohemia has nothing against it. If so, please delete this post, but I won't buy ArmA a second time.

Guys, UNIX GUI is a joke from the technical standpoint. The very idea of doing GUI in userland (the X11 server) is horrible. The only reason why games work well on UNIX is because the GLX 'hack' lets the game talk directly to the kernel. But for the rest of applications it's more like... application -> kernel (system call) -> x11 (userland) -> kernel (system call) -> application. While in Windows... application -> kernel -> application. Edit: Don't forget about copyin/copyout that happens, not just SYSCALL overhead. Also don't forget about scheduling issues for the x server. So if you wonder why a glorified terminal emulator, web browser, or an office program works as badly as it does on UNIX, remember the godawful X11 architecture. Especially on non-top-of-the-line hardware. Two cents from someone who never will write any GUI application for UNIX, except for those that port straight from Windows, using some compatibility layer.

Router-related issue, perhaps? Pinging multiple servers is hard on the routers, such-that it has to create many states. In case you use any type of NAT, it might be the cause. I've had issues with regard to server browsers in multiple games with a Netgear router until I threw it away and replaced with another solution.

How did you transfer the file? Verify MD5 on both ends.

Try: file /home/arma2arrowhead/lib32/libstdc++.so.6 and paste the result.

@kaju: Copy the 'real' one (with a minor .so version, not just major '6') too.

I have a fully-working chroot that works on any Linux system with a fairly recent (2-3 years? I think the requirement was a 2.6.18 kernel) kernel, able to run x86 binaries. So stop spreading FUD about how hard it is to create one. As for the term, I suggest you consult a dictionary. As for your insults, I lost any incentive to help you with your imagined problems. I'll only correct your "facts" from now on.

And to keep this on topic: While alpha works without any mods fine, after loading a handful, clients wait forever to connect, and after disconnecting the log gets: /home/arma/arma/chroot/var/log.2302.txt:NetServer::finishDestroyPlayer(807887649): DESTROY immediately after CREATE, both cancelled Guess for a while I'll be running the Win32 version (WINE 1.5.10) in a VNC X11 session. This one doesn't have any problems, other than lower-than-optimal performance.

Why build the depends? Grab wheezy's .debs, use ar(1) to unpack, then 'data.tar.gz' are the contents. Or copy from some virtual machine installed for this sole purpose. In fact, I just specified the list of shared libraries required for running the alpha. Some of them are symlinks created by ldconfig, though. Linux From Scratch isn't that uncommon, either :) Coupled with some knowledge about the C language, can greatly help many a budding UNIX hacker.

arma ~% id uid=1001(arma) gid=1001(arma) groups=1001(arma) arma ~% /lib32/ld-linux.so.2 Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] [...] --list list all dependencies and how they are resolved --verify verify that given object really is a dynamically linked object we can handle [b][color="#FF0000"] --library-path[/color][/b] PATH use given PATH instead of content of the environment variable LD_LIBRARY_PATH [b][color="#FF0000"] --inhibit-rpath[/color][/b] LIST ignore RUNPATH and RPATH information in object names in LIST --audit LIST use objects named in LIST as auditors This would be a start. Personally I use a chroot, since forever. That doesn't mean that a chroot is required. bin: server etc: group hosts ld.so.cache localtime nsswitch.conf passwd protocols resolv.conf services lib: ld-2.13.so libc.so.6 libgcc_s.so.1 libnss_dns-2.13.so libpthread.so.0 librt.so.1 libz.so.1 ld-linux.so.2 libdl-2.13.so libm-2.13.so libnss_dns.so.2 libresolv-2.13.so libstdc++.so.6 libz.so.1.2.7 libc-2.13.so libdl.so.2 libm.so.6 libpthread-2.13.so libresolv.so.2 libstdc++.so.6.0.17

Using Debian Testing due to net-admin installing Linux. I would have gone for FreeBSD like ^ as well. Never tried depenguinator. Anyone familiar with it?

Guys, You're speaking as if changing libc/libstdc++ was hard or even required root privileges. Devs, thank you very much for the build and continued support of UNIX operating systems. I'll try it with proper-version libraries soonish and see if there are indeed any errors (double free(), heap corruption or somesuch). In case anyone wonders, play with the dynamic linker (ld-linux.so.whatnot), LD_PRELOAD, LD_LIBRARY_PATH or just chroot it (might indeed require root privileges). The latter seems preferable on a multi-user system anyway.

Make sure the video widget is enabled. View -> Video widget. As for Arma, it's quite possibly a distinct issue.

The server is back up. The latest Accela version isn't incorporated, however. If any of you want to test latest Accela, please send a PM and I'll provide a link. I'm requesting help from programmers with regards to filtering jitter in tracker input. Testing and telling it's good is great and all, but the code won't write itself :( Just a mathematics background is fine too, for instance the guy who wrote the EWMA filter does audio processing and not strictly programming.

Lawlcat, after you enable FreeTrack, you have to restart Arma. It'll crash first time, just rerun it. moorsey, yes, it's down. :( I don't have a good place to put my files now, so it'll have to wait. I just improved accela, to quote from my last email to Wim: He has the code for that, of course. Also, I realized that it's important *not* to use FaceAPI internal filtering. It causes very bad lag, often 1/3 of a second or more delayed movement. With newest accela and proper accela curves (can't stress it enough - accela is only as good as the curves are), there's little to no jitter as well as little delay in movement. Hope you guys enjoy it, and let's hope the relevant changes are integrated and released soon.

No. DLL's and .EXE's are changing too. Just extract it to your documents directory and be done with it. For now, there are no further changes unless there are some improvements to be made. Thanks. X-Plane is a nice sim with friendly developers. If only it had any combat... :) Waiting for the TacPack, still. Other than the ipp-5.3 addition, there were no binary changes in the past few days. Can stop furiously updating now :) If you're interested in diffs and changes, point your TortoiseSVN to http://arma.misaki.pl/svn/ftnoir-devel/ There will be no WebSVN interface because that pitiful piece of cr*p deadlocks during IPC with diff(1) when someone browses the repository, thus bringing down the whole FastCGI instance. I don't feel like becoming a developer for each open-source project I use either.

C# is a major pain from a perf standpoint. Every object contains a pointer to its type. Garbage collection is mandatory for all so-called "managed" data. Last time I saw GC'able heap allocation during the render loop in MonoGame when using the VS Ultimate profiler. JVM is nice because it can run Scala.

I'm talking about ipp-5.3.dll and friends in the newest version here: http://arma.misaki.pl/ Edit: There aren't any! Time for a ninja edit... Done. And the install procedure is extracting to some random directory, clicking `Load' and choosing a 'Falcon BMS' profile to base your new profile upon, then creating it and 'Save as'. Note that the Falcon BMS profile was made by me and it's very sensitive. Heard from Wim that he's in the process of merging the changes. Also, the crash fix on exiting should be fixed if it wasn't mentioned already. Turns out freeing stuff in an atexit context where half of our heap is gone already isn't such a good idea.

Why would you get an error? There are IPP exes in the app's directory which should override all existing IPP copies in the system.

Use the FreeTrack protocol for Arma. No need to install either FaceAPI or IPP anymore, in this release they're all bundled. Also you need to activate FreeTrack in Arma separately.

For those getting bad results from my tracker, FaceAPI works again. Turned out to be a simple dll/headers issue. FaceAPI is now separated to a new directory, to allow us to use Qt 4.8.1 with all its bugfixes, while at the same time allowing FaceAPI to function with Qt 4.6.2 it's hardcoded to use.

Half of the code was recently rewritten. Please give it a try now. Should be accurate to 1-2 degrees. Drifts with time, but drifts very slowly. There's autocorrection, too, and works up to 50 deg. But as long as you find the use for the filter, i'm happy anyway that you're using it. It would be better if FaceDetect flourished, but guess can't have it all :) I had to rewrite the code because of bad detection causing weird shifts in view. This no longer happens. Whenever a shift outside the good range, new detection is discarded. Unless there are no points left on a face-part. Also, POSIT is now tracking only 4 points, which gives it correct depth information at all times. If any programmer wants to contribute, now is the time, because the messy parts were rewritten and it's pretty readable by now. The offending part was `face_detect_cycle()'. My new curves after a rewrite look like this: http://img1.uploadscreenshot.com/images/orig/5/14408234052-orig.jpg

FaceAPI sets up its classifiers for several seconds, all while using much CPU. This issue doesn't exist in FaceDetect. > Thanks for trying to explain Accela but I'm afraid most of that went over my head! Let's try explaining one more time. You have a position the tracker detects, as well as the position that's currently transmitted to the game/sim. The latter "catches up". The X is the absolute difference between these 2. More you set for Y for given X, faster it catches up. Just try not to set any position to zero except for zero itself, it always *has to* go faster up than the previous position. This is in my understanding the tangent of a function. The monotonicity is always upward, too. Thank you for your kind words. Here are my curves used with FaceDetect: http://img1.uploadscreenshot.com/images/orig/5/13806411049-orig.jpg Also, if your "multiplier" is lower than mine (40 deg. means for me 180 deg. X, similar for Y upward in a flight sim), you can set more aggressive Accela curves, too.