linux tutorial segmentation fault

edited October 2014 in Help request
I downloaded orx and the tutorials. I created a code::blocks project for the 08_physics tutorial program (unmodified). I compiled and linked successfully. But, when I run it I get a segfault in some unknown place. It's outside of this source module.

- '' & '' will rotate the camera
* Gravity will follow the camera
* a bump visual FX is played on objects that collide
Segmentation fault

Has anyone a clue why? Am I going to have to build orx with debugging on? Or should I just give up and move on the the next engine??


  • edited October 2014
    Strange, I have developed a full game using nearly all features (but shaders) on linux and didn't run into any issues.

    Have you tried lauching the game with F8 (debug mode)?

    Edit: BTW, what distro are you using?
  • edited October 2014
    Hi coosadog and welcome here!

    coosadog wrote:
    I downloaded orx and the tutorials.

    Which version did you download? 1.5? 1.6rc0? nightly? 32bit or 64bit?
    Has anyone a clue why? Am I going to have to build orx with debugging on? Or should I just give up and move on the the next engine??

    I'm afraid we're lacking a bit of details for now to be very helpful.
    Did you try to launch the pre-compiled binary for tutorial #8? Did it crash as well?

    Instead of linking with the release version, you could compile/link with the debug version of orx, you should at least get a callstack/trace when it segfaults that could help us diagnose the issue. Keep in mind to define __orxDEBUG__ when using the debug version of orx (and only with the debug version, that could even be your issue in the first place?)

    I've just tried the pre-compiled tutorials from the 1.6rc0 version on two different linux machines (32bit and 64bit) and both ran fine without crashing.

    As a side note, I'd recommend using the source distribution (syncing the hg repository at is usually what most users do) and orx builds out-of-the-box for most platforms, with the slight exception of... linux. ;)

    But it's really not bad: on linux, you need to "apt-get install" 4 dev libraries if they're not already on your system (most ubuntu-based distributions do not install them by default):
    - freeglut3-dev
    - libsndfile1-dev
    - libopenal-dev
    - libxrandr-dev

    That's about it. After that the project files can be generated using the premake version that ships with orx (it's not a vanilla one, you need to use this one). It's located in orx/extern/premake. So assuming you start in orx's root folder (replace 64 with 32 if you're using a 32bit linux):
    cd code/build
    ../../extern/premake/bin/linux64/premake4 gmake
    cd linux/gmake
    make config=embedded_dynamic_debug64
    make config=embedded_dynamic_release64

    Everything should compile without any warning/error within 15-30 secs for each version, depending on your machine.

    Alternatively you can use "codeblocks" instead of "gmake" to generate the project file for that IDE, they should work just as well (though I haven't tested them, I don't use code::blocks).

    Same thing for the tutorials:
    cd tutorial/build
    ../../extern/premake/bin/linux64/premake4 gmake
    cd linux/gmake
    make config=debug64

    All the tutorials should be compiled and ready to run in tutorial/bin. You can also compile the release version (config=release64) but only one version of the tutorials can exist at a given time.

    Let us know how it went. :)
  • edited October 2014
    Wow, guys!! I never get this sort of response from developer forums. I'm impressed! Yes, the prebuilt tutorials run just fine here. I'm running version 1.6rc0 for development. I didn't see a debug version of orx when I downloaded so I guess I had better look again. I can build from source too, but didn't want to have to... This is a development machine and has everything needed to build just about anything already installed. I've built many 3d apps. I have my own 3d game engine on it too so I should be good I'd think if that's what I need to do. Let me make some time today and see what I can discover based on the responses and I'll let you know how it goes. Thanks!!!!
  • edited October 2014
    As you might have probably noticed by now, the community is rather small but there's always someone around to help and answer questions. :)

    The advantages of the source distribution is that you get the latest features and fixes much faster. We try to keep it as stable as possible and it's rarely broken for much longer than a day whenever it happens (which is also rare).

    Releases are done only once or twice a year. I should probably increase the frequency now that we have continuous integration, no more 6 hours of manual work to make the packages. ;)

    As for the dev package, you should have the 3 versions of the library binaries in it: debug, profile and release.

    For the debug one, you need to define __orxDEBUG__, whereas there are no needed define for profile/release. Those precompiled binaries are dynamic, however if you'd rather compile orx as a static library, you'd then need to define __orxSTATIC__ when using them. There should be a summary of all the flags at the end of the README file. :)

    Let us know how it goes!
  • edited October 2014
    Amazing! Finally got around to doing it. I used codeblocks. premake built 3 projects: orxLIB.cbp, orx.cbp and Bounce.cbp. I built all 3 of them using 'Static Debug|x32' which already had the necessary flags set. That was pretty impressive. But, after going through the steps I discovered the 08-Physics.cbp file and brought it up for a view. I don't have enough flags, etc set up in my build, is my problem. I'm really bad about 'speed reading' instructions... Now it looks like it can't find a config file. I'll let you know when I've worked through this. I'll get working eventually. Thanks for the wonderful help!
  • edited October 2014
    OK, all done. Everything is working just fine. Had to get the associated .ini file. I'll move on now and create my first project, so I may have questions as I move forward. I had some other engines I was going to try but I think I'll stay put here and see how it goes. So far I'm impressed. How do I close this thread, or do I?
  • edited October 2014
    You don't really need to close the thread, at some point people were changing the topic to add a [resolved] tag, but that practice didn't last long. ;)

    Glad you like it so far and that you got it running. Don't hesitate if you have any questions as there are quite a few things that are a bit unusual compared to other 2D game engines (and that I believe gives us often an edge over them), starting with the clock, config, resource and input systems.

    There's no obligation, of course, but, in case you choose another 2D game engine/library, we'd love to hear why as it's always good to get ideas on how to improve the engine. :)

    Lastly, in addition to the forum, there's also the google dev group that might be of some interest as it's where new features and proposals are discussed.
  • edited October 2014
    Ok, thanks. I'll keep you posted. All the doc I found was doxygen stuff. I suppose that the best way to figure it out is to study the demos and forums?
  • edited October 2014
    Never mind, I found the online reference and tut's.
  • edited October 2014
    Hi coosadog, yep the tutorials are a good source of info as is the reference section.

    There is a collection on code snippits in the wiki as well which we try to add to fairly often. The API is pretty good but sometimes you just need to see it used in a code example.

    And the forum posts have a lot of information.

    Always feel free to holler out, or PM. Someone will try to help.

    Orx is a fantastic engine. Some of us are very dedicated to it, just because of the way it works so naturally, and the people who use it.
Sign In or Register to comment.