Raydium 3D Game Engine

ça y est, un package est désormais disponible pour compiler très facilement Raydium sous Windows avec Visual Studio .NET.

Note : Pour des raisons de simplicité, tout mettre dans c:\raydium

Pour compiler sous Windows :

1) Télécharger la dernière version de Raydium et décompacter l’archive dans le répertoire de votre choix. La dernière version stable de raydium est disponible sur le site de Raydium à l'adresse : http://raydium.cqfd-corp.org/data/raydi ... ent.tar.gz
Notons que ce guide a été réalisé à partir de la version raydium-2005-04-30.tar.gz.
Sous Windows, les fichiers .tar.gz peuvent facilement être ouverts grâce à Winrar.
On obtient alors 3 répertoires et une série de fichiers .c
2) Décompacter le fichier WinRaydium.rar dans le même répertoire.
Pour le télécharger, voir WinRaydium dans le Wiki.
3) Allez dans le répertoire WinRaydium et lancer la solution, puis faire un Build. Cela va générer 4 exécutables : le tutoriel 1, le train, le skydiver et test6.
4) Have Fun ! Merci aux concepteurs de ce fabuleux moteur pour leur excellent travail.


Pour recréer soi-même sa solution sous Visual Studio (pour les autres versions par exemple) :

1) Créer un nouveau projet Win32 Console et retirez tous les Source Files et les Headers créés par défaut – supprimez ces fichiers (stdafx.* et un fichier portant le nom de la solution).
2) Ajouter tous les fichiers .c du répertoire Raydium sous « Source Files » à l’aide du Solution Explorer, tous les fichiers .h dans « Header Files », et toutes les librairies fournies avec WinRaydium dans « Resource Files ».
3) Dans les propriétés du Projet, Sous « Configuration Properties/C/C++ » vous trouverez « Precompiled Headers ». Passez de « Use … » à « Not Using Precompiled Headers ».
4) Ajouter les répertoires suivant dans « Additional Include Directories » :
C:\Raydium\ode\include
C:\Raydium\WinRaydium\include
C:\Raydium\php\ext\standard
C:\Raydium\php\
C:\Raydium\php\TSRM
C:\Raydium\php\Zend
C:\Raydium\php\main

Guide et install réalisés par Gossellin De Bénicourt Grégory (raydium@benicourt.com)

Très bon travail ! félicitations. Je n'ai en revanche pas la bande passante pour tester ton travail pour l'heure.
Un point ceci dit : le repository de Raydium est exclusivement destiné aux données des applications, je placerais donc tes fichiers sur le site de Raydium une fois les tests passés.

Au passage, cette doc a sa place sur le Wiki (si quelqu'un passe par là et en a le temps ...).
Encore bravo.

Merci beaucoup,
Je vais continuer à étudier tout cela de mon coté afin de mieux connaitre le moteur.

J'ai mis à jour le Wiki, j'espère que c'est bien comme cela qu'on fait car je ne voulait manquer de respect envers personne du fait d'avoir modifié une des pages et en avoir ajouté d'autres. Je ne connais pas trop les us et coutumes du Wiki, alors veuillez me pardonner, tout comme d'avoir mis le fichier sur le FTP.

Au fait, j'en ai profité pour créer un librairie WinRaydium et une DLL pour faciliter l'utilisation sous Windows, mais ça ne fait pas partie du package de tout à l'heure. Cependant, elle ne fonctionne pas correctement. Pourriez-vous par exemple retirer les fonctions des fichiers include comme glarb.h et toutes les variables également de ces fichiers.
Il faudrait qu'elles soient déclarées externes dans les include et normalement dans les .c

Qu'en pensez-vous ? Je veux bien m'en occuper mais faudra qu'on travaille tous avec les mêmes sources. Qu'en dites-vous ?

_________________
Life is Hard, and then you die.

Bien sur qu'il faut qu'on travaille sur les mêmes sources !
Quand tu as des modifs à faire de ce genre là, travaille sur la dernière version publiée de Raydium, applique tes modifs dedans, et annonce tes modifs sur le forum. Si les modifications devaient prendre plus de temps (quelques jours) et porter sur une plus grande partie du programme, il suffit qu'on "freeze" le développement de Raydium le temps de tes modifs. Cette dernière solution avait été appliquée avec mildred pour le Makefile, à mon sens avec un certain succès. A terme, un SVN (Subversion) doit prendre tout ça en charge.
Le status de glarb.h est en plus très particulier, puisqu'il n'est utilisé que sous Windows (les headers GL sont en version 1.1 en général sur cette plateforme).

Ok, avant d'entamer tout cela, on conviendra tous ensemble de ce qui est à faire.

Mon idée est de mettre dans chaque fichier .C les variables globales qui lui correspondent et uniquement. Dans le .H, on fait la prédéclaration des fonctions et des variables globales.
De plus, dans chaque .H on include tous les .H nécessaires afin de pouvoir compiler séparément chaque fichier .C

Ainsi on pourra réaliser facilement une librairie et les DLL correspondantes et je pense qu'on s'y retrouvera mieux.

Ainsi, nous restons aux normes ANSI et on pourra documenter chaque fichier C et ses variables globales correspondantes. Pour moi, c'est la seule façon de réaliser les classes C++ correspondant à chaque fichier .C, sinon je risque d'avoir de gros problèmes de variables déclarées à plusieurs endroits.

Qu'en dites-vous ? Je peux réaliser ce travail en moins d'une journée si vous le validez (sauf doc).
Par ailleurs, où trouver la dernière version ?

Il y a une sorte de CVS ? J'ai vu qu'il y avait WVS, mais que le moteur raydium ne semblait pas avoir été modifié de puis 19 Mars 2005. C'est bien cela ? C'est étrange puisque j'ai utilisé la compil du 30/04/2005... Alors je pige pas, tu parles d'un autre CVS ?

_________________
Life is Hard, and then you die.

Je crois qu'il a une préférence pour Subversion (SVN).

Sinon, ce serait très très bien ...
Mais je crois que j'avais déja (pour chaque fichier .c) inclus les .h nécessaires, et uniquement.
Ou alors, peut être que ce n'était qu'un essai et que j'a iabandonné car c'était trop compliqué et je n'avais pas beaucoup de temps.

Sinon, je pense que le Makefile que j'ai fait pourrait être retouché. Et surtout simplifié (j'en ai appris un peu plus sur make entre temps).
Par exemple, il existe une règle fabuleuse:

