I've found two issues while trying to prod at the latest official Orx release:
b2BoundaryListener doesn't exist in Box2D 2.1.2 which is the latest; I tried compiling my own embedded version of Orx and this comes up as a problem… I don't understand Orx's source code enough yet to try and fix this myself so I'll see if I can drum up an older version of Box2D for now.
Second problem, I've noticed that Orx seems to think anything Apple is an iPhone unless you explicitly define __orxMAC__ on the compiler line. I'm not fully sure why, but I ran in to this as adding __orxEMBEDDED__ causes a stream of redefinition errors that I tracked back to a lack of an OS setting makes it search for the OS, which it thinks is an iPhone, which means Embedded, which collides with my already explaining its embedded, etc.
Edit: Accidentally typed the wrong version number in.
Comments
I presume you meant Box2D 2.1.2 and not 1.2.1. I didn't know about the disparition of b2BoundaryListener, but I'm sure there's an equivalent system to get notified of bodies going out of world's boundaries.
However, you can't use a vanilla version of Box2D with orx as I made at least 2 changes in it for orx, the biggest being the support of custom gravities on a per object basis.
That's why I haven't included the latest version of Box2D yet as I lacked the time to reintegrate my local changes. I'll do it for 1.3 which is ready, only waiting for me to find a new place to live and the time to do the release.
I'm intrigued about this one, it's the first time someone reports it. __orxIPHONE__ gets defined in orxDecl.h if, and only if, TARGET_OS_IPHONE is defined. Which should clearly indicate that the target is an iPhone/iPod/iPad and not a Mac (either simulator or device).
(More info here.)
On the other hand, __orxMAC__ gets defined for all other __APPLE__ platforms (ie. when TARGET_OS_IPHONE isn't defined).
If you can't figure out where the issue lies, could you create an archive with all the source/project files for me to try on my end? I currently only have access to a macbook, but as your issue is mac/iPhone related, I guess it's ok.
Also, do you have the same issue when using the SVN version of orx (which will be the future 1.3)?
BorisTheBrave wrote on the Box2D Forums:
As I'm understanding it to replicate the same "out of world" notification means doing some kind of bounds collision check on objects to see if they left what Orx thinks the size of the world is.
iarwain wrote:
I can package it up and send to you, but all I've done so far is copy and paste orx's source code in to a project directory and set up a CMakeLists.txt file that compiles every source file it finds as well as positioning the plugins I needed to satisfy link errors in as well. I suspect the link errors may have been caused by Orx for some reason thinking I was building for the iPhone and thus building Embedded and then breaking because no plugins were embedded however. I'll have to try building it again non-embedded now that __orxMAC__ seems to set it straight and see if dynamic plugins work properly now.
I've no idea why it is trying to resolve to an iPhone target considering I have given no such settings to it, other than running the default 64-bit GCC from Snow Leopard on it. This made a strange artifact though in that everything would build successfully but linking would fail with a list of errors indicating the plugin init functions were missing as called by functions such as _registerFunction_MUSIC_Init; which I suspect was caused by it thinking it was being built in an embedded fashion when it wasn't.
---
Hmm, looks like that was exactly why it was giving weird link errors.
What a weird design decision. Especially with a world using floating point arithmetics for coordinates, unless they now went for fixed point or double precision.
In both those cases it'd have major performance drawbacks, so it's a bit unlikely.
This sounds good to me, or I can just drop together the support of world boundaries and people relying on it will have to manually do this detection. I know that the concept of world boundaries was disturbing some users anyway and Box2D's behavior when creating new bodies/fixtures outside the world was a bit inconsistent.
I still have no idea why it does this. Can you try to manually invoke the compiler (the one you use when compiling orx, which might not be the one from the binary path) with this command line?
It should print out the list of preprocessor defines and if you see TARGET_OS_IPHONE in the list, there's something wrong somewhere!
Mmh, if this happens it's usually that all the objects were not compiled with the exact same settings. Or that it wasn't linking against the correct plugins (in non embedded mode for mac, only the SFML plugins are available currently, due to some design choices in GLFW that might be changed in the future, from what Camilla told me).
Again, hard to tell for sure without more details such as a verbose output log. Hope you'll find the issue pretty soon, otherwise don't hesitate to drop me the archive, I'll spend some time on my side and I might get more lucky, who knows!
iarwain wrote:
I've been using the GLFW plugin more or less okay for the moment, might look at the SFML plugin in a bit. CPU usage spikes when the GLFW window loses focus and normalizes back when it regains it so I'll have to see if that's just a plugin glitch.
I've never noticed the CPU spike when losing focus, but I haven't especially looked for it either. I'll try to monitor that on my side when I get my computer back in a couple of weeks.
So right now you're using GLFW plugin in non-embedded mode? I'm surprised you can get the mouse and joystick to work with this configuration as GLFW doesn't support code spread in many shared libraries.