compiling from source - linux 64bit

edited June 2011 in Help request
Hi there!

I recently stumbled over the orx project and I think this is the right game enigne for my little game project on the wetab (what is the wetab?).

My Problem is now:
Everything compiles out-of-the-box for the hardware platforms cited above.

cause my dev platform is a 64 bit linux system running ubuntu I'm having some issues.

What I did with revision 2588 from the svn:

Installed all dependencies listed in the projects:
sndfile;openal;dl;m;glfw;SOIL;box2d;GL;X11;Xrandr;sfml-system

Because the libs in extern would not work for me!

All projects (linux dynamic debug) in the codelite workspace compile (only Bounce and Scroll claim to need some missing projects orxFileSystem_LibC but the also generate their dynamic libs without problems)
when I run orxd:
[2011-06-28 14:12:44] <SYSTEM> (orxConfig_Load() - home/rich/Projekte/test/orx/code/src/core/orxConfig.c:2656) [orxd.ini]: Begins the processing of included file @orx.ini@.
[2011-06-28 14:12:44] <SYSTEM> (orxConfig_Load() - home/rich/Projekte/test/orx/code/src/core/orxConfig.c:2662) [orxd.ini]: Ends the processing of included file @orx.ini@.
[2011-06-28 14:12:44] <SYSTEM> (orxConfig_Load() - home/rich/Projekte/test/orx/code/src/core/orxConfig.c:2570) Config entry [Display::Title]: Replacing value "OrxDemo (Release)" with new value "OrxDemo (Debug)" from <orxd.ini>.
[2011-06-28 14:12:44] <SYSTEM> (orxConfig_Load() - home/rich/Projekte/test/orx/code/src/core/orxConfig.c:2656) [orxd.ini]: Begins the processing of included file @orx.ini@.
[2011-06-28 14:12:44] <SYSTEM> (orxConfig_Load() - home/rich/Projekte/test/orx/code/src/core/orxConfig.c:2662) [orxd.ini]: Ends the processing of included file @orx.ini@.
[2011-06-28 14:12:44] <SYSTEM> (orxConfig_Load() - home/rich/Projekte/test/orx/code/src/core/orxConfig.c:2570) Config entry [Display::Title]: Replacing value "OrxDemo (Release)" with new value "OrxDemo (Debug)" from <orxd.ini>.
Speicherzugriffsfehler

'Speicherzugriffsfehler' is a memory access error!

any help appreciated

Comments

  • edited June 2011
    plan_rich wrote:
    Hi there!

    Hi and welcome!
    I recently stumbled over the orx project and I think this is the right game enigne for my little game project on the wetab (what is the wetab?).

    I had a quick glance at the site and it looks really interesting. I'll look more into it later.
    My Problem is now:
    Everything compiles out-of-the-box for the hardware platforms cited above.
    

    cause my dev platform is a 64 bit linux system running ubuntu I'm having some issues.

    What I did with revision 2588 from the svn:

    Installed all dependencies listed in the projects:
    sndfile;openal;dl;m;glfw;SOIL;box2d;GL;X11;Xrandr;sfml-system
    

    Because the libs in extern would not work for me!

    Yep, the projects were made for 32bits but don't have the explicit /m32 when being compiled. I need to install a 64b linux to try to update the project files myself or ask for someone to do it for me (Eyecreate or Grey maybe? :)).
    All projects (linux dynamic debug) in the codelite workspace compile (only Bounce and Scroll claim to need some missing projects orxFileSystem_LibC but the also generate their dynamic libs without problems)
    when I run orxd:
    [2011-06-28 14:12:44] <SYSTEM> (orxConfig_Load() - home/rich/Projekte/test/orx/code/src/core/orxConfig.c:2656) [orxd.ini]: Begins the processing of included file @orx.ini@.
    [2011-06-28 14:12:44] <SYSTEM> (orxConfig_Load() - home/rich/Projekte/test/orx/code/src/core/orxConfig.c:2662) [orxd.ini]: Ends the processing of included file @orx.ini@.
    [2011-06-28 14:12:44] <SYSTEM> (orxConfig_Load() - home/rich/Projekte/test/orx/code/src/core/orxConfig.c:2570) Config entry [Display::Title]: Replacing value "OrxDemo (Release)" with new value "OrxDemo (Debug)" from <orxd.ini>.
    [2011-06-28 14:12:44] <SYSTEM> (orxConfig_Load() - home/rich/Projekte/test/orx/code/src/core/orxConfig.c:2656) [orxd.ini]: Begins the processing of included file @orx.ini@.
    [2011-06-28 14:12:44] <SYSTEM> (orxConfig_Load() - home/rich/Projekte/test/orx/code/src/core/orxConfig.c:2662) [orxd.ini]: Ends the processing of included file @orx.ini@.
    [2011-06-28 14:12:44] <SYSTEM> (orxConfig_Load() - home/rich/Projekte/test/orx/code/src/core/orxConfig.c:2570) Config entry [Display::Title]: Replacing value "OrxDemo (Release)" with new value "OrxDemo (Debug)" from <orxd.ini>.
    Speicherzugriffsfehler
    

    'Speicherzugriffsfehler' is a memory access error!

    any help appreciated

    Do you have any callstack when crashing?

    My guess is that you compiled the non-embedded version of orx, using the dynamic SFML-based plugins which, in addition to being obsolete, haven't been tested for ages. If I were you I'd try to compile the embedded dynamic versions instead, which should only produce a single .so and resolve all the plugin dependencies at compile time (making the execution much more efficient and being the de facto version for platforms that don't support dynamic library loading, such as iOS).

    Also, I believe Eyecreate maintains packages for orx 64b for the most common linux distributions. You can PM him about that or ask in the corresponding thread on this forum.

    Let me know if you still have issues and I'll try to look into it more thoroughly. :)
  • edited June 2011
    No there is no callstack trace... :(

    I tried now to compile the linux embedded dynamic debug and I ran into following compile error:

    Problem is the #include <Box2D/Box2D.h> cause on my machine using the recent Box2D i have Box2D.h in /usr/include/ and not in /usr/include/Box2D/.

    Ok no problem I thought and changed to: #include <Box2D.h> and i get lots of complaints saying
    ... [lots more above :)]
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp:1624:3: error: ‘poFixture’ was not declared in this scope
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp:1624:16: error: ‘b2Fixture’ was not declared in this scope
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp:1624:27: error: expected primary-expression before ‘)’ token
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp:1624:28: error: expected ‘;’ before ‘_pstBodyPart’
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp: In function ‘orxU16 orxPhysics_Box2D_GetCheckMask(const orxPHYSICS_BODY_PART*)’:
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp:1635:9: error: ‘b2Fixture’ does not name a type
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp:1643:3: error: ‘poFixture’ was not declared in this scope
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp:1643:16: error: ‘b2Fixture’ was not declared in this scope
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp:1643:27: error: expected primary-expression before ‘)’ token
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp:1643:28: error: expected ‘;’ before ‘_pstBodyPart’
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp: In function ‘void* orxPhysics_Box2D_Raycast(const orxVECTOR*, const orxVECTOR*, orxU16, orxU16, orxBOOL, orxVECTOR*, orxVECTOR*)’:
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp:1675:23: error: ‘class b2World’ has no member named ‘RayCast’
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp: In function ‘orxVECTOR* orxPhysics_Box2D_GetGravity(orxVECTOR*)’:
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp:1752:34: error: ‘class b2World’ has no member named ‘GetGravity’
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp: In function ‘orxSTATUS orxPhysics_Box2D_Init()’:
    ../../../include/../plugins/Physics/Box2D/orxPhysics.cpp:1803:79: error: no matching function for call to ‘b2World::b2World(b2Vec2&, bool)’
    /usr/include/Box2D/Dynamics/b2World.h:58:2: note: candidates are: b2World::b2World(const b2AABB&, const b2Vec2&, bool)
    /usr/include/Box2D/Dynamics/b2World.h:52:1: note:                 b2World::b2World(const b2World&)
    gcc -c  "/home/rich/Projekte/test/orx/code/src/render/orxFXPointer.c" -Wmissing-braces -Wparentheses -Wsign-compare -Wswitch -Wunused-variable -g -Wno-write-strings -fPIC -D__orxDEBUG__ -D__orxEMBEDDED__ -DAL_LIBTYPE_STATIC  -o Linux_Embedded_Dynamic_Debug/render_orxFXPointer.o "-I." "-I../../../include" "-I../../../../extern/dlmalloc" "-I/usr/include/SOIL/" "-I../../../../extern/stb_vorbis" 
    make[1]: *** [Linux_Embedded_Dynamic_Debug/plugin_orxPlugin_EmbeddedList.o] Fehler 1
    make[1]: *** Warte auf noch nicht beendete Prozesse...
    make[1]: Verlasse Verzeichnis '/home/rich/Projekte/test/orx/code/build/codelite/orxLIB'
    make: *** [All] Fehler 2
    ----------Build Ended----------
    142 errors, 12 warnings
    

    Is the Box2D outdated in the source repo?

    I also realized that the compiler took the wrong box2d headers and i think that was the reason for the memory access error. I dropped them now (all not just box2d)...

    I was wondering why you always compile the libs for the enduser?

    thx plan_rich
  • edited June 2011
    plan_rich wrote:
    Problem is the #include <Box2D/Box2D.h> cause on my machine using the recent Box2D i have Box2D.h in /usr/include/ and not in /usr/include/Box2D/.

    Ah yes, that will be problematic because orx is not using a vanilla version of Box2D. It's a modified version to suit orx's need (such as per body gravity support, for example).
    I was wondering why you always compile the libs for the enduser?

    For convenience, mostly. Almost all the libraries in the extern folder are modified versions either to add new features (box2D), fix some issues (glfw, sfml) or make them compile with compiler/platforms that were not supported by the original version (libsndfile, SOIL).

    If I remember correctly, all external dependencies but dlmalloc and stb_vorbis are customized versions so you won't be able to use the vanilla ones.

    If I weren't keeping the compiled versions on the repository, that'd mean that all the external libraries would have to be recompiled when someone wants to sync orx (and it happens often to me on new computers), which is pretty annoying (not even mentioning that windows and mac programmers don't expect to have to compile everything from scratch when getting a new tool, especially not the dependencies of said tool). :)
  • edited June 2011
    Of course, having an automated way to compile all the dependencies for all the platforms would solve this issue. We had a try with bakefile a few years ago but that turned out to be a nightmare as it was constantly crashing and producing invalid project files for visual studio or xcode most of the time.

    If someone is willing to automate the building process, that'd be great but I won't do it myself as I don't have the time nor the will: I'd rather spend my time adding new features and giving support instead. :)
  • edited June 2011
    iarwain wrote:
    Ah yes, that will be problematic because orx is not using a vanilla version of Box2D. It's a modified version to suit orx's need (such as per body gravity support, for example).

    Bad news :) ... Then I'll stick with the version shipped with orx.
  • edited June 2011
    iarwain wrote:
    Of course, having an automated way to compile all the dependencies for all the platforms would solve this issue. We had a try with bakefile a few years ago but that turned out to be a nightmare as it was constantly crashing and producing invalid project files for visual studio or xcode most of the time.

    If someone is willing to automate the building process, that'd be great but I won't do it myself as I don't have the time nor the will: I'd rather spend my time adding new features and giving support instead. :)

    I think I will give it a try to automate the build for linux/mac (no windows here :) ).

    When it turns out to work good for me I'll share the script and maybe it helps some poor linux 64 guys...

    plan_rich
  • edited June 2011
    plan_rich wrote:
    I think I will give it a try to automate the build for linux/mac (no windows here :) ).

    When it turns out to work good for me I'll share the script and maybe it helps some poor linux 64 guys...

    That'd be great. :)

    Here's the thread with Eyecreate's packages for linux64: https://forum.orx-project.org/discussion/1535#Comment_1980

    I don't think he's made any package with the newest release yet.

    I'll try to find some time to install a linux64 box here and see if I can prepare the project files/lib for this version which is becoming more and more popular. :)
  • edited June 2011
    I made some progress these days and made the liborx compile using the waf build tool (and most of the extern libs).
    I need some more information about the plugin system.

    Some questions:
    why use sfml, glfw or SDL? Is one of them not enough?

    Which one should I use, targeting a netbook platform to run my game?

    thx plan_rich
  • edited June 2011
    plan_rich wrote:
    I made some progress these days and made the liborx compile using the waf build tool (and most of the extern libs).
    I need some more information about the plugin system.

    Nice!
    Some questions:
    why use sfml, glfw or SDL? Is one of them not enough?

    Which one should I use, targeting a netbook platform to run my game?

    thx plan_rich

    Unfortunately one isn't enough, that being said you should use GLFW with embedded configurations as it's the most advanced one.

    The SDL one won't work on mac platforms and lack some of the features (rendering to texture, for example).
    The SFML one is also very limited (as it can't handle user-made fragment shader in a correct way, due to SFML's internal shader handling) but is the only one that can work in non-embedded versions due to its ability to share the runtime execution across multiple dynamically loaded libraries (which GLFW and SDL don't support).
    GLFW might support that in the future from what Camilla told me last year.

    Hope this sheds some light on the situation. =)
  • edited July 2011
    I managed to get everything compiled on my 64 bit machine (Arch Linux, with gcc 4.6.1 for ref)
    Here are my notes on the expidition, using the svn release:

    For the extern libs:

    The Arch packages for libsndfile, openAL, and freetype appear to work correctly, so you don't HAVE to use the included ones, I think. (If this assumption is wrong, please let me know.)

    stb_truetype, stb_vorbis, and dlmalloc are merely includes for orxLib, thus do not need to be built on their own.

    SDL and SFML are not required at all, since I used glfw.

    glfw can be made using
    "make x11" with the makefile in the glfw-2.7 dir.
    You need to copy or move the resultant glfw-2.7/lib/x11 folder to glfw-2.7/lib/linux so that orxLib can find it.

    Box2d and SOIL can be built using the codelite project files without issue.

    A note on codelite: It lies. Do not trust it's "Build Successfull" or "0 error, 0 warnings" messages. Check the build log and make sure gcc didnt actually choke on something. (Seems mostly to struggle with linker errors.)

    Finally, for the actual orx package: load up the codelite project.
    Use the Linux Embedded build profiles exclusivly.

    If you try building the entire workspace right away (eg, Linux Embedded Dynamic Debug) you should be able to produce an executable. Check the log file for any linker errors, make sure it didnt die.

    Assuming this works, you can run it and watch it segfault. :)


    On 64bit gcc the 'long' type is 64 bits, which makes the orxU32 and orxS32 types actualy 64 bits.
    Normally this would not be an issue, but the algorithm used by orxMath_GetTrailingZeroCount only works when those are
    exactly 32bit types (worse: it does work for certain inputs with the 64 bit types) Since this function is used in a memory allocation scheme, I get segfaults on a 64bit machine.

    Solution: the 'int' type is 32bits for me on both 32bit and 64bit gcc.
    Open up orxLIb->include->Base->orxType.h and go to lines 100 and 105 and change:

    From:
    100: typedef unsigned long orxU32;
    to:
    100: typedef unsigned int orxU32;
    and from:
    105: typedef signed long orxS32;
    to:
    105: typedef signed int orxS32;


    This introduces another issue: theres many type conversions between pointers and orx32 integers, of course, orx32 types are now no longer as big as 64bit pointers.

    Thankfully, most of this just results in warnings which I ignored. However, it does seem to throw errors sometimes when trying to typecast from the pointer to the integer due to the loss of precision. To fix this, typecast to the 64 bit integer type first, then to the 32bit.

    I recieved these errors exclusivly in the orxPhysics_Box2D package; changed lines 350 and 355 of orxPhysics.cpp (!!! not .c !!!) :

    From:
    350: sstPhysics.poWorld->Step(orxPhysics::sfMaxDT, (orxS32)_pContext, (orxS32)_pContext);
    to:
    350: sstPhysics.poWorld->Step(orxPhysics::sfMaxDT, (orxS32)(orxS64)_pContext, (orxS32)(orxS64)_pContext);
    and from:
    355: sstPhysics.poWorld->Step(fDT, (orxS32)_pContext, (orxS32)_pContext);
    to:
    355: sstPhysics.poWorld->Step(fDT, (orxS32)(orxS64)_pContext, (orxS32)(orxS64)_pContext);

    From here, clean and build the entire workspace, and I got a working demo to run with F5, and had no trouble compiling my own small test.
  • edited July 2011
    4babce wrote:
    I managed to get everything compiled on my 64 bit machine (Arch Linux, with gcc 4.6.1 for ref)
    Here are my notes on the expidition, using the svn release:

    Thanks for all these info, I'll make sure to make some changes accordingly soon.
    For the extern libs:

    The Arch packages for libsndfile, openAL, and freetype appear to work correctly, so you don't HAVE to use the included ones, I think. (If this assumption is wrong, please let me know.)

    You're right, if you have linbsndfile in your distro, the orx version has nothing special about it (except it can be compiled with visual studio but that's all). Freetype is only used for the font generation tool (orxFontGen), not for orx itself.
    stb_truetype, stb_vorbis, and dlmalloc are merely includes for orxLib, thus do not need to be built on their own.

    Exactly. Also: stb_truetype isn't used anymore and was only for tools anyway.
    SDL and SFML are not required at all, since I used glfw.

    As long as you're using embedded versions, the GLFW plugins are the ones to use and you can completely forget about SDL and SFML.
    glfw can be made using
    "make x11" with the makefile in the glfw-2.7 dir.
    You need to copy or move the resultant glfw-2.7/lib/x11 folder to glfw-2.7/lib/linux so that orxLib can find it.

    Glad it compiles out of the box.
    Box2d and SOIL can be built using the codelite project files without issue.
    Excellent!
    A note on codelite: It lies. Do not trust it's "Build Successfull" or "0 error, 0 warnings" messages. Check the build log and make sure gcc didnt actually choke on something. (Seems mostly to struggle with linker errors.)

    Finally, for the actual orx package: load up the codelite project.
    Use the Linux Embedded build profiles exclusivly.

    If you try building the entire workspace right away (eg, Linux Embedded Dynamic Debug) you should be able to produce an executable. Check the log file for any linker errors, make sure it didnt die.

    Assuming this works, you can run it and watch it segfault. :)

    Woops! :)

    On 64bit gcc the 'long' type is 64 bits, which makes the orxU32 and orxS32 types actualy 64 bits.
    Normally this would not be an issue, but the algorithm used by orxMath_GetTrailingZeroCount only works when those are
    exactly 32bit types (worse: it does work for certain inputs with the 64 bit types) Since this function is used in a memory allocation scheme, I get segfaults on a 64bit machine.

    Solution: the 'int' type is 32bits for me on both 32bit and 64bit gcc.
    Open up orxLIb->include->Base->orxType.h and go to lines 100 and 105 and change:

    From:
    100: typedef unsigned long orxU32;
    to:
    100: typedef unsigned int orxU32;
    and from:
    105: typedef signed long orxS32;
    to:
    105: typedef signed int orxS32;

    Makes sense. I'll update the code tonight.
    This introduces another issue: theres many type conversions between pointers and orx32 integers, of course, orx32 types are now no longer as big as 64bit pointers.

    Thankfully, most of this just results in warnings which I ignored. However, it does seem to throw errors sometimes when trying to typecast from the pointer to the integer due to the loss of precision. To fix this, typecast to the 64 bit integer type first, then to the 32bit.

    I recieved these errors exclusivly in the orxPhysics_Box2D package; changed lines 350 and 355 of orxPhysics.cpp (!!! not .c !!!) :

    From:
    350: sstPhysics.poWorld->Step(orxPhysics::sfMaxDT, (orxS32)_pContext, (orxS32)_pContext);
    to:
    350: sstPhysics.poWorld->Step(orxPhysics::sfMaxDT, (orxS32)(orxS64)_pContext, (orxS32)(orxS64)_pContext);
    and from:
    355: sstPhysics.poWorld->Step(fDT, (orxS32)_pContext, (orxS32)_pContext);
    to:
    355: sstPhysics.poWorld->Step(fDT, (orxS32)(orxS64)_pContext, (orxS32)(orxS64)_pContext);

    Thanks, I'll change that too. We do mostly pointer casting to get unique IDs. It's ugly so I'll see if I can't find something more elegant and get rid of the problem completely.
    From here, clean and build the entire workspace, and I got a working demo to run with F5, and had no trouble compiling my own small test.

    Great! One question though: were you able to get the FPS display work? What about any on-screen text using the default built-in font?


    Thanks again for all this, it's very helpful! :)
  • AlsAls
    edited August 2011
    Hi!
    Today I looking for multiplatform game engine and I found orx. I must appreciate good tutorials and generally thoughtful design.

    Downloaded orx-tutorial-linux-1.3rc0.tar.bz2 works but seems to me slowly (130 FPS in 01_Object), so I decide compile my own build. Thanks to 4babce I get 64bit build quickly. I also use sndfile, openal and freetype from my distro (Fedora 14).
    iarwain wrote:
    Great! One question though: were you able to get the FPS display work? What about any on-screen text using the default built-in font?
    FPS display works in tutorials with my 64bit build (BTW 620 FPS in 01_Object now) but I got SIGSEGV on 06_Sound and 10_StandAlone, 11_Spawner and 12_Lighting simply exited without error, I suppose due to work with font.
  • edited August 2011
    Hi Als, and welcome here!

    First of all, thanks for your appreciation! Any comment/suggestion is welcomed, of course.

    I'm afraid you'll have to use the latest SVN if you want a stable linux64 version as some fixes have been added for that since the latest release candidate.
    I also added project files for codelite and everything compiled and ran just fine for me in my linux64 box.

    As for the FPS, on win32 I get about 6000FPS (on a Phenom II x6 1055T / 4GB RAM / ATI 5570) for that tutorial if I remove the VSync. That doesn't measure much of course, but it's for giving an order of magnitude.

    I was able to run all the tutorials on linux64 when compiled with the new config targets in codelite (called linux64).

    Another thing I'd like to point out: as you'll have to compile your own orx version after syncing the svn, always use the dynamic embedded targets and if you use the profiler one, you can display at runtime where time is spent for a frame by simply adding to your config:
    [Render]
    ShowProfiler = true
    

    Let me know if you have any questions. You can also join the IRC channel on freenode.net / #orx-project.
  • AlsAls
    edited August 2011
    iarwain wrote:
    I'm afraid you'll have to use the latest SVN if you want a stable linux64 version as some fixes have been added for that since the latest release candidate.
    Iarwain thank you for information and really fast response. You doing great work.
    iarwain wrote:
    I also added project files for codelite and everything compiled and ran just fine for me in my linux64 box.
    I found there is missing codelite project file for glfw, but make works great.
    iarwain wrote:
    As for the FPS, on win32 I get about 6000FPS (on a Phenom II x6 1055T / 4GB RAM / ATI 5570) for that tutorial if I remove the VSync. That doesn't measure much of course, but it's for giving an order of magnitude.
    My numbers FPS from work pc corresponds with configuration ([email protected] and NV7600GT with Nouveau :)) on my home game rig ([email protected], GTX570) with SVN build and on Fedora 15 is 8500 FPS. It seems that engine scales well.
    iarwain wrote:
    I was able to run all the tutorials on linux64 when compiled with the new config targets in codelite (called linux64).
    Yes, I confirm it, it works great.
    iarwain wrote:
    Another thing I'd like to point out: as you'll have to compile your own orx version after syncing the svn, always use the dynamic embedded targets and if you use the profiler one, you can display at runtime where time is spent for a frame by simply adding to your config.
    I like features that you incorporate to orx. I think orx is the right engine for my project. I now go play with it :woohoo:
  • edited August 2011
    Als wrote:
    Iarwain thank you for information and really fast response. You doing great work.

    You're welcome, there's usually always someone around to reply within a day or two max. Thanks again for your appreciation. :)
    I found there is missing codelite project file for glfw, but make works great.

    True! GLFW is one of the rare dependencies that had a decent multiplatform build system so I didn't feel the need to add a custom codelite project file. :)
    My numbers FPS from work pc corresponds with configuration ([email protected] and NV7600GT with Nouveau :)) on my home game rig ([email protected], GTX570) with SVN build and on Fedora 15 is 8500 FPS. It seems that engine scales well.

    It doesn't do too bad so far, I remember that Laschweinski noted that it was even slightly faster than Cocos2D on the iOS devices he tested (but that was a while ago so it might not be true today, haven't tried it myself :)).

    EDIT: I should soon add a loose quadtree(aka cover fieldtree)-based partitioner to speed up rendering of worlds that contain a huge amount of objects.
    Yes, I confirm it, it works great.

    Excellent!
    I like features that you incorporate to orx. I think orx is the right engine for my project. I now go play with it :woohoo:

    I hope you'll like what you'll find then. :D

    Don't hesitate to ask questions around here as there are many more-or-less hidden features that are not really well documented or shown in tutorials. Two examples that come right now to my mind are the physics joint support (I still need to write the wiki section about that!) and the fact that you can modify sound packets on the fly (by listening to the orxSOUND_EVENT_PACKET event) when streaming sounds: I use it in one of my current projects that contains a soft synthesizer so as to swap instruments and change sound envelopes on the fly.
Sign In or Register to comment.