En clair: ca demande a Make ue pour avoir le fichier truc.o, il faut compiler truc.c.
Cela permettrait d'enlever beaucoup de lignes inutiles au Makefile.

Et aussi:

Cela permet de dire que tout les fichiers .c doivent être compilés en fichier .o pour donner le fichier programme.
Problème: avec Raydium, il y a certains ficiers .c qui ne doivent pas etre compilés directement (ils servent juste a être inclus a partir d'autres fichiers .c).

On s'éloigne un peu du sujet (Windows). Mais j'ai fini.

Peux-tu m'en dire plus sur Subversion : comment cela fonctionne, où peut-on trouver les fichiers en question ?

_________________
Life is Hard, and then you die.

mildred : n'hésite pas à faire une évolution du Makefile, je ne pense pas avoir appliqué de modifs depuis la version actuellement en téléchargement.

benicourt : J'ai du mal à voir le problème avec les variables ... sous Linux (et avec le travail de mildred) chaque fichier est compilé à part des autres. Il est tout à fait possible que je ne comprenne pas le problème, mais en l'état actuel des choses, la construction d'une "lib" Windows me semble possible (cf common.h et son __global). Reste que je n'ai rien contre la répartition des variables dans les différents .h (il faut que ce soit suffisement bien fait pour ne pas engendrer de travail de maintenance supplémentaire [du style déclaration de variables en double]).
Autre point : pas de CVS, mais bientot (blablabla pas encore d'accès internet blablabla) un concurrent 'achement mieux : SVN (Subversion).
WVS est "mort" (seuls les scripts Blender sont encore intéressants là bas), à mon avis.

edit : tu as posté entre temps, benicourt, donc pour te rassurer : la version "publique" de Raydium la plus récente est celle qui est disponible en téléchargement sur le site (30/04/2005 effectivement). Je vais bientot en uploader une autre avec quelques bugfixes (peut être ce soir), sinon.

cool, j'attends la prochaine version.
Je vais tâcher de vous présenter un plan des modifications pour qu'on en discute avant de procéder.

_________________
Life is Hard, and then you die.

J'ai installé la nouvelle version, cela a compilé du premier coup sous windows sans problème. Par contre, j'ai de nouveau un problème avec le son. En fait, dans la précipitation, tu as du oublirt de mettre en place le système suivant :


#ifdef WIN32
#define RAYDIUM_SOUND_NUM_BUFFERS 16
#define RAYDIUM_SOUND_NUM_SOURCES 16
#else
#define RAYDIUM_SOUND_NUM_BUFFERS 30
#define RAYDIUM_SOUND_NUM_SOURCES 30
#endif

Sans cela, le son ne fonctionne pas chez moi. Il faudrait le tester sur d'autres windows, mais 16 est le max pour moi.
A ce sujet, il faudrait peut-être mettre en place un fichier sur ce site permettant d'indiquer des bugs au fur et à mesure, ainsi que des suggestions, et ce qu'il en est du debuggage au jour le jour. Qu'en pensez-vous ?
Combien de personnes travaillent actuellement sur le moteur ?

_________________
Life is Hard, and then you die.

Je pense qu'il est actuellement le seul a travailler dessus, non ?

Sinon, un bugzilla serait très pratique. Facile a mettre en place si on a accès au serveur. Je l'utilise chez moi.
On peut penser que ca fait un peu gros pour pas grand chose mais finalepment c'est pratique.

Ne comptez pas sur moi avant une semaine, je passe mon BAC. Donc ma disponnibilité est fortement réduite.

Bugzilla (ou de préférence des outils plus légers), pourquoi pas en effet. N'oubliez pas que je ne suis pas mieux placé que vous pour mettre en place ces outils.
Concernant OpenAL, le problème n'est une question de précipitation mais d'ignorance : je n'ai jamais eu ce problème de limitation à 16 sources. Après vérification, aucune appli Raydium n'approche de cette limite, je vais donc descendre cette valeur à 16 pour tout le monde.

mildred : merde ! (qu'on dit)

Moi je veux bien aider à mettre en place des trucs sur le serveur, mais j'ai pas les droits d'accès

_________________
Life is Hard, and then you die.

Tout ne doit pas forcément être hébergé sur la même machine Le wiki est hébergé chez Flex par exemple.

I'm back.

Je veux bien héberger un bugzilla sur ma machine (j'en ai déja un). Mais le problème c'est que la connexion n'est en aucun cas garantie.
Surtout que je vais peut être partir quelques jours cet été. Donc les machines dormiront. J'ai mis en place un système de miroir sur un compte free (avec sitecopy) mais ca ne fonctionne que pour des pages statiques (ou presque).

Et je vois mal faire un bugzilla sur un hébergeur gratuit. Et je n'ai pas d'hébergement pro a ma disposition.