This is a weird problem. Orx refuses to run the game in release mode. It runs in profiling and debug mode, but it bombs out without error in release mode. Anyone have any idea?
Beside the usual mismatch between the compiler flags (no __orxDEBUG__ nor __orxPROFILE__) and the library used for linking/running (orx.lib/orx.dll), nope, don't have much ideas.
Have you a config file with a name that matches your release exe?
First I'm going to try compiling my own version of orx with the svn code. [strike]I'm having a little trouble though, codelite is terrible software to work with (for me, at least). I'm converting the projects to eclipse projects as we speak, so that everything can be in the same IDE (I'm using eclipse for my project). When I'm finished, by the way, do you want the eclipse workspace files so that others can use them? I'm sure there are others who don't want to use either codelite or msvc.[/strike]
EDIT: Never mind. I ran into some roadblocks with importing the code into eclipse, so I stuck with getting codelite to work... It worked perfectly in Linux but took more tweaking than I cared for in Windows. Either way, I have my libraries compiled now. I'm going to try using these libraries with my project and get back to you.
Before going for Code::Blocks and then CodeLite I was using Eclipse + CDT (between 2001 - 2005).
But back then CDT wasn't very good and the rate at which it was updated was sluggish at best.
Their code highlight looked like coming from the 80s and their code completion was non existent.
I'm sure they've much improved since then, so I should maybe give it another try.
That being said, if you want to maintain makefiles + eclipse project files for orx, I'd be happy to add them to the repo and give you write access.
For now I'm thinking of using something like premake to generate all the projects file for all the different IDEs and personally only use Sublime Text across all different OSes.
Let me know if you got the release version running.
Well, I noticed that I forgot to strip debug symbols from the binaries. I haven't tried running the program yet, though, because I've been too busy trying to convert my project from a dynamic binary to a static one.
Too bad I failed miserably. After hours of toiling, it turns out that Box2D had some C++ junk in it, and my project is C-only. The linker then decided that it no longer liked me and died as soon as it hit an operator keyword. I wasn't thinking about that... oh well, there goes a couple of perfectly good hours.
I'll have to scrounge up all of the DLLs my game needs to run and stick them in the same folder as the executable, then. Not that that's terrible, but it puts a hamper on getting the Linux version going... I'll be working in a computer lab, and I don't have access to 99% of the system. Unless I can modify my environment temporarily, I won't be able to run the game there...
I failed to create orx projects in Eclipse. I have no clue how the codelite ones work, so I failed to duplicate them. Maybe another time?
Oh, and on the issue of CDT: I don't know if they have code completion, its a function I don't use. The syntax highlighting is fine now, as far as I can tell. It's cross-platform and pretty stable.
I'll have to scrounge up all of the DLLs my game needs to run and stick them in the same folder as the executable, then. Not that that's terrible, but it puts a hamper on getting the Linux version going... I'll be working in a computer lab, and I don't have access to 99% of the system. Unless I can modify my environment temporarily, I won't be able to run the game there...
You can have the binary look for runtime libraries in its own folder without having to temper with environment variables.
It's done by adding this to your link command line:
-Wl,-rpath ./
Oh, and on the issue of CDT: I don't know if they have code completion, its a function I don't use.
You don't use code completion? O_o
I can't even imagine writing all by hand and remembering the names of all the functions/methods/variables/constant by heart nor having to go look them up every time.
I'll try the rpath thing, but I can't compile my program right now, unless I want some awesome crashes.
I've coded with code completion, and without; it seems that I end up instinctively typing what I need half of the time, a fourth of the time I can look at previous code and copy-pasta, and the other fourth of the time is a quick look at the documentation, which is a bookmark on my browser's bar. Not a problem.
I'll check if there is a code completion function for you, though. It wouldn't be bad to have, but I notice that it sometimes hinders me as much as it helps.
Oh they have code completion, it just that CDT found only half of the symbols at best back then.
Eclipse for writing Java was great but CDT was really sub-par. But again, I haven't used it for many years so I'm sure they've improved it since.
But instead of typing orxConfig_PushSection, I'd rather type confpusec + tab (which will, in turn after the completion, show me the list of expected parameters). I'm just lazy that way.
I understand, we all have our preferences. Its just that for a long time I practically programmed with notepad on a good day and on the command line on a bad day, so I got used to it.
Perhaps we should move this to the bugs section.
For some reason, if I use an optimization flag aside from -O0, -O1 to -O3 or even -Os cause the program to bomb immediately after graphics are supposed to be displayed. (My log shows FX being assigned and being started before the program closes). And its not crashing either. It seems to be like when I tried updating orx to the svn release.
Oh well, at least it works now. And profiling mode rocks my socks.
Mmh, this is slightly different from what you told me in PM.
Do you mean that if you optimize your game by using some optimization flag it won't work, even when using the debug build?
Or is it not working when you link against the release build (and working with debug/profile ones)?
In both cases however, my suspicion is that something might be wrong on your side as I've been running the latest SVN on 2 different linux boxes without any issue, no matter the build options used.
If it's not crashing you should be able to trace the execution and see what's happening and why your game is quitting prematurely.
If you still have issues, if you provide me with your project I could also have a look.
Well, that's the problem right there, I cannot fix what I cannot reproduce.
As far as I'm concerned, today's SVN version is much more stable than 1.3rc0 (which isn't a stable version by all means, it's a release candidate 0): a lot of bugs have been fixed since that release.
Out of curiosity, what compiler/version are you using?
I remember a late gcc 3.x that was even crashing when compiling orx with 2 specific optimization flags part of -O2/-O3, so a compiler bug isn't to exclude.
Right now, I'm using GCC MinGW32 4.6.2 in Windows. I haven't compiled in Linux for a while, so I forgot what version it is in there. I'm pretty sure it's a 4.6 in Linux though.
When I have more free time, I'll try doing another subversion build. But the rest of the team has to agree on it first, and I'm sure they would rather wait for 1.3 stable to come out before trying to upgrade again.
EDIT: I'm the biggest moron ever. I got it to run in release mode. You know what I didn't do?
orxSTATUS orxFASTCALL Run()
{
orxSTATUS result;
/* Should quit? */
if (orxInput_IsActive("Quit"))
/* Updates result */
result = orxSTATUS_FAILURE;
/* Done! */
return result;
}
This is the original code. What's wrong here? Without optimization, result does not equal orxSTATUS_FAILURE. But for some reason, with optimization on, it does. Why? Because I forgot one very crucial thing. I changed the code to this:
orxSTATUS result = orxSTATUS_SUCCESS;
and everything works perfectly. How did I miss that? I'm glad I ran GDB on that. I feel like a fool for missing that, but at least its fixed now! Maybe that's why the new version was quitting itself as well? I can't wait to let everyone know!
You might want to turn on the gcc compile warning about those.
Also using a static code analyzer, such as CppCheck which is already integrated to CodeLite, will catch all those problems and much more!
I have the -Wall flag set... it should've warned me. Oh well, problem's solved now. once orx 1.3 is released my team will talk about switching versions. I hope it's out before march 9th, because we probably won't want to do too much more to this thing.
-Wall doesn't actually turn on all warning flags. -Wextra adds some more and there are still warnings not enabled by the combination of both. That being said, I think -Wuninitialized is part of -Wall, so it should have been triggered. Ah, well.
As for 1.3, it won't get released at all. Current svn is considered as 1.4pre and I'm pretty sure 1.4rc0 won't be ready before march 9th.
You can check the SVN log (or the CHANGELOG file) to see if there are things you need on the SVN version that are not part of 1.3rc0.
As far as I'm concerned 1.3rc0 is on the verge of getting deprecated and I'm not sure if I'll be making any binary release at all in the future. I'll probably only tag versions on the SVN or make source only packages.
Because it takes me 6-8 hours for making all the packages for a release and I don't think I'll be willing to do that again any time soon since my spare time has been drastically reduced with the second baby.
Comments
Have you a config file with a name that matches your release exe?
I can check your project if you want to send it to me. I keep everything private, of course.
EDIT: Never mind. I ran into some roadblocks with importing the code into eclipse, so I stuck with getting codelite to work... It worked perfectly in Linux but took more tweaking than I cared for in Windows. Either way, I have my libraries compiled now. I'm going to try using these libraries with my project and get back to you.
But back then CDT wasn't very good and the rate at which it was updated was sluggish at best.
Their code highlight looked like coming from the 80s and their code completion was non existent.
I'm sure they've much improved since then, so I should maybe give it another try.
That being said, if you want to maintain makefiles + eclipse project files for orx, I'd be happy to add them to the repo and give you write access.
For now I'm thinking of using something like premake to generate all the projects file for all the different IDEs and personally only use Sublime Text across all different OSes.
Let me know if you got the release version running.
Too bad I failed miserably. After hours of toiling, it turns out that Box2D had some C++ junk in it, and my project is C-only. The linker then decided that it no longer liked me and died as soon as it hit an operator keyword. I wasn't thinking about that... oh well, there goes a couple of perfectly good hours.
I'll have to scrounge up all of the DLLs my game needs to run and stick them in the same folder as the executable, then. Not that that's terrible, but it puts a hamper on getting the Linux version going... I'll be working in a computer lab, and I don't have access to 99% of the system. Unless I can modify my environment temporarily, I won't be able to run the game there...
I failed to create orx projects in Eclipse. I have no clue how the codelite ones work, so I failed to duplicate them. Maybe another time?
Oh, and on the issue of CDT: I don't know if they have code completion, its a function I don't use. The syntax highlighting is fine now, as far as I can tell. It's cross-platform and pretty stable.
You can have the binary look for runtime libraries in its own folder without having to temper with environment variables.
It's done by adding this to your link command line:
You don't use code completion? O_o
I can't even imagine writing all by hand and remembering the names of all the functions/methods/variables/constant by heart nor having to go look them up every time.
I've coded with code completion, and without; it seems that I end up instinctively typing what I need half of the time, a fourth of the time I can look at previous code and copy-pasta, and the other fourth of the time is a quick look at the documentation, which is a bookmark on my browser's bar. Not a problem.
I'll check if there is a code completion function for you, though. It wouldn't be bad to have, but I notice that it sometimes hinders me as much as it helps.
Eclipse for writing Java was great but CDT was really sub-par. But again, I haven't used it for many years so I'm sure they've improved it since.
But instead of typing orxConfig_PushSection, I'd rather type confpusec + tab (which will, in turn after the completion, show me the list of expected parameters). I'm just lazy that way.
For some reason, if I use an optimization flag aside from -O0, -O1 to -O3 or even -Os cause the program to bomb immediately after graphics are supposed to be displayed. (My log shows FX being assigned and being started before the program closes). And its not crashing either. It seems to be like when I tried updating orx to the svn release.
Oh well, at least it works now. And profiling mode rocks my socks.
Do you mean that if you optimize your game by using some optimization flag it won't work, even when using the debug build?
Or is it not working when you link against the release build (and working with debug/profile ones)?
In both cases however, my suspicion is that something might be wrong on your side as I've been running the latest SVN on 2 different linux boxes without any issue, no matter the build options used.
If it's not crashing you should be able to trace the execution and see what's happening and why your game is quitting prematurely.
If you still have issues, if you provide me with your project I could also have a look.
I'm glad you like the profiling mode.
Neither debug nor release run with an optimization flag set.
I don't have time right now to do a trace, but I might try to do some later.
The team leader doesn't want to think about upgrading orx again until the next stable release.
As far as I'm concerned, today's SVN version is much more stable than 1.3rc0 (which isn't a stable version by all means, it's a release candidate 0): a lot of bugs have been fixed since that release.
Out of curiosity, what compiler/version are you using?
I remember a late gcc 3.x that was even crashing when compiling orx with 2 specific optimization flags part of -O2/-O3, so a compiler bug isn't to exclude.
When I have more free time, I'll try doing another subversion build. But the rest of the team has to agree on it first, and I'm sure they would rather wait for 1.3 stable to come out before trying to upgrade again.
EDIT: I'm the biggest moron ever. I got it to run in release mode. You know what I didn't do?
This is the original code. What's wrong here? Without optimization, result does not equal orxSTATUS_FAILURE. But for some reason, with optimization on, it does. Why? Because I forgot one very crucial thing. I changed the code to this:
and everything works perfectly. How did I miss that? I'm glad I ran GDB on that. I feel like a fool for missing that, but at least its fixed now! Maybe that's why the new version was quitting itself as well? I can't wait to let everyone know!
You might want to turn on the gcc compile warning about those.
Also using a static code analyzer, such as CppCheck which is already integrated to CodeLite, will catch all those problems and much more!
As for 1.3, it won't get released at all. Current svn is considered as 1.4pre and I'm pretty sure 1.4rc0 won't be ready before march 9th.
You can check the SVN log (or the CHANGELOG file) to see if there are things you need on the SVN version that are not part of 1.3rc0.
As far as I'm concerned 1.3rc0 is on the verge of getting deprecated and I'm not sure if I'll be making any binary release at all in the future. I'll probably only tag versions on the SVN or make source only packages.