Raydium 3D Game Engine

Hi,

A) No all my changes were about some compile fixes such as defines that would colide with VS.

B) me too

C) if you use my make file you can decide to build raydium as static by doing make SHARED=no and shared library as make SHARED=yes

D) i assume if you follow the long post your /usr/local/lib will contain all the required static libs which are: openAL alut, glew, ode, ogg, vorbis and PHP.

I tryed to compile all static but i didn't manage to do it for glew and PHP

The pros are that you always have the right libs to link and you only need to ship 1 DLL that internally is already linked to all other libs

The cons are that if there is an update to those libs you need to recompile everything instead of just replace a dll

the last pro is that if you ship 1 dll you can build app that only link to that dll and it's done, if you ship all static you need to link your app to all libs and if you're using other compile you also need to link against mingw static runtime libs which will need to be shipped along the engine although they are not part of it at all.

E) I had a problem on my HDD and i need to rebuild them all again

F) I like it, maybe appli should be something like examples or demo i think. And maybe move the headers to a root folder /include so you know that if you make an SDK you only need to use the include and the lib/bin dirs.

G) I'm not an expert either no worries, without you initial work i'd never had got to this place.

Hello,

Allways corrupted console, i continue to dig ...

Static and dynamic linking are simplyest now (sorry Xfennec).

About static dependency.
For glew need to add GLEW_STATIC define to get glew build as static.

I don't manage to get openal compiled as static lib.
(Perhaps you can edit your first post, openal32.dll in place of openal.dll)

Comming with openal there is an wrap_oal.dll. This dll is needed by certain soundcard hardware. Else all application fails, don't know why.


for others libs, it's perhaps easier to get their binaries. Is it very important to build them all ? (Of course in this case your post is very very interesting).

About Static versus Dynamic, i think that ode will be dynamic. Following the mailing list they are lot's of bug fix and quite often new version. Good client for dynamic link no ?

I misunderstand your last pro.
Ok for one big raydium.dll with all dependancy as static.
Second part ... if you ship all as dynamic ?
I need to link with all dynaminc libs, which is already the case for raydium. In this case a big static lib is a good thing.

Can you send me your static libs to test build process from your side.
For now i try to compile your source code from my sdk.
I think this cross evaluation is important for sdk robustness.

Ok for a demo or test directory (perhaps both).
I also forgot include, you'r right.

i'm slowly updating my msys to manage to compile following your details. But i also investigate about this console.

Xfennec advise on Sdk structure / static / new raydium.h ?

Have a nice day
Ouille

I just rebuilt all dependencies, you can get them at:
http://public.box.net/pmlopes

if you like i can also publish the source code for those builds, basically is just some tweaks on the header files that are already on the include folder.

For those in trouble to get a working dev environment i also uploaded my msys environment, you just need to unzip it to your C:\ and start it using the batch C:\msys\msys.bat

after this you have a fully configured GCC 3.4.5, G++ 3.4.5, GDB, Insight GDB and most of the unix tools required to build software...

Hello,

I progress slowly with your work.

I manage de build static lib using your libs. Size is quite impressive 30Mb in debug mode. Release is less than 2Mb.

I have some problem creating application such as test6. But i continue to work on it

You have done lots of cleaning work. But also quite deep modification in raydium source code and sdk structure

I think that xfennec need to validate this before we go further.

About glew as static lib, is saw in the header it need to define GLEW_STATIC, in the binaries distribution there is a glew32s.lib Is it usefull ?

The link order is important, i need to link alut before openal32, i don't know why but it's not in this order in your makefile.

I plan to have several sdk

1) The minimalist with just include, libs, and raydium

2) An other one with embedded mingw and a small application or shell to build application (for non developper) like ld sdk

3) With an ide as code block

4) Full one which is your work if you are agree.

I think we need to have a very simple sdk (the second one) for people who just want to test raydium without knowledge of an ide or makefile process.

What do you think about this

Xfennec

Have a nice day
Ouille

Hello

test6 work now.

Some remarqs: wrap_oal.dll is need for some soundcard. Else application fails on run slowwwwwly. Don't know why but add this dll to bin folder solve problems.

your test6 is modifier to use lua, but the raydium lib is not so there are some problems. Reverting to original state work normaly.

A printf in file.c line 140 don't conform to raydium_log format that why i found the console corrupted.
To have "normal" console behaviour i need to define _DEBUG (conforming to your makefile).

