Mac is not iPhone, also Box2D Bugs

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

  • edited September 2010
    Skrylar wrote:
    I've found two issues while trying to prod at the latest official Orx release:

    b2BoundaryListener doesn't exist in Box2D 1.2.1 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.

    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. :)
    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.

    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)?
  • edited September 2010
    iarwain wrote:
    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.
    Whoops, edited the original post. I did indeed mean 2.1.2 and not 1.2.1; as for an "equivalent system", some searching of the Box2D forums indicates that there is no direct equivalent.

    BorisTheBrave wrote on the Box2D Forums:
    The world has no boundaries any more. Things can never go outside the world.[..]The world just extends indefinitely in every direction.

    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'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).

    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.
  • edited September 2010
    Skrylar wrote:
    Whoops, edited the original post. I did indeed mean 2.1.2 and not 1.2.1; as for an "equivalent system", some searching of the Box2D forums indicates that there is no direct equivalent.

    BorisTheBrave wrote on the Box2D Forums:
    The world has no boundaries any more. Things can never go outside the world.[..]The world just extends indefinitely in every direction.

    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.
    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.

    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 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 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?
    echo | gcc -E -dDM -
    

    It should print out the list of preprocessor defines and if you see TARGET_OS_IPHONE in the list, there's something wrong somewhere! ;)
    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.

    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! :)
  • edited September 2010
    LittleFish:~ skrylar$ which gcc
    /usr/bin/gcc
    LittleFish:~ skrylar$ /usr/bin/gcc -v
    Using built-in specs.
    Target: i686-apple-darwin10
    Configured with: /var/tmp/gcc/gcc-5659~1/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
    Thread model: posix
    gcc version 4.2.1 (Apple Inc. build 5659)
    LittleFish:~ skrylar$ echo | gcc -E -dDM -
    #define __DBL_MIN_EXP__ (-1021)
    #define __FLT_MIN__ 1.17549435e-38F
    #define __DEC64_DEN__ 0.000000000000001E-383DD
    #define __CHAR_BIT__ 8
    #define __WCHAR_MAX__ 2147483647
    #define __DBL_DENORM_MIN__ 4.9406564584124654e-324
    #define __FLT_EVAL_METHOD__ 0
    #define __DBL_MIN_10_EXP__ (-307)
    #define __FINITE_MATH_ONLY__ 0
    #define __DEC64_MAX_EXP__ 384
    #define __SHRT_MAX__ 32767
    #define __LDBL_MAX__ 1.18973149535723176502e+4932L
    #define __APPLE_CC__ 5659
    #define __UINTMAX_TYPE__ long unsigned int
    #define __DEC32_EPSILON__ 1E-6DF
    #define __block __attribute__((__blocks__(byref)))
    #define __SCHAR_MAX__ 127
    #define __USER_LABEL_PREFIX__ _
    #define __STDC_HOSTED__ 1
    #define __DEC64_MIN_EXP__ (-383)
    #define __DBL_DIG__ 15
    #define __FLT_EPSILON__ 1.19209290e-7F
    #define __LDBL_MIN__ 3.36210314311209350626e-4932L
    #define __DEC32_MAX__ 9.999999E96DF
    #define __strong 
    #define __APPLE__ 1
    #define __DECIMAL_DIG__ 21
    #define __LDBL_HAS_QUIET_NAN__ 1
    #define __DYNAMIC__ 1
    #define __GNUC__ 4
    #define __MMX__ 1
    #define __FLT_HAS_DENORM__ 1
    #define __DBL_MAX__ 1.7976931348623157e+308
    #define __DBL_HAS_INFINITY__ 1
    #define __DEC32_MIN_EXP__ (-95)
    #define OBJC_NEW_PROPERTIES 1
    #define __LDBL_HAS_DENORM__ 1
    #define __DEC32_MIN__ 1E-95DF
    #define __weak __attribute__((objc_gc(weak)))
    #define __DBL_MAX_EXP__ 1024
    #define __DEC128_EPSILON__ 1E-33DL
    #define __SSE2_MATH__ 1
    #define __amd64 1
    #define __tune_core2__ 1
    #define __LONG_LONG_MAX__ 9223372036854775807LL
    #define __GXX_ABI_VERSION 1002
    #define __FLT_MIN_EXP__ (-125)
    #define __x86_64 1
    #define __DBL_MIN__ 2.2250738585072014e-308
    #define __LP64__ 1
    #define __DBL_HAS_QUIET_NAN__ 1
    #define __DEC128_MIN__ 1E-6143DL
    #define __REGISTER_PREFIX__ 
    #define __DBL_HAS_DENORM__ 1
    #define __NO_INLINE__ 1
    #define __DEC_EVAL_METHOD__ 2
    #define __DEC128_MAX__ 9.999999999999999999999999999999999E6144DL
    #define __FLT_MANT_DIG__ 24
    #define __VERSION__ "4.2.1 (Apple Inc. build 5659)"
    #define __DEC64_EPSILON__ 1E-15DD
    #define __DEC128_MIN_EXP__ (-6143)
    #define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 1064
    #define __SIZE_TYPE__ long unsigned int
    #define __DEC32_DEN__ 0.000001E-95DF
    #define __FLT_RADIX__ 2
    #define __LDBL_EPSILON__ 1.08420217248550443401e-19L
    #define __SSE_MATH__ 1
    #define __k8 1
    #define __LDBL_DIG__ 18
    #define __x86_64__ 1
    #define __FLT_HAS_QUIET_NAN__ 1
    #define __FLT_MAX_10_EXP__ 38
    #define __LONG_MAX__ 9223372036854775807L
    #define __FLT_HAS_INFINITY__ 1
    #define __DEC64_MAX__ 9.999999999999999E384DD
    #define __DEC64_MANT_DIG__ 16
    #define __DEC32_MAX_EXP__ 96
    #define __DEC128_DEN__ 0.000000000000000000000000000000001E-6143DL
    #define __LITTLE_ENDIAN__ 1
    #define __LDBL_MANT_DIG__ 64
    #define __CONSTANT_CFSTRINGS__ 1
    #define __DEC32_MANT_DIG__ 7
    #define __k8__ 1
    #define __WCHAR_TYPE__ int
    #define __pic__ 2
    #define __FLT_DIG__ 6
    #define __INT_MAX__ 2147483647
    #define __FLT_MAX_EXP__ 128
    #define __BLOCKS__ 1
    #define __DBL_MANT_DIG__ 53
    #define __DEC64_MIN__ 1E-383DD
    #define __WINT_TYPE__ int
    #define __SSE__ 1
    #define __LDBL_MIN_EXP__ (-16381)
    #define __MACH__ 1
    #define __amd64__ 1
    #define __LDBL_MAX_EXP__ 16384
    #define __SSP__ 1
    #define __LDBL_MAX_10_EXP__ 4932
    #define __DBL_EPSILON__ 2.2204460492503131e-16
    #define _LP64 1
    #define __GNUC_PATCHLEVEL__ 1
    #define __LDBL_HAS_INFINITY__ 1
    #define __INTMAX_MAX__ 9223372036854775807L
    #define __FLT_DENORM_MIN__ 1.40129846e-45F
    #define __PIC__ 2
    #define __FLT_MAX__ 3.40282347e+38F
    #define __SSE2__ 1
    #define __FLT_MIN_10_EXP__ (-37)
    #define __INTMAX_TYPE__ long int
    #define __DEC128_MAX_EXP__ 6144
    #define __GNUC_MINOR__ 2
    #define __DBL_MAX_10_EXP__ 308
    #define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L
    #define __STDC__ 1
    #define __PTRDIFF_TYPE__ long int
    #define __DEC128_MANT_DIG__ 34
    #define __LDBL_MIN_10_EXP__ (-4931)
    #define __GNUC_GNU_INLINE__ 1
    #define __SSE3__ 1
    

    iarwain wrote:
    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).

    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.
  • edited September 2010
    Mmh, looks OK to me. I'm afraid I don't have any other ideas than just trying on my side.

    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.
Sign In or Register to comment.