|
Pages: [1] 2
|
 |
|
Author
|
Topic: UQM on Gentoo linux amd64 (Read 5539 times)
|
azathoth
Guest
|
After a small search on these forums I saw someone mentioning that the game wont run on an amd64 system, but the post wasn't that recent ...
My question is this : I emerged the game using accept_keywords on gentoo, and everything compiled just fine .. no problems whatsoever.
However, the game will pop up a window for a fraction of a second, report 'Killed' after loading 'lbm/title.ani', and, well, die. I'm pretty sure all the content files are in the right locations, and there seem to be no errors reported before that last 'Killed' line : everything is initialized successfully ..
Is this what's supposed to happen on an amd64 system?
Thanks in advance =)
|
|
|
|
|
Logged
|
|
|
|
|
|
azathoth
Guest
|
Thanks , I'm going to try that =)
|
|
|
|
|
Logged
|
|
|
|
nate
Guest
|
hey i was wondering if you might provide a sample of the kinds of things you have to alter in order to get uqm to run on a 64bit machine. im using gentoo too and have studied c++ for a couple of years so for my personal enjoyment of looking through c code (not being sarcastic here  I was wondering if you might post an example. I would appreciate it.
Thanks for your time.
|
|
|
|
|
Logged
|
|
|
|
|
|
Nate
Guest
|
And whats going on here:
typedef void (*PVOIDFUNC) (void);
is this similar to casting?
|
|
|
|
|
Logged
|
|
|
|
|
|
meep-eep
Forum Admin
Enlightened
 Offline
Posts: 2847
|
There are a couple of assumptions that are made in the code that aren't true for 64 bits code.
Most importantly, the size of the pointers and the size of ints.
On most 32 bits platform both are 32 bits. But on most 64 bits platforms, pointers are 64 bits, while ints are 32 bits.
So if you need to store a pointer in an int (you should rarely need this, but it is done in UQM), you get into problems. There exists a type 'intptr_t' which is guaranteed to be big enough to store either which can be used.
Also, structures may have a different size. Either because they contain types that have a different size, or because they are padded to 64 bits. It happens that assumptions are made about the size of a structure that don't hold on a 64 bits environment. In UQM some structures are dumped to a saved game as a block. This is fast, but it leaves saved games incompatible between 32 and 64 bits systems.
As for the << and >> opeartors, what macros are you refering too? These operators are often used in macros to extract specific bits from an integer, set specific bits.
For instance, if bits 4 through 8 contain some value you want, you can do
#define GET_BITS_4_8(x) (((x) >> 4) & 0xf)
The 'x >> 4' will return the value of x with the bits shifted 4 positions, so the bits you want are now 0 through 4. But the other bits still contain stuff you don't need (apart from the top 4 bits which were filled in with 0's after the shift), so you perform and & to take only the bits set in 0xf, which are 0 through 4.
Similarly, you can have macros to set specific bits in an int. For instance, to make an int with bits 4 through 8 set to a value contained in x (which should be no larger than 0xf), you could do 'x << 4'.
To make a value of an existing int y, with bits 4 through 8 set to a new value, you first need to have the value of y with the bits 4 through 8 cleared, and then | them with the new value. So
#define SET_BITS_4_8(y, x) (((y) & ~0xf0) | ((x) << 4))
The y & ~0xf0 takes just the bits that are not set in 0xf0.
As for
typedef void (*PVOIDFUNC) (void);
this is a definition of a function pointer type.
You'd say
void (*f) (void);
to make a pointer f to a function taking nothing as arguments, and returning nothing.
To make subsequent code more clearer, the typedef defines a type PVOIDFUNC, so that you can define f instead as
PVOIDFUNC f;
Function pointers in C are ugly. They may be the worst part of C syntax and are not easy to understand. There's a pretty good site explaining all of it on http://www.function-pointer.org/ which may help you.
As an example of how ugly it can get, take a look at the C fun signal:
void (*signal(int sig, void (*func)(int)))(int);
If you understand this, then you're beginning to grasp C functions.
|
|
|
|
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
Nate
Guest
|
I appreciate the explanation. I've been working in servlets and jsps lately, but getting back to c/c++ is always refreshing! Admittedly I have no experience with c so if you don't mind I will continue to post parts of the code that I have questions about.
|
|
|
|
|
Logged
|
|
|
|
venenozo
Zebranky food
Offline
Posts: 5
|
I am running a true 64bit environment winxp64 service pack 1
UQM WORK FLAWLESSLY.. my specs are as follows
AMD ATHLON 4400+ ( Clawhammer) Water
epox MB
2 gig pc 500 Ram verto
2x WD Raptors
SB audigy 2 zs
Geforce 6800 ultra oc on water ...
i can not speak for linux user but xp64 and uqm runs flawless...
thanks ,
Ven
|
|
|
|
|
Logged
|
|
|
|
|
|
venenozo
Zebranky food
Offline
Posts: 5
|
right via the WOW64 emulator ... but none the less what a great game i cant seem to name my ship and captain or to get my remixes to work they seem to work when i installed the game and even after the "time mod" but when i installed ship editing mod to try to rename my ship it defualted back to the original 3do sfx.. is this happening on 32 bit systems as well?
am i doing something wrong with the mods or is it a 64 bit emulation bug ?
|
|
|
|
|
Logged
|
|
|
|
|
|
venenozo
Zebranky food
Offline
Posts: 5
|
i outsmarted my self again ..all working perfectly now ... the remixes really do the game a bit more justice they are awesome and give the game a fresh new feeling..
but put it in the books uqm is perfect on xp64
|
|
|
|
|
Logged
|
|
|
|
Nate
Guest
|
meep-eep,
is this what you mean by storing a pointer in an int?
(remember im a c++ guy for now  )
std::cout << "try to store a pointer in an int..." << std::endl;
int * int_ptr;
int test;
int test2 = 34;
int * int_ptr2; = (int *)test;
int_ptr = &test2;
std::cout << "test2: " << test2 << std::endl;
std::cout << "int_ptrs address: " << int_ptr << std::endl;
test = (int)int_ptr;
std::cout << "is tests value the same? : " << std::hex << test << std::endl;
int_ptr2 = (int *)test;
std::cout << "int_ptr2 takes tests new value..." << std::endl;
std::cout << std::dec << *int_ptr2 << " should be: " << test2 << std::endl;
now my box is 64 bit so I used the flag -m32 at compile time to get this to work. i got a segmentation fault, of course, without it.
|
|
|
|
|
Logged
|
|
|
|
|
Pages: [1] 2
|
|
|
|
|