On question, i build raydium as static lib. When i link my application i thought i don't need to link against all libs, only raydium, php and glew. This doesn't work, i always need to link with all libs. Perhaps i make a mistake some where.

Have a nice day
Ouille.

Hello,

Can you confirm this:

For the engine:

Static build with flags:
_WIN32 if needed _DEBUG

Dynamic link:
_WIN32 and RAYDIUM_BUILD_SHARED_LIBRARY

For application:
_WIN32 for static raydium lin
_WIN32 and _SHARED if raydium is built as dll.

One question:
if raydium is a dll, application link is minimalist (only lib ode, li php). But code syze is huge 6Mb. Why ?

Have a nice day
Ouille

_WIN32 is added automatically by GCC and is also the same key that visual studio uses, visual studio uses for debug _DEBUG so i renamed all the DEBUG to _DEBUG so it would be the same for both compilers.

About the other flags they are correct.

and finally... the lua stuff was a test of mine... i can replace the scripting engine from php to lua.

Hello,

I have finished a new windows Sdk

This work is based on librairie built by paulo, but does not integrate raydium overall re-structuration.

I'll include the new raydium structure in the sdk after svn update.
Migration will not be very difficult paulo does quite all the work.

Structure is based on previous proposal.

I integrated Ide (codeblock) and compiler (Mingw), the sdk is quite Big 40Mb but allow an easy start with raydium. Sample project are provided and batch file to compile everything.
http://ftp.cqfd-corp.org/raydium_sdk_ide_593.zip


I give an other sdk without ide and compiler. This one contain include / libs / dll needed to build raydium dll and apps but without ide and compiler. This one is smaller (only ? 8Mb).
http://ftp.cqfd-corp.org/raydium_sdk_593.zip

Windows users can test this sdk and reports bugs Please

Have a nice day
Ouille

Thanks, i am going to test it.

Great ! Nice work !

I've just tested the "full" SDK (with codeblocks + mingw), and it's exactly what we need. Simple but complete.

A few points :
- for an unknown reason, "raydium" directory is not seen as a subversion checkout ... (and the .svn directory are here). A problem only on my windows ?
- README.txt could be a bit more complete: describing itself as Raydium windows SDK, explaining in a few words what Raydium is, a link to the website, things like that. It may sounds insignificant, but small points like this may help a lot newcomers. For example, complile_all.bat is not "documented", and it should probably be the first thing to call for a real beginner. The README may start with something about this script, I think. "You have no idea about how to use this SDK ? Just launch compile_all.bat and play with exe in the bin directory ... That's it."
- rayphp directory have moved. Nothing wrong about that, but it does not follow the SVN tree, so we should think about a way to fix this.

All these small points must not hide the fact that this SDK is very good and can replace our old official SDK almost now.

Again, nice work guys !

Hello,

After several tests raydium is svn ready on my "tests" (virtaul) machines.

I'll expand readme.txt and include in a next sdk.

Rayphp need to be in bin directory i'll add a script to copy form raydium to bin, and perhaps removing svn in bin directory.

Paulo sdk structure have lot's of modification, but seem more "regular". Can you have a look at it ? It involve modification on both windows and linux.

Have a nice day
Ouille

About rayphp, we can probably found a "smart" solution, since this problem also exists when you deploy Raydium applications to different paths (you must made as many copy as deployments).

Currently, the --rayphp command line option, allowing to give direct path to rayphp, so all is ready internally for rayphp path change.

So we can imagine something like a config option in config.h ? SVN tree will be shipped with a default of "rayphp/" and your SDK with "../rayphp" so everyone is happy ? Or this setting can be stored in a config file loaded on startup ?

I kind of finished the restructuring of the files in the project. All demos/apps are in a individual folder and contain a makefile that can build it.

there is a top makefile that trigers all the others (kind of the same as autotools)

on the root folder if you call:
make

this will build the DLL and the jpgs tools and all the demos except (the ar one)

to change the build mode, again at the root you can call something like:

make DEBUG=NO
# disables the debug info

make SHARED=NO
# builds a static lib and all the tools and demos linked against the static lib

make SHARED=NO DEBUG=NO
#becomes obvious...

In the binary package that i build you have the raydium.dll that is 1.2Mb and the mania_drive.exe is 62kb!!!

here are the links:
http://public.box.net/pmlopes

the src code: raydium-20080106-src.7z
the bin: raydium-20080106-bin.7z

All this was made against the SVN code from 2008-01-04.