|
Linux programming... |
Don Freeman
Member #5,110
October 2004
|
Ok...I've never actually did any linux programming before, but I made my project multiplatform as I could. Everything compiles just fine, and I can even run the resulting executeable while in Code Blocks....but when I try to run the program from within KDE it trys to open a window and closes down with no error message or anything ! I use GFX_AUTODETECT_WINDOWED...I read in the manual that the accelerated drivers require root access...how do I do that so my end users can have accelerated graphics? I don't know if that is the problem, but seems likely to me...any suggestions or comments on this would be a great help...::) Thanks to all, -- |
CGamesPlay
Member #2,559
July 2002
|
Run it from a terminal and it will probably say "Shutting down Allegro due to signal number 11". Find out what file you aren't checking fails to load, and fix the problem -- Ryan Patterson - <http://cgamesplay.com/> |
Evert
Member #794
November 2000
|
Quote: but when I try to run the program from within KDE it trys to open a window and closes down with no error message or anything ! It tries to open a file, but this fails. Make sure the program looks for the file in a sensible location (such as the location of the executable, for instance), not just the current directory. Quote: I read in the manual that the accelerated drivers require root access...how do I do that so my end users can have accelerated graphics? You don't. The adminstrator has to install the program in such a way that it runs with root privileges ("suid root"). Quote: I don't know if that is the problem No. EDIT (from below) Quote: it seg faults with 11 Actually, signal 11 means a segmentation fault. |
Don Freeman
Member #5,110
October 2004
|
See that is what I thought might also be the problem (trying to load an image, but fails)...the program looks for the GFX/ folder in the current directory to get it's graphics...I even changed the code so it would just load from the current directory...same thing! Edit: Edit #2: Edit #3: -- |
Frank Drebin
Member #2,987
December 2002
|
#2 #ifndef _WIN32 char path [128]; get_executable_name(path,128); replace_filename(path,path,"",128); chdir(path); #endif
|
CGamesPlay
Member #2,559
July 2002
|
Quote: in linux you have to set the current path by yourself - this is code i'm using: This has nothing to do with Linux versus Windows, and it's wrong The path is the same as the path you were at when you ran the program. If you ran it from the same directory ("./program"), the CWD will be that directory. Don: Use a log file to find out which bitmap fails to load. [append] Put that in main, run the program, and check those files. -- Ryan Patterson - <http://cgamesplay.com/> |
psycho
Member #5,042
September 2004
|
Quote: The path is the same as the path you were at when you ran the program. If you ran it from the same directory ("./program"), the CWD will be that directory.
Quote: in linux you have to set the current path by yourself
Both wrong, in linux the working directory is (AFAIK) the home directory of the current user. |
Evert
Member #794
November 2000
|
Quote: Both wrong, in linux the working directory is (AFAIK) the home directory of the current user.
Wrong again. Quote: The code written by Frank Drebin should work perfectly. Yes. Except that you normally need the exact same code in Windows too. |
Michael Faerber
Member #4,800
July 2004
|
Quote: The adminstrator has to install the program in such a way that it runs with root privileges ("suid root"). Are you serious? -- |
Don Freeman
Member #5,110
October 2004
|
Evert: -- |
Thomas Harte
Member #33
April 2000
|
Hmmm. The Mac version of Allegro sets the cwd to be the resources folder of your application bundle (or an Allegro-specific subdirectory of it if that exists), would it make sense to have the other platforms automatically set the cwd to wherever the executable is so that behaviour is "uniform" across platforms in the sense that it sets the cwd to be where your data files probably are? [My site] [Tetrominoes] |
Evert
Member #794
November 2000
|
Quote: But how would you know at runtime what the CMD would be? Quote: would it make sense to have the other platforms automatically set the cwd to wherever the executable is so that behaviour is "uniform" across platforms in the sense that it sets the cwd to be where your data files probably are?
Probably not. The MacOS X port is special in this, but I think that makes sense, since the concept of application bundles is also MacOS X specific (and something I actually quite like). EDIT Quote: I want to keep this as portable as possible Then you should definately include that code; as I said, it's generally also nescessary in Windows. |
ImLeftFooted
Member #3,935
October 2003
|
Since we're on the subject of application bundles, how come you cant load the special "#" datafile when your executable is in an application bundle? |
Evert
Member #794
November 2000
|
My guess is that it's looking for the game executable in the resource directory of the application bundle and fails to find it (thus failing to load the embedded datafile), but that's just a random guess (yes, I'm saying that's a bug). EDIT: For got to reply to this before Quote: Are you serious? In that the administrator has to install the program to use root privileges rather than the user just telling it to? Of course I am, it wouldn't make sense otherwise. |
ImLeftFooted
Member #3,935
October 2003
|
Quote: why do you need to append the datafile to the executable in the first place? Because you're porting your game over from windows and would prefer to maintain the same build system. That and maybe you want to make your game data just a bit harder for someone to reverse engineer. |
Evert
Member #794
November 2000
|
Quote: Because you're porting your game over from windows and would prefer to maintain the same build system. Can't do that anyway; linking options are already different and Windows doesn't know about application bundles in the first place. |
ImLeftFooted
Member #3,935
October 2003
|
It was easy to add new options to my build system for OSX, but to change the location of the datafile requires me to write new code to handle that and make other weird changes to my build system that don't fit well with the other OS's build system stuff. But I've already done it all anyway. I just think it would be cool if "#" worked. After all, the docs do say it does. |
Evert
Member #794
November 2000
|
Quote: I just think it would be cool if "#" worked. After all, the docs do say it does. As I said, it's a bug. |
|