It looks like you're new here. If you want to get involved, click one of these buttons!
Everything compiles out-of-the-box for the hardware platforms cited above.
sndfile;openal;dl;m;glfw;SOIL;box2d;GL;X11;Xrandr;sfml-system
[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
Comments
Hi and welcome!
I had a quick glance at the site and it looks really interesting. I'll look more into it later.
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?
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.
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
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
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).
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).
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.
Bad news
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
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.
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
Nice!
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.
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.
Thanks for all these info, I'll make sure to make some changes accordingly soon.
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.
Exactly. Also: stb_truetype isn't used anymore and was only for tools anyway.
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.
Glad it compiles out of the box.
Excellent!
Woops!
Makes sense. I'll update the code tonight.
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.
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!
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).
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.
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:
Let me know if you have any questions. You can also join the IRC channel on freenode.net / #orx-project.
I found there is missing codelite project file for glfw, but make works great.
My numbers FPS from work pc corresponds with configuration ([email protected] and NV7600GT with Nouveau
Yes, I confirm it, it works great.
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:
You're welcome, there's usually always someone around to reply within a day or two max. Thanks again for your appreciation.
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.
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.
Excellent!
I hope you'll like what you'll find then.
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.