Short version: Loading a config file
not named after my executable by calling orxConfig_Load() doesn't work, whereas the normal automatic loading of <exe>.ini does.
Long version:
I'm compiling and running Tutorial
#10 (standalone), by pasting the code into a file called 'main.cpp'.
The first/only change I made was to StandAlone::Init(), partially seen below. All I added was a call to orxConfig_Load(), which succeeds.
If I don't have any .ini file, the code segfaults (as it should, since it doesn't check things). If I have an .ini file named 'main.ini' (my executable name is 'main'), then it runs normally.
If I rename 'main.ini' to 'mango.ini' (which is explicitly loaded in the code below), I get a maximized window that is empty. If I have both 'main.ini', and 'mango.ini', then the code works as expected.
In every case, the .ini file is an unaltered copy of the init file for Tutorial
#10.
orxSTATUS StandAlone::Init()
{
orxSTATUS eResult;
orxINPUT_TYPE eType;
orxENUM eID;
const orxSTRING zInputQuit;
const orxSTRING zInputCycle;
eResult = orxConfig_Load("mango.ini");
switch (eResult)
{
case orxSTATUS_SUCCESS:
orxLOG("Config load: Success");
break;
default:
orxLOG("Config load: not a success %d", eResult);
}
...
Comments
I'm using it everyday in my test bed (the Bounce plugin that comes with orx's source: http://code.orx-project.org/orx/src/334ea6e5fd8cc0d57c6913db5241c3654398d866/code/plugins/Demo/orxBounce.c?at=default, line 495) and another example can be seen in Mushroom Stew: https://bitbucket.org/iarwain/mushroomstew/src/7c85c920acf575f4996bdb75049697b851699cf3/src/MushroomStew.cpp?at=default, line 459.
That segfault shouldn't happen either. If a config file doesn't exist, the load should gracefully fail and you should get a debug error message if you're running a debug build.
Are you using a version of orx you compile yourself from the Mercurial repository or another one?
Remember, this is the StandAlone demo ... doesn't that mean many things don't happen automagically?
The segfault is in the tutorial code itself, not the libs. It doesn't check the return pointer (which is NULL) when creating an object from a config that doesn't exist. 1.3rc0, as mentioned above.
I recommend (and will write a sticky post about it later) to directly use the source from the repository instead.
The Mercurial repository is available at http://code.orx-project.org/orx and Grey wrote a quick 'how to build orx from source' tutorial here.
Orx builds out-of-the-box on most, if not all, platforms.
All the external dependencies are stored in the repository as well, in binary form, except for un-modified OS-available libraries (OpenAL on linux/os x, OpenGL on all platforms, libsndfile on linux, etc...).
CodeLite is the IDE used for compiling the linux version.
Make sure you're building the Dynamic Embedded Debug/Profile/Release versions.
Not really, no. Only a few keybindings are made for you by the launcher (quitting, toggling VSync, capturing a screenshot, reloading config) and the use of the [Main] config section to define which plugin to load, as stated at the beginning of this wiki article: http://orx-project.org/wiki/en/orx/tutorials/standalone
After fiddling with it a bit more (getting the graphic to work, etc), it turns out that it is reading the config file correctly.
Symptoms:
Unfortunately, the graphics in the window are not captured in the operating system screenshot. I did add F12 to capture screenshot, but since keybindings are borked, that didn't work.
It's going to be extremely hard, if not impossible, to give you any helpful advice.
Please try to use the current repository version (you'll have to update the linux binaries of the tutorial yourself as they haven't been updated for a while, usually it's done in sync with binary releases).
The issue is that releases are entirely done by hand and the last one took me over 6 hours of work. So it's unlikely to happen again this way.
I'd like to setup a buildbot infrastructure to automatize smoke tests and builds, but I'm progressing very slowly and asked for help here, without any success so far.
none- Pommelo/orx is a symlink to Pommelo/orx-srcnone
- I removed the orxConfig_Load(), and orx is auto-loading main.ininone
Debug version output:Release version output:
Now the behavior is identical to my original post, except:
1) Animation is much more flickery.
2) The "release" build only: Animation of the logo ends after about 1 second. The color cycling of the legend continues.
P.S. I should note that all of this on 64-bit Ubuntu on an iMac. I'll try it at home with my 32-bit Ubuntu on a Dell.
As for 2), that sounds a lot like a GCC bug we've encountered in the past with regards to optimization. Which version of GCC did you use?
If I remember correctly it got introduced with a gcc 4.4.x and carried over to gcc 4.5.x. I'm not sure if it disappeared since.
I believe Graag encountered a similar issue here.
Note: With a late gcc 4.3.x, the compiler was even crashing when compiling with optimizations O2/O3. I tracked the specific flag combination but have since lost it.
I haven't tried on linux for quite some time, but on windows with mingw gcc 4.6.x everything works fine.
I wonder if other linux users have the same issue as you. I'll poke Graag and Lydesik. I only have access to a linux64 box.
What about your first point, how would you define "flickery" for an animation?
No difference when compiling on i386
The other options seemed to have no effect, only the optimization level.
Assuming you are still testing on a 64b machine, does this only happen when you run a 32b optimized version on it or does it also happen with 64b binaries?
none- Compiling from Mercurial repositorynone
- Compiling on 64 and 32 bit Ubuntu 12.04 machinesnone
- Identical Codelite workspaces (synced via Dropbox)none
- All builds are forced to 32 bit via -m32 GCC switch.none
All Builds:Loading a config file via orxConfig_Load() causes the main window to fullscreen itself. If <exec>.ini exists, it works fine, whether or not the explicit load occurs. This is the initial problem I encountered
32-bit Release builds:
When using -O2 or -O3, the "disappearing animation" bug pops up. Does not occur with -O1 or -O0. Updated: This does not occur on 64-bit builds.
On the iMac (Ubuntu 12.04 x64):
Animations are "flickery"
The main window covering the whole fullscreen in this case is normal: when the display plugin initializes, there's no config data available for it so it uses the desktop resolution by default.
If you load a config file with display info subsequently, it's already too late. You'll then have to resize your display manually by calling orxDisplay_SetVideoMode().
Last night I tried a 64b built on my 64b linux box (mint 13, gcc 4.5.3) and it worked fine as it did for you.
So something's wrong with 32b optimized binaries. I'll check it tonight.
Is that with both 32b and 64b binaries? Are your OpenGL drivers up-to-date on your iMac?
I also tried OS X binaries, just in case. 32b and 64b binaries worked fine for me on OS X 10.6 64b.
Yes; I thought this because keybindings were also not working. Fixed by calling orxInput_Load().
Yes, this worked.
They are whatever Ubuntu provides for ATI Radeon M 6900M; a quick Google shows that flickering might be a sometimes problem with Ubuntu + ATI. There's no flicker if I go fullscreen, but doing so also crashes Unity/compiz when exiting. I suspect this is an artifact of my dual monitor setup.
compiled orx in 32bits with gcc 4.7.2
10_Standalone works fine here.
I've updated the linux (32b) binaries for the tutorials on the hg repo if you want to sync it and try them directly on your machine.