Orx

External libraries (GTK, GSL, SDL, Allegro, OpenGL, etc) questions.
iarwain
Posts: 22
Joined: Jan 22, 2010 9:45
Location: Montreal
Contact:

Postby iarwain » Feb 24, 2010 0:33

AGS wrote:I've just checked out the source code of the .h files and looked at the functions declared inline. The orxSTRING and the orxMATH module are the ones that use inline functions a lot and orxSTRING has some lengthy ones. The other modules use inline here and there (mostly one liners combined with assertions).

I would suggest the following solution.

Inline functions can be translated to FB macros. As the inlined functions are declared static they cannot be seen from FB code so using the FB macros instead of the inline funtions should not pose a problem. Of course rewriting of those inline functions will be done by me.

I had planned to be translating the inline functions to FB macros from the start so to me it's just 'part of the plan' (I had expected to be doing so anyway).

If I use macros it will get a bit harder for duke4e to port his app from FB to C as he would not be able to use the macros as functions.

Something like

Code: Select all

<macro_name><argument_list,s>
etc....


would become

Code: Select all

s = <function_name><argument_list>
etc.....


in C.

My solution does mean I'd have to follow changes in the orx code but I don't think that's a major problem.

For now I think the macro solution will do. I wanna get that orx lib working asap and using the macro solution I should be able to get it to work.

The problem with the dynamic link library had to do with pexports adding DATA to every line. I thought that was a bit weird as pexports usually does not do that.

The dll, however, worked as it should so stripping DATA from the lines produced by pexports could be enough to use i's output with dlltool.

So I can actually put that import library together. I do not remember, however, seeing any symbols from the SFML library inside the dll.

If I get the macros solution to work I think I'd still need to have those SFML related files or I'll be getting linker errors.


I'm fine with your solution but I was hoping we could find a way to prevent this extra work on your side. If you plan on following orx, I'll inform you when releases are made (next one is currently scheduled for early may) but if you prefer you can also subscribe to orx's development mailing list (you'll find it via orx's sourceforge page).

As for the missing external symbols, they are not exported in the DLL (as being extern to orx) but the corresponding code should however be present as those links are resolved when the DLL is built/linked.

However this isn't the case when building a static library as static libraries are mere gatherings of all built objects (ie. there's no link stage), hence needing to manually embed the external object files as well. In order to do so I simply need to extract all .o from libBox2D.a and the other external libraries, then pack them into liborx.a.

As for the static version, I'll update the package tomorrow and I'll include Box2D & SFML code/symbols into liborx.a. I couldn't do it before as I don't have access to binutils on my laptop.

I'll keep you posted when it's done.

Good luck on porting orx to the iphone!


Thanks! Things are going very smoothly lately: everything seems to work well so far.
I simply need to add text and sound support in order to finish the port.
I also added code to catch/relay multiple touches & accelerometer/motion info, but I can't test it on the iPhone simulator.

Testing on a real device requires to register to Apple's IDP program which costs 99$/year. So this part will wait a bit. :)
iarwain
Posts: 22
Joined: Jan 22, 2010 9:45
Location: Montreal
Contact:

Postby iarwain » Feb 24, 2010 21:51

I've updated the archive.

The static libraries now contain all the external symbols. I also checked the dynamic binaries and they also contain them (they should be the same as the ones you already have).

I haven't tried to link against these libraries due to lack of time but I assume we won't have anymore surprises.

I'll still try to find an alternative to re-write all the inline functions. I'll keep you posted if I find something.
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Postby AGS » Feb 24, 2010 23:16

iarwain wrote:I've updated the archive.

The static libraries now contain all the external symbols. I also checked the dynamic binaries and they also contain them (they should be the same as the ones you already have).

I haven't tried to link against these libraries due to lack of time but I assume we won't have anymore surprises.

I'll still try to find an alternative to re-write all the inline functions. I'll keep you posted if I find something.


Thank you very much for the updated archive. I'm almost done translating the inline functions and hope to be posting an Orx example soon.
iarwain
Posts: 22
Joined: Jan 22, 2010 9:45
Location: Montreal
Contact:

Postby iarwain » Feb 25, 2010 0:09

Excellent! I'm really looking forward to seeing an example work. =)

On my side, I've been toying with weak symbols and GCC 4.4.0 to try to export symbols/code for all the inline functions with no success: everything is correctly exported, no multiple symbols defined, but at runtime the weak symbol resolution is pure garbage. :/
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Postby AGS » Mar 02, 2010 0:48

One more day and I'll have a working orx example.
iarwain
Posts: 22
Joined: Jan 22, 2010 9:45
Location: Montreal
Contact:

Postby iarwain » Mar 02, 2010 0:51

Great! So I guess that the last archive was finally working? :)
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Postby AGS » Mar 06, 2010 1:18

The orx example I'm trying to compile/execute is not working yet but I'm close.

This is what I've done.

I've taken the spawner example and tried to compile it. Initially I got a lot of errors that had to do with libstdc++. So I ended up copying libstdc++ from the mingw distribution to the FB directory and I put this:

Code: Select all

#include "windows.bi"
#inclib  "stdc++"


at the start of the spawner source code example. That took care of most linker errors. Linking succeeded and then the spawner failed:

Assertion failed: worldAABB.IsValid(), file F:/workspace/orx/extern/Box2D_2.0.1/Source/Collision/b2BroadPhase.cpp, line 72


The line below is the FB line the program fails on

If(orxModule_Init(orxMODULE_ID_MAIN) <> orxSTATUS_FAILURE) Then


The program does not get past orxModule_init(orxMODULE_ID_MAIN).

But at least orx code compiles now which is good. And the static library you put together seems to be working well. Now if only we could get an orx example to work...
iarwain
Posts: 22
Joined: Jan 22, 2010 9:45
Location: Montreal
Contact:

Postby iarwain » Mar 06, 2010 2:39

I think you're now very close to a working example. =)

The assert you get is a Box2D assert complaining about the invalid dimension of the physics simulation world.

In the 1.1 release, I didn't put default values (I fixed that since then) so in your main config (.ini) file you need to specify values for the physics simulation.
You can look at SettingsTemplate.ini to see how to do it or, in more details, on the wiki.

Something like:

Code: Select all

[Physics]
Gravity         = (0.0, 981, 0.0)
WorldLowerBound = (-10000.0, -10000.0, 0.0)
WorldUpperBound = (10000.0, 10000.0, 0.0)


should work.

If you already have a config file, the default config file (ie. the one loaded automatically by orx, without any explicit call to orxConfig_Load()) is named after the main executable. Only with the extension .ini. It has to be in the same directory as your executable (and this one should be your working directory when launching orx, except on mac & iPhone where I manually force the working directory to be this one. I probably should do it for all platforms -_-).

More info about orx's config system here.

Let me know if you have any other issues.
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Postby AGS » Mar 08, 2010 20:28

I'm using the example that comes with orx 1.1 (11_spawner.c). Translated to FB (11_spawner.bas) of course. Config files are the same (I tweaked the ini files slightly (changes to paths)).

I'm wondering: do I need to fill out command line options? I removed the assertions from orxExecute (assertions: argc != 0, argv != orxNULL) because I figured that for this particular example (it links with the static library) there is no need for command line options.

If it's not the command line options then I'm running out of ideas on getting orx to work with FreeBASIC. I'm sure I'm overlooking some detail(s) but as it stands I will (sadly) not be the one providing FB bindings for orx.
iarwain
Posts: 22
Joined: Jan 22, 2010 9:45
Location: Montreal
Contact:

Postby iarwain » Mar 10, 2010 13:53

You don't need any command line parameter except argv[0] that is used to recover the executable name (and the working directory on iPhone/OS X).

If you can send me all your files, I'll be happy to check if I see anything obvious. As I'm currently visiting my parents I might not being able to do it as fast as I would normally though.

You can contact me directly using iarwain at orx-project dot org.
duke4e
Posts: 717
Joined: Dec 04, 2005 0:16
Location: Varazdin, Croatia, Europe
Contact:

Postby duke4e » Mar 26, 2010 18:20

Any progress?
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Postby AGS » Mar 28, 2010 16:16

duke4e wrote:Any progress?


I left Orx for what it was during a couple of weeks.

After that I contacted iarwain, picked Orx up again and got most of the example working but I could not get it to work quite the way it should work.

I got as far as getting text on the screen, the ORX logo flying through the screen, mouse was working, keyboard was working. To get it working completely some C code that was in a config file (I had translated the code to FB) should have worked but it didn't. Which wasn't much of a surprise since the code did not get compiled while building the example.

At that point I figured that way of using Orx (linking against the library and not using orx.exe) is not going to work for FB programmers. Too much hassle (I think). Orx has an easier way of buillding something and that's by letting orx.exe take care of the main execution loop, loading modules etc..... A lot more things happening in C without resorting to the use of FB macros.

Less use of FB macros = less maintenance in case of updates of the Orx lib = good. All you have to do when using orx.exe is:

-write three routines (init,update,event handler);
-write a config file;
-build an FB DLL (containing the three routines);
-put an entry in orx.ini stating what DLL it should use.

Executing orx.exe should then be enough to execute a demo/game.

You still have to link against liborx.a (and libstdc++) to build the DLL but I think I'll stick to using orx.exe because it takes care of so much things you'd have to take care of when not using orx.exe otherwise.

Right now I'm trying to build a DLL that orx.exe can execute.

So far no luck but I have not tried all that hard yet. I'm getting a very understandable error message which basically states 'the DLL cannot be loaded'.

Once Orx loads the DLL correctly all the examples that utilize orx.exe should work.
duke4e
Posts: 717
Joined: Dec 04, 2005 0:16
Location: Varazdin, Croatia, Europe
Contact:

Postby duke4e » Mar 28, 2010 18:39

It's good to see that you didn't give up on this project, and that progress is being made. As usual, if I can help with anything, just ask and I'll give it a shot.
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Postby AGS » Mar 30, 2010 20:51

duke4e wrote:It's good to see that you didn't give up on this project, and that progress is being made. As usual, if I can help with anything, just ask and I'll give it a shot.


Yes, you can help. I'll post a package with:
- the orx bindings and
- the example I'm working on.

If you could have a go at getting the example to work that would be great.

What you'll need is my package (I'll post it tomorrow) and the FB package built by iarwain. There are links to the package he built in this thread. You'll need liborx.a (liborxd.a) and orx.exe (orxd.exe) from his FB package (you might need the dlls as well).

You'll also be needing libstdc++.a (it's part of mingw) to be able to build the example.

I'll put a README in my package to explain what the example should do and why I think it's not working (yet).
duke4e
Posts: 717
Joined: Dec 04, 2005 0:16
Location: Varazdin, Croatia, Europe
Contact:

Postby duke4e » Mar 31, 2010 6:56

Sure, no problem!

Return to “Libraries”

Who is online

Users browsing this forum: No registered users and 1 guest