Author
|
Topic: The MegaMod 0.8.0 has finally arrived! (Read 47614 times)
|
darklord42
*Many bubbles*
 Offline
Posts: 208
|
I have a question. I know the game is suppose to be compiled for 32 bit, but I have never noticed any issues with compiling it 64bit on my linux machine. Nor have I noticed any issues with doing so right off that bat. Are there any reasons not to?
If 32 bit is the recommendation what is the best way to do so on 64 bit linux?
I tried going to config_proginfo_build and setting cflags, cxxflags, and ldflags to -m32. Only at the linking stage it fails to link the 32bit libraries...
/usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu/libSDL.so when searching for -lSDL
I already have gcc-multilib g++-multilib and libc6-dev-i386
It's just very odd...
|
|
|
|
« Last Edit: April 15, 2018, 06:04:30 am by darklord42 »
|
Logged
|
|
|
|
|
|
darklord42
*Many bubbles*
Offline
Posts: 208
|
but it's not as simple as pointing a 64-bit compiler at it.
Really? I always thought that was Exactly what it took! If it compiles, then the outputting binary is 64bit. The OS certainly seems to think so, which will be good enough for apple down the road:
/home/joshuapettus/Downloads/UQM-MegaMod-0.8.0-MegaMod_Rev.6/UrQuanMasters: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=31a297b1ed7857b5a82a9bbf185632a7ce745be2, not stripped
I'm really not sure what technicality you are referring? Does the outputting binary not address more then 4 gigs of RAM? (or 1 something in the case of windows). Heck, I couldn't even run a 32bit binary in 64bit linux without some finagling. That's never default. You cant link 32bit libraries to a 64bit binary. It can't be done. It would fail at the linking process which the opposite of which is what I'm getting now. It's trying to link 64bit libraries on the 32bit binary I asked for. Otherwise it would successfully build the 64bit binary.
Heck, I don't even know if the necessary libraries are fully 64-bit compatible.
Those are all standard libraries and It's not hard to get them for 64bit for linux and osx. Every distro package manager has them. You should look into chocolaty for windows. I would expect to find them there.
|
|
|
|
« Last Edit: April 15, 2018, 03:33:19 pm by darklord42 »
|
Logged
|
|
|
|
Elestan
*Smell* controller
Offline
Posts: 431
|
but it's not as simple as pointing a 64-bit compiler at it. Really? I always thought that was Exactly what it took! If it compiles, then the outputting binary is 64bit.
Porting to 64-bit isn't rocket science,but it's not as easy as just compiling it with a 64-bit compiler. The code is probably making assumptions about the size of integers and/or pointers being 32 bits, so even if it compiles, it's likely to crash or have other new bugs.
Heck, I don't even know if the necessary libraries are fully 64-bit compatible. Those are all standard libraries and It's not hard to get them for 64bit for linux and osx. Every distro package manager has them. You should look into chocolaty for windows. I would expect to find them there.
The problem is that someone will have to go get 64-bit versions of all of the 3rd-party libraries UQM needs on three different platforms, modify the build scripts to use them, and debug the result. That's not necessarily hard, but it's a lot of grunt work, And if any of the 3P libraries aren't available in 64-bit, you've got a bigger problem. For example, I'm not sure if there's a version of SDL 1.2 for 64-bit OSX. If there isn't, then UQM would have to port to SDL 2.x, which has a different API, and would require rewriting a bunch of the code. And then you have to deal with any incompatibilities in the new SDL's dependencies, and keep working your way up the chain until you find a new set of compatible versions.
I've done ports like this, and they're usually a pain in the tail, especially on multiplatform products with many external dependencies.
|
|
|
|
|
Logged
|
|
|
|
darklord42
*Many bubbles*
Offline
Posts: 208
|
As I said, those are all standard libraries. Finding 64bit versions isn't hard.
For instance If you download the SDL1.2 framework right off of their page, you will find it contains both the 64bit and 32bit libraries included right in it. (The advantage of frameworks over dylibs is that they can contain multiple versions of the library in a single package). Remember apple has been a 64bit OS for well over 10 years. Or if if you prefer dylib versions, you can install macports and do "sudo port install libsdl" *or whatever the package name* then "+universal" if you want 32 bit versions as well or leave "+universal" out and it will download 64bit versions.
There are plenty of sdl 1.2 apps that are 64bit
As for any crashes in the code with a 64bit binary of UQM mega mod. I haven't had any issues, and I've played most way through the game. Which was why I was wondering... You're right, there can be such issues as integer assumtions. Take DosBox for example which I know their dynamic core was written in assembly for a 32bit system, and doesn't make the translation to 64bit very well. But in this case, I think you are way over-thinking this. SDL-1.2 is pretty tried and true.
|
|
|
|
« Last Edit: April 15, 2018, 06:10:33 pm by darklord42 »
|
Logged
|
|
|
|
|
|
darklord42
*Many bubbles*
Offline
Posts: 208
|
There may be certain edge case scenarios where there is a crash I suppose, but then again, how is that different from any other day. 
As for build scripts. I didn't have to do anything to make it do 64bit. That's default on the 64bit system. It's trying to get it to do 32bit that's hard, and I hadn't figured out if you read my first post on the top of the page.
There is this nice patch that lets you choose the compiler with the $CC and $CXX environment variables, that I don't think is a bad idea...
http://forum.uqm.stack.nl/index.php?topic=5797.0
|
|
|
|
« Last Edit: April 15, 2018, 08:19:48 pm by darklord42 »
|
Logged
|
|
|
|
|
|
darklord42
*Many bubbles*
Offline
Posts: 208
|
Well you are in good company. Neither am I. I'm a network engineer by trade, but like you, I love to tinker.
Anyway I'm not sure how MS Visual Studio works. I never had the money to get it. Gun to my head I would try cygwin and install the mingw compiler, then use the cygwin installer to install the 64bit sdl , sdl image, zlib, and ogg vorbis libraries. Then I would try to compile. No idea if it would work though. Though I do remember seeing mingw mentioned in the build files. I use to have a mingw setup on my mac which could compile windows binaries. I'm sure I could do the same on this linux box should I find the time.
|
|
|
|
|
Logged
|
|
|
|
|
|
PRH
*Many bubbles*
Offline
Gender: 
Posts: 209
|
I've found two bugs in the MegaMod so far.
First, when an alien race's sphere of influence is partially outside the map, the race's name is displayed outside its sphere of influence, rather than inside it. Like this: https://b8.ru.icdn.ru/p/prhmro/upic2.jpg
Second, the game randomly crashes when I'm talking to the Orz.
|
|
|
|
« Last Edit: April 20, 2018, 04:18:23 pm by PRH »
|
Logged
|
|
|
|
|
|
PRH
*Many bubbles*
Offline
Gender:
Posts: 209
|
In the version I have, the game consistently crashes when the Orz says the line labeled GENERAL_INFO_ALLY_3 in the dialogue file, and then I review it in text-only mode. When I first met the Orz, the game also crashed just as their fleet came into contact with my ship.
|
|
|
|
|
Logged
|
|
|
|
|
|
PRH
*Many bubbles*
Offline
Gender:
Posts: 209
|
Apparently the game crashes whenever the Orz say anything that is longer than one page (not just GENERAL_INFO_ALLY_3), and I review the text. This does not happen in conversations with other races (e.g., the Melnorme).
|
|
|
|
|
Logged
|
|
|
|
|
