Bit Blot Forum
Aquaria => Support => Topic started by: flabbergastedpickle on January 16, 2012, 04:48:58 pm
-
I guess the following question is primarily for the devs but I am also hoping others might have some idea how to address this as well, so here it goes...
First of all, many thanks for supporting Linux platform! After having used Linux for 14 years, it is so great to see this noticeable growth in Linux support :-)
I am using 64-bit version of Oneiric Ubuntu on a Sandy Bridge laptop with Intel HD 3000 video card. The game runs smooth and everything works as expected, except that every single 2D texture throughout the game, including loading screen, splash logo, menu, and in game textures, has a faint rectangle around it, almost as if antialiasing of the texture is buggy and generates darker areas around the edges when trying to alias with non-existing pixels beyond the texture's edge, resulting in this corruption. Naija literally has dozen of them as each part of her body is I presume a separate 2D texture applied inside the 3D context. So, to clarify, the rectangles appear even around 2D textures whose edges are supposed to be transparent. Aquaria is not the only game that has this problem. Apparently Myth II (native version) also exhibits this problem. Yet, there are tons of other 3D games that have none of these problems which makes me wonder whether both Myth II and more importantly Aquaria use some older 2D texture OpenGL draw function that may not be as commonly used any more and thus the drivers may need more work in this area (since devs usually focus on the most prominent bugs first and Sandy Bridge is still a relatively new platform). If so, identifying this OpenGL call would be very helpful as that would help me push this issue forward upstream...
I also wrote about this problem on ask ubuntu seeking help from the devs there but no dice yet. Even with the latest Intel drivers nothing changes. For the ask ubuntu page please see: http://askubuntu.com/questions/95508/3d-textures-on-intel-hd-3000-have-edges-rectangles-that-should-not-be-visible
Also, below are 2 screenshots from Aquaria and Myth II (obviously the first one is more relevant here):
http://img59.imageshack.us/img59/6900/intel3000oneirictexture.jpg
(Aquaria--note the faint light gray-ish lines denoting bunch of rectangles around the image, one of which was curved, probably for the wavy sea grass texture)
http://img341.imageshack.us/img341/457/mythintel3000rectangles.jpg
(Myth II--here the rectangles are more apparent; those units are not selected but have those persistent rectangles on top of any selection rectangle which is usually green; also, note any 2D object on the ground has one of those as well)
Any thoughts?
-
Did you compile yourself or are you using an old commercial release?
Two things to try would be to enable/disable displaylists and enable/disable the framebuffer and/or darkfbuffer (see your ~/Aquaria/preferences/usersettings.xml file).
Or change your driver settings, including antialiasing, mipmapping, optimizations, whatever you find.
I wish i could reproduce it but i have never seen this and no idea which OpenGL function could be implemented so bad in the driver that it screws up like this.
(FYI, The OpenGL functions the game uses are listed here: http://hg.icculus.org/icculus/aquaria/file/tip/BBGE/OpenGLStubs.h. I can't recall that GLU is used/linked at all.)
But it's clearly a driver problem. No problems here - I use a Radeon 6850 with windows/linux and the linux catalyst drivers aren't known to be exceptionally good. But still better than the intel drivers.
[troll] The easiest solution would be to drop intel cards (they suck) and possibly ubuntu (It's the mac of linux), but oh well, not a feasible solution i suppose. [/troll]
-
Thanks for the reply. This is the Humble Bundle version. I tried changing both framebuffer and darkbuffer and neither (or both) had any effect on the issue... Also, thanks for the .h file. I will try to include that in my report upstream...
As for OS/drivers, I guess each to their own... I have a MBP currently collecting dust on my desk as ideologically I don't agree with the way Apple works. Same for intel card. While its driver is in many ways inferior, which is in part because it is still fairly new, at least it is open and is supported (apart from the aforesaid buggy driver behavior), including suspend and other core usability matters.
Again, thanks for the info...
-
Ok, the HiB version is 32 bits only, and old.
Go and build from source, so that it can load the native 64 bit drivers. Could be that only the 32 bit ones are screwed.
EDIT: Or wait, i just saw that there is a 64bit version now. Didn't see those the last time i checked. But no idea from which code revision those are made.
For a quick test, you can try some linux binaries I compiled a few days ago: http://dl.dropbox.com/u/22111385/crap/Aquaria_linux.zip
Copy the contents of the "newfiles" folder, and the 64 bit binary into your Aquaria install dir, but keep a backup of the original binary. It should be able to run with the updated files as well.
But note that these binaries are meant only for testing, but should do for the time beeing, if they fix the problem. Look out for real updates in some time.
-
Again, many thanks for the quick reply. 32-bit issue is an incredibly good point as both games affected are now known to be running in 32-bit so this very well might be it... Now if only we could prove it by running Aquaria in 64-bit without problems :-)
So, I downloaded the said file as instructed, backed up original install directory to /opt/Aquaria.bak and left a the old /opt/Aquaria to mess with. Then I copied all the contents of the Aquaria_linux/newfiles/ into the /opt/Aquaria folder, and finally copied Aquaria_linux/64bit/aquaria into the same /opt/Aquaria/ folder overwriting the old executable. However, now when starting the game I simply get:
./aquaria
bash: ./aquaria: No such file or directory
(I am running from the command line to monitor any potential output... The old version runs just fine from the command line)
The file has proper exec permissions (same as the old executable). Nothing else has changed on my system...
Any ideas?
Many thanks for all your help!
-
what does `file ./aquaria` tell you?
either the file is there and something is screwed up, or whatever unpacker you used put it into a wrong directory. "No such file or directory" ... you sure the file is *really* there?
(Xiagan tested this pack and it worked for him.)
So, double-check it is really there and ls -lshA gives useful infos.
I usually run it from console too, so that *can't* be an issue. It even works on Mac this way, lol.
The file util gives me this, for the 64 bit one:
./aquaria: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.27, BuildID[sha1]=0x78fb72739d574a0babc37fd41219bccacf99fb44, stripped
EDIT: I forgot: i used strip on the binary *after* i made+uploaded the ZIP (to see how much it would shrink), so the checksum has probably changed. Just in case you were wondering.
-
This is what I get when I run those:
$ file ./aquaria
./aquaria: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.27, not stripped
$ ./aquaria
bash: ./aquaria: No such file or directory
$ ls -lshA
total 5.7M
3.7M -rwxr-xr-x 1 root root 3.7M 2012-01-16 13:14 aquaria
32K -rw-r--r-- 1 root root 32K 2011-11-03 19:28 aquaria.png
4.0K drwxr-xr-x 2 root root 4.0K 2012-01-01 23:44 config
4.0K drwxr-xr-x 7 root root 4.0K 2012-01-01 23:44 data
4.0K -rw-r--r-- 1 root root 2.9K 2011-11-03 19:28 default-1.xml
4.0K drwxr-xr-x 4 root root 4.0K 2012-01-01 23:44 docs
52K drwxr-xr-x 181 root root 48K 2012-01-01 23:44 gfx
52K -rwxr-xr-x 1 root root 49K 2011-11-03 19:28 libgcc_s.so.1
244K -rwxr-xr-x 1 root root 242K 2011-11-03 19:28 libopenal.so.1
492K -rwxr-xr-x 1 root root 492K 2011-11-03 19:28 libSDL-1.2.so.0
1.2M -rwxr-xr-x 1 root root 1.2M 2011-11-03 19:28 libstdc++.so.6
4.0K drwxr-xr-x 2 root root 4.0K 2011-11-03 21:07 maptemplates
4.0K drwxr-xr-x 6 root root 4.0K 2012-01-01 23:44 _mods
4.0K drwxr-xr-x 2 root root 4.0K 2012-01-01 23:44 mus
4.0K -rw-r--r-- 1 root root 276 2011-11-03 19:28 README-linux.txt
4.0K drwxr-xr-x 8 root root 4.0K 2012-01-01 23:44 scripts
4.0K drwxr-xr-x 4 root root 4.0K 2012-01-01 23:44 sfx
4.0K -rw-r--r-- 1 root root 2.6K 2011-11-03 19:29 usersettings.xml
12K drwxr-xr-x 2 root root 12K 2012-01-01 23:44 vox
4.0K -rwxr-xr-x 1 root root 2.7K 2011-11-03 19:29 xdg-open
Maybe I need to remove libs from that folder as they I suspect are 32-bit?
EDIT: tried without those libs in the folder and still the same problem.
-
`ldd aquaria` ? If it says something about "not found" or so then it's probably that, and you need to install anything that is missing. (If this helps i need to remember this for the actual update pack!)
does the file name contain spaces by accident?
Man, this is really strange, i'm kinda out of ideas now.... ???
Well if nothing else works, hg clone the repo, cmake, make, compile the code, and use that binary. If you need help with this, let me know.
Gosh, such a mess.
EDIT: Maybe a ubuntu-generic problem. http://stackoverflow.com/questions/3949161/no-such-file-or-directory-but-it-exists - AFAIK bash should output why it can't exec a file, and not what it is doing in your case. Weird.
EDIT2: Not ubuntu-generic, if i purposefully mess up the linker flags i get this too. Hrm.
Anyways, here's my ldd output:
myhost /home/fg/code/aq/build # uname -a
Linux myhost 3.1.0-4-ARCH #1 SMP PREEMPT Mon Nov 7 22:47:18 CET 2011 x86_64 Intel(R) Xeon(TM) CPU 3.40GHz GenuineIntel GNU/Linux
myhost /home/fg/code/aq/build # ldd aquaria
linux-vdso.so.1 => (0x00007fff5373d000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x00007f0327aa6000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f0327889000)
libopenal.so.1 => /usr/lib/libopenal.so.1 (0x00007f032763c000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f0327337000)
libm.so.6 => /lib/libm.so.6 (0x00007f03270b5000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f0326e9f000)
libc.so.6 => /lib/libc.so.6 (0x00007f0326b18000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f0326914000)
/lib/ld-linux-x86-64.so.2 (0x00007f0327d3f000)
librt.so.1 => /lib/librt.so.1 (0x00007f032670c000)
Maybe this helps...
-
Here's my ldd output:
./aquaria: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./aquaria)
linux-vdso.so.1 => (0x00007fff8bbb7000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x00007fc7c6540000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc7c6323000)
libopenal.so.1 => /usr/lib/libopenal.so.1 (0x00007fc7c6072000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc7c5d6b000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc7c5ae7000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc7c58d0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc7c5531000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc7c532d000)
libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x00007fc7c5128000)
libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007fc7c4ee1000)
/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fc7c67fc000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc7c4cd9000)
libpulsecommon-1.0.so => /usr/lib/x86_64-linux-gnu/libpulsecommon-1.0.so (0x00007fc7c4a7a000)
libjson.so.0 => /usr/lib/x86_64-linux-gnu/libjson.so.0 (0x00007fc7c4872000)
libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007fc7c462e000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fc7c4412000)
libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007fc7c4209000)
libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007fc7c3fa1000)
libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007fc7c3d9b000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fc7c3b98000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fc7c3991000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fc7c3777000)
libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007fc7c352d000)
libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007fc7c305d000)
libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007fc7c2e31000)
libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007fc7c2c2a000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fc7c2a0e000)
Seems to complain about GLIBC 2.14. Latest Ubuntu ships with 2.13, so your version might be bleeding edge. Any chance it could be recompiled with 2.13?
-
Ugh, sorry... using arch linux and they are always bleeding edge (can indeed be annoying sometimes). In fact i haven't updated that system for months, and it's the oldest one i have.
I'll see what i can do and come back to you once i have a definite solution. Will need this for public update packs anyways...
stay tuned!
-
No problem! Actually, I just built the version from icculus with debug disabled (as per instructions on your site) and it works perfect and all the artifacts are gone, so this is definitely a problem with the ia32-libs. Let me know if you need the binary (I did not strip anything from the binary).
Once again, many thanks for all your help!
-
Update: New linux builds.
I got myself 2 bootstrapped+chrooted debian lenny inside arch linux, 32 and 64 bits, and am using these as build slaves now.
Would be nice if you tested the builds.
Files: 7z (http://dl.dropbox.com/u/22111385/crap/Aquaria_update_linux.7z) | zip (http://dl.dropbox.com/u/22111385/crap/Aquaria_update_linux.zip) | tar.gz (http://dl.dropbox.com/u/22111385/crap/Aquaria_update_linux.tar.gz)
Pick whatever you like, they all have the same content. chmod +x the included launcher script if it refuses to run.
But beware it's not intended as a public update; rather a test to see if i'm now in the shape to do linux builds that actually work on more machines than mine.
The included libs are old, yet work on my bleeding edge machine. And the dependencies are down to a minimum.
Checked with ldd & objdump, i think i figured out the configuration that Ryan C. Gordon used when he made the HiB builds, and am using that now. :)
The used OpenAL-soft lib can utilize the following audio backends: ALSA, OSS, PulseAudio, PortAudio. I rememeber a post (http://www.bit-blot.com/forum/index.php?topic=3713.0) that said pulseaudio didn't work.
glVertex3i() is additionally used in one place, unlike in the original code, if that makes any difference.
Based on the icculus.org code, with a few patches that were sent to the mailing list but haven't been applied yet.
And about what you wrote on askubuntu.com (http://askubuntu.com/questions/95508/3d-textures-on-intel-hd-3000-sandy-bridge-have-erroneous-rectangles-in-32-bit-gl), i am NOT an Aquaria developer. Yes, i am hacking on the code, but nothing more. Just to make that clear.
If you want official support, nag Alec (http://www.bit-blot.com/forum/index.php?action=profile;u=2), but he is busy making awesome stuff, so he doesn't answer very fast, if at all :)
-
Many thanks for the update! (and sorry to both you and the main dev for giving you the wrong title ;-)
Hmmm, plot thickens... I just tried both aquaria32 and aquaria64 and neither of them have artifacts any more. I did this doing the following:
cp -r /opt/Aquaria /opt/Aquaria.bak
cd /opt/Aquaria
cp -r ~/Downloads/Aquaria_update_linux/* .
./aquaria32
...
./aquaria64
This way I overwrote everything in the Aquaria folder with the stuff found inside Aquaria_update_linux folder. Then I simply ran aquaria32 and aquaria64
aquaria32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
aquaria64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
ls -lshA /opt/Aquaria
8.0K -rwxr-xr-x 1 root root 4.2K 2012-01-18 00:24 aquaria
3.6M -rwxr-xr-x 1 root root 3.6M 2012-01-18 00:24 aquaria32
4.2M -rwxr-xr-x 1 root root 4.2M 2012-01-18 00:24 aquaria64
32K -rw-r--r-- 1 root root 32K 2012-01-16 17:48 aquaria.png
4.0K drwxr-xr-x 2 root root 4.0K 2012-01-16 17:48 config
4.0K drwxr-xr-x 7 root root 4.0K 2012-01-16 17:48 data
4.0K -rw-r--r-- 1 root root 2.9K 2012-01-16 17:49 default-1.xml
4.0K drwxr-xr-x 4 root root 4.0K 2012-01-16 17:49 docs
52K drwxr-xr-x 181 root root 48K 2012-01-16 17:48 gfx
4.0K drwxr-xr-x 2 root root 4.0K 2012-01-18 00:24 lib32
4.0K drwxr-xr-x 2 root root 4.0K 2012-01-18 00:24 lib64
52K -rwxr-xr-x 1 root root 49K 2012-01-16 17:48 libgcc_s.so.1
244K -rwxr-xr-x 1 root root 242K 2012-01-16 17:48 libopenal.so.1
492K -rwxr-xr-x 1 root root 492K 2012-01-16 17:48 libSDL-1.2.so.0
1.2M -rwxr-xr-x 1 root root 1.2M 2012-01-16 17:48 libstdc++.so.6
4.0K drwxr-xr-x 2 root root 4.0K 2012-01-16 17:49 maptemplates
4.0K drwxr-xr-x 6 root root 4.0K 2012-01-16 17:48 _mods
4.0K drwxr-xr-x 2 root root 4.0K 2012-01-16 17:49 mus
4.0K -rw-r--r-- 1 root root 276 2012-01-16 17:48 README-linux.txt
8.0K -rw-r--r-- 1 root root 4.6K 2012-01-18 00:24 README.txt
4.0K drwxr-xr-x 8 root root 4.0K 2012-01-16 17:49 scripts
4.0K drwxr-xr-x 4 root root 4.0K 2012-01-16 17:48 sfx
4.0K -rw-r--r-- 1 root root 2.6K 2012-01-16 17:48 usersettings.xml
12K drwxr-xr-x 2 root root 12K 2012-01-16 17:48 vox
4.0K -rwxr-xr-x 1 root root 2.7K 2012-01-16 17:49 xdg-open
(there is still old 64-bit aquaria in there but I did not run that one)
My response: What the heck is going on? What did you change in the 32-bit build since the last time? What is even wierder is that there is no mention of libGL or libGLU in the ldd so what might be the cause of this? Is it perhaps libSDL (but Myth II does not even use that lib)?
Here is the ldd on my machine for Aquaria and Myth II:
$ldd ./aquaria32
linux-gate.so.1 => (0xf771b000)
libSDL-1.2.so.0 => /opt/Aquaria/./lib32/libSDL-1.2.so.0 (0xf76b9000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf767b000)
libopenal.so.1 => /opt/Aquaria/./lib32/libopenal.so.1 (0xf7631000)
libstdc++.so.6 => /opt/Aquaria/./lib32/libstdc++.so.6 (0xf7543000)
libm.so.6 => /lib32/libm.so.6 (0xf7519000)
libgcc_s.so.1 => /opt/Aquaria/./lib32/libgcc_s.so.1 (0xf750c000)
libc.so.6 => /lib32/libc.so.6 (0xf7392000)
libdl.so.2 => /lib32/libdl.so.2 (0xf738c000)
/lib/ld-linux.so.2 (0xf771c000)
librt.so.1 => /lib32/librt.so.1 (0xf7383000)
$ldd ~/Games/Myth\ II/Myth2
linux-gate.so.1 => (0xf77a4000)
libGLU.so.1 => /usr/lib32/libGLU.so.1 (0xf770d000)
libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7622000)
libm.so.6 => /lib32/libm.so.6 (0xf75f7000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf75d9000)
libc.so.6 => /lib32/libc.so.6 (0xf745f000)
libGL.so.1 => /usr/lib/i386-linux-gnu/mesa/libGL.so.1 (0xf73ef000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf73d4000)
libdl.so.2 => /lib32/libdl.so.2 (0xf73ce000)
/lib/ld-linux.so.2 (0xf77a5000)
libglapi.so.0 => /usr/lib32/libglapi.so.0 (0xf73b8000)
libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7282000)
libXext.so.6 => /usr/lib32/libXext.so.6 (0xf726f000)
libXdamage.so.1 => /usr/lib32/libXdamage.so.1 (0xf726b000)
libXfixes.so.3 => /usr/lib32/libXfixes.so.3 (0xf7265000)
libXxf86vm.so.1 => /usr/lib32/libXxf86vm.so.1 (0xf725e000)
libdrm.so.2 => /usr/lib32/libdrm.so.2 (0xf7252000)
libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7233000)
librt.so.1 => /lib32/librt.so.1 (0xf722a000)
libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7226000)
libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf721e000)
What do these two have in common (or had in common)?
EDIT: even if I just put aquaria32 in the /opt/Aquaria folder with no other files included (albeit I've already included addition of new files from the newfiles folder in the package you asked me to download before) it works without the glitches...
-
I used the stable SDL 1.2.14 release with unncessary stuff excluded, nothing else.
All OpenGL-stuff is loaded dynamically by SDL, and none of my changes touch anything related to openGL except that this one more function is used, but not for the images/textures.. only for obstruction grid rendering (the parts of the map where you can't go, that are black).
Maybe because the HiB release was built on a 2.4 kernel...
Seriously, i have no idea. But good to know that it works, one step nearer to a real update pack. :)
Fun fact: For me, both the HiB one and my 32 bit binary crash when loading maps that have entities or tiles that mess with the obstruction grid. But it's a problem in the bleeding edge libc-32, that doesn't go well with my catalyst driver.
EDIT: Hm. Maybe it crashes for me, and for you, it produces these rectangles instead. Who knows what's going on between all these libraries under the hood... my linux knowledge is still idling a bit above zero, but maybe someone else on the forum has an idea.
-
So might it be simply a different SDL lib? Is it really that easy? Going to do some digging around...
(then again, Myth2 AFAIK does not link against it, or at least ldd does not report it)
-
Just thought of something to try...
You could try treating Myth with patchelf (http://nixos.org/patchelf.html) (which replaces the older chrpath), and set the rpath to $ORIGIN/lib32 or something, and put the lib32 folder from my builds next to it, so it will load these, and not the system ones. You will possibly have to escape $ORIGIN (http://itee.uq.edu.au/~daniel/using_origin/), so that the shell doesn't mangle it.
Then use ldd and objdump -x Myth2 | grep RPATH or readelf -d Myth2 | grep RPATH to verify it loads the new libs. If objdump literally prints $ORIGIN/lib32, you've been successful. You can also test objdump on aquaria32.
(Fyi, when compiling, I used -Wl,-rpath,\$ORIGIN/lib32 from ccmake, as CXX flag.)
Well... this is more random experimenting than anything else. :P
But one thing Myth2 and aquria32 do NOT have in common is that Myth2 uses system libs only. Could be the problem, but i doubt it - it would mean the ubuntu packagers have messed up.
The HiB release ships its own libraries too, and nevertheless it had the rectangles.
-
Hmmm, this may be potentially possible but I would probably have to move all the libs into that new folder, no? Also, some libs are in /lib32/ and other are in /usr/lib32 folder... Is it possible to change that prefix for only some of the libs?
I am also suspecting that the game might be using statically linked SDL (although I have no proof at this point as nm executable gives me no symbols). so until I hear from the Myth 2 folks, it's going to be difficult to move forward...
Once again, many thanks for all your help!
-
I meant ./lib32 inside of the Myth2 dir, which is basically what $ORIGIN/lib32 translates to. /usr/lib32 are the system ones, don't touch them.
RPATH is just to tell the dynamic linker to check the specified directories before the system ones, allowing you to replace libs. There is another way with environent variables (world of goo uses this), but it is rather hackish.
And why "all the libs" ? Mine's just 4 ...
Statically linked SDL would be against the LGPL, unless they published their source code.
You could try to find SDL-related strings in the binary with a hex editor just for fun...
-
Never mind. I misunderstood what RPATH stood for. I thought it is a prefix for all lib paths but instead it is another path altogether that is searched before looking through system paths. Speaking of hacki-ish ways, couldn't I simply do LD_PRELOAD=path-to-lib executable and do one lib at a time? Alternatively, what version of patchelf would you recommend since there is no recent release for Ubuntu or any other distro (latest one was from 2008 or thereabouts)?
EDIT: tried LD_PRELOAD trick with all 4 of your libs as well as individual ones and no change. I also tried to preload alternative libGL.so.1.2 and that made no difference either... Is there still a point of trying patchelf?
-
Yes, LD_PRELOAD is almost the same thing, just had forgotten the variable name yesterday.
If ldd says your custom libs were loaded, there is no point in trying patchelf. Haven't tried it myself though.
Looks like the Myth2 devs need to help you now ;)
-
Many thanks for all your help!
As it turns out apparently Myth does statically link against SDL and hence LD_PRELOAD has no effect in respect to SDL lib (AFAIK). I am curious to hear why is SDL being statically linked (hopefully they are not using some kind of hacked version) and if there is a way to get a build that is dynamically linked. Myth2 BTW is not open-source so there is no way for me to recompile it...
-
Sorry to bother you again, but I am wondering can you tell me what exact OpenGL function did you add and what does it do? I am still having no luck trying to identify the source of this problem even on Aquaria-side. The old and new 32-bit binaries only differ in that the new one relies on system libs and yet when I LD_PRELOAD included one it still doesn't show any problems (unless I am missing something)...
-
glVertex3i(). It is like glVertex3f(), just taking 3 integers instead of float for vertex coordinates. Internally, on openGL side, it may as well be impemented to convert the integers to floats and call glVertex3f(). But not sure.
But as said earlier, this has nothing do do with it. It *might* be because of SDL, but more likely is some internal gfx driver failure. If you really want i can make a version that does not use glVertex3i(), but it will be the same as it is now. Or build from current *original* icculus code, and not my patched version. Although you'd miss a few goodies then :P
Btw, unrelated note, there is way too few activity on this forum, so you're not bothering me or anyone. Just go ahead.
-
Actually both of the scenarios you suggested would be interesting to test just to figure out where the problem lies.... If both of these don't exhibit the problem then we'll need to look into build environment/flags in hope to find the culprit...
Another interesting thing is that Myth2 dev built a fully dynamically linked version (including SDL) and the problem persists, albeit I get this weird error when trying to run it:
Inconsistency detected by ld.so: dl-close.c: 743: _dl_close: Assertion `map->l_init_called' failed!
This happens only a few times per session, though... What could this mean when the executable is supposed to be fully dynamic?
http://tain.totalcodex.net/forum/viewtopic.php?f=2&t=5800&start=15
-
I have some time this evening to do some testing... Any chance you could get me the two executables to test as discussed above? That would be awesome :-)
Alternately, is there a repository of source of older executables that I might be able to compile on my own?
-
Wait, what? Didn't get that one.
Anyway, if you need really old stuff, grab the icculus repo and checkout the initial changeset rather than tip, that should closely resemble the HiB builds (But you seriously don't want to use that version anymore except for testing).
And before i forget, i configured SDL like this:
./configure --enable-x11-shared=yes --disable-video-svga --disable-video-fbcon --disable-video-directfb --disable-arts --enable-input-tslib --disable-audio
Which keeps the dependencies minimal (32bit .so below):
linux-gate.so.1 => (0xf7702000)
libm.so.6 => /lib32/libm.so.6 (0xf7657000)
libdl.so.2 => /lib32/libdl.so.2 (0xf7652000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf7637000)
libc.so.6 => /lib32/libc.so.6 (0xf7494000)
/lib/ld-linux.so.2 (0xf7703000)
Ubuntu SDL has more stuff enabled for sure. I saw that Myth has --disable-audio too, btw...
EDIT: The error you are getting are incompatibilities between some runtime libs on your system vs. what myth expects, or between the runtime libs myth has already loaded, and SDL can't cope with, because it loads your system libs ADDITIONALLY...? Not sure what the dynamic linker is doing there. I imagine that there are structures in use that have changed, and either myth or SDL expect another version (= diff. memory layout)... that is, Myth passes a structure to SDL, and that, which is using your system libs and not those myth has loaded, fails because the memory layout is different. Or the other way around. Whatever, i might be wrong. In any case, this is not functional.
-
I was hoping you could produce 2 binaries you suggested in your previous email for me to test as I am not sure how I can check out older branch from icculus (what is the command for that?).
I think the current icculus code already creates properly working executables for me (at least 64-bit ones, BTW how do I build 32-bit one on a 64-bit machine?), so I would need to figure out how to get the original source of the HiB release... Any ideas?
-
Never mind. No matter what I tried, I could not reproduce the problem on my machine even when forcefully building a 32-bit version of the app so this clearly has something to do with a discrepancy between build environments and that's that...