Raydium 3D Game Engine

Hello,

One of this day we have to rename it raydium_math_max, it's not specific trigo function.

Have a nice day
Ouille.

Yep ! We should create a math.c module (or rename trigo) and move all these functions here (with an alias for old names)

Hello,

done rev 738.

Have a nice day
Ouille.

SVN broken ...

This patch may have a huge impact on engine "microcosm".

A few things:
- Makefile is broken (now updated)
- Compilation currently fails (*)
- Some macro in math.h are not completely defined ("define func1 func2" instead of "define func1(a) func2(a)"
- Using macro instead of functions may have repercussions on things like bindings (internal [PHP] but mostly externals [Java & Python]). I must check all this. It will break API compatibility, but it's (quiet) acceptable, I think, since there's still very few users of external bindings.

(*) compilation log :

Ok, versusrx updated for using math min and max functions.
Also I have fighting with code until I saw a commit of Xfennec that I had to revert (I'm not sure what was failing, but the commit was the problem)

Ouille, I guess that the windows version should have an installer or something like that. Do you know something about that?

Hello,

Oups again.

For Makefile , i've tested on windows and forgot linux. Sorry.
But there is no makefile, i modify index.c index.h. Can you be more explicit about makefile ?

Compilation: I have no such problem on windows, i'll try to fix it, but i'll need linux tester.
(what packages does i have to install on a linux virtual box to make compile test ? Is there info about this somewhere. I'll search for that).

Ok i'll make full function alias to solve exported api problem. But is it really a good thing to keep raydium_trigo in the exported api ?

Other errors, it's an deeper problem wich ennoy me a lot.
I haven't touch matrix function at all. Code / declaration are the same. only the file have (trigo -> math) been changed.

Last errors are due to miss prototyped function / order in the c file. But why does this appear only now ?

Looking precisely at your post show me one very strange file, Xfennec you are hidding things to us !

How can you compile only math.c -> math.o. Raydium is always compiled as a single file. I remember Paulo work on this side, but i don't remenber that you accept a such deep modification.

Have a nice day.
Ouille

About Makefile I think the problem was only a tab<->spaces change surely by an automatition in your editor. For example I can not open any Makefile with geany cause they will be saved badly.
It was a "separator" error.

Ouille, you seems quiet unaware of Linux flavor of Raydium

The usual way to compile Raydium library for Linux is using the Makefile (http://raydium.org/svn.php?f=/trunk/Makefile), provided in the official trunk. This Makefile use "index.h" style of Raydium (and not "index.c" style as we used to do for win32 DLL) and compiles modules one by one. This switch was done years ago, by mildred. (was a huge work, you're right)

So, the trouble with the Makefile was very simple (see my commit 739): it was still trying to compile trigo.c.

Then comes the trouble "it was working for trigo and it does not compile anymore with math". It toke me a lot of time to figured it out but ... the _MATH_H define in top of the header file, to protect the file from "multiple includes" ... is already defined by the GLIBC ! I moved it to _MATH_H_RAY and all is ok. So your commit was good, ouille, you're just very unlucky

About macro, I've check quickly all my own applications that use bindings, and no use of trigo was done, so it's ok for me like that (I've just completed macro arguments), since I think there very few users of these bindings yet.

All this is now fixed by commits 740 and 741.

Hello,

I try to have a file by file compile for windows.

But i'm lost with
RAYDLL
FORCE_LIBRAYDIUM
DO_NOT_INCLUDE_HEADER
MAIN_C
MAIN_H and even
LIBRAY:?:.
..... sure it's not the first time !

basic index.c compiling is quite long for often very small changes.

Here is what i've found, can you just confirm ?, perhaps detail if you have lot's of free time ?

1) First: FORCE_LIBRAYDIUM and MAIN_C are the same !FORCE_LIBRAYDIUM => MAIN_C, FORCE_LIBRAYDIUM => MAIN_H.

2) If raydll is not defined, i can just compile static app, but i can not build static raydium.lib without adding an other define (no .... not an other one please) to define __global as extern in the appli (not the lib).

3) if raydll is define: when i build index.c i build the lib dll.

4) if raydll is defined: when i build something that include index.h, or if i FORCE_LIBRAYDIUM and i include index.c i build a shared app (which will use the dll).

5) To build the librarie as on linux (file by file compile). i need RAYDLL defined and MAIN_C so !FORCE_LIBRAYDIUM. But as files include index.h i'll have MAIN_H defined.

Last but don't forget : big troubles no bubbles !!!

6) Each file will include index.h so main.h so common.h so all global vars will be in each object file. Linking all of this together make 33Mo for the lib (ouch).
This cause a problem in path api, each variable exist in each object (or i'm false ?).

And there i don't understand how you handle this case with the linux makefile.

Don't waste your time about raydll and forcelibraydium it's in an other post (i'm quite sure of 1,2,3,4).

Do you have an idea of steps or modifications needed to have file by file build on windows ?

Have a nice day.
Ouille with headache.

I'll try to explain a bit how Linux dynamic compilation is done.

First, there's two way to compile an application.
The first (and old) one is to build a big binary with Raydium engine and application. This is done with "ocomp.sh" script, without any particular define. The application should include "index.c" (will define MAIN_C)

The second one is to build the Raydium library, using the Makefile, and the application on the other side. This application should include "index.h" since it only needs prototypes and not source code of functions. Since it's not easy to switch between "index.c" and "index.h", it was decided to always use "index.c" and redirect it to "index.h", using "-DFORCE_LIBRAYDIUM" when compiling the application. "main.h" will define MAIN_H.

For the application, MAIN_C means that variables are used directly and MAIN_H means "extern" keyword.

OK for that first part ?

So, the Makefile now. This file is mainly dedicated to libraydium.so building. (you probably already know it, but so = Shared Object, almost the same thing as a DLL)
This library is compiled file by file, as you've seen.
Each file is compiled that way:
1) The "-c" GCC flag is used, of course (no linking)
2) The "-DLIBRAY" is used. Since "index.c" is not included, "DONT_INCLUDE_HEADERS" does not exists. So headers are included, with the help of "index.h".
3) "Index.h" will include all others headers + common.h. Here, __global is defined to anything, so variable are "duplicated" in every generated file (but that not a trouble since no linking is done)

Then, linking is done, using "-shared" gcc flag to produced the .so. The other job of the linker is to gather all (duplicated) variable symbols in object files and generate unique entry points in the shared object.

Is all this make things a bit clearer ?

Hello,

SO ...

I change this in common.h


In fact i only invert dllexport and dllimport.

Here is my interpretation of the meaning of flags:

RAYDLL i work with a Dynamic link type librarie.
FORCE_LIBRAYDIUM i work with a librarie.

When i compile raydium C file with RAYDLL i create the DLL.

When i compile raydium C file without RAYDLL i create a static lib.

When i compile an application with RAYDLL and FORCE_LIBRAYDIUM : working with librarie wich is a DLL
When i compile an application with FORCE_LIBRAYDIUM: working with librarie static link.
WIthout FORCE_LIBRAYDIUM: compiling without librarie.

Now i achieve to have this:

compiling and linking (ar ) together raydium .c files.
If RAYDLL is defined: i create raydium DLL.
if not i create raydium static lib.

Compiling an application:

if RAYDLL and FORCE_LIBRAYDIUM defined: linking and using the DLL
if FORCE_LIBRAYDIUM only linking with static lib
if none Full static compile (no raydium librarie needed).

I have one problem with raydium_init_args need to make this coherent with my flags.

What do you think about that ? Am i on the way ?
Any other border effect as raydium_init_args ?

If everything ok should i commit and update sdk ?

Have a nice day.
Ouille.

Perfectly remember starting to reply to this post, but can't remember why it did not post it ... probably forgot to click the "submit" button while diving deeply in all that build stuffs ...

I saw you commit (747), and I'm OK with it (and since it works as it should under win32 and does not broke anything for other targets, I couldn't disagree ) except for a small point : FORCE_LIBRAYDIUM. This symbol has currently one goal: allow applications to use "index.c" even when they should use "index.h". With your building improvement, it becomes mandatory to have this define even if you include index.h in your applications.

MAIN_C and MAIN_H didn't do the trick ?

(Apart from this, this building system makes win32 and Linux target closer, it's a good thing)

Hello,

MAIN_H have a problem:
1) Creating dll as on linux, compiling each file -> MAIN_H is defined.

2) Creating an application with FORCE_LIBRAYDIUm -> MAIN_H defined.

Case 1 i need dllexport as global, case 2 dllimport. So i can't only handle this with MAIN_H.

That's why i use FORCE_LIBRAYDIUM.

But it doesn't break old compile way. So ...

Understanding the concept was very hard, but this involve realy few modification, we can revert them if a problem arise.

Have a nice day.
Ouille

Ouille, can you try the last changes(rememeber, in the experimental branch) of versusRX?
There is a looot of changes and i'm afraid thath a function could have appeared without declaration or something.

ouille: of course (DLL is a stupid system ). You're right, that's ok for me.

(We're a bit of topic here, sorry vicente !)