Raydium 3D Game Engine

Bon, j'ai intégré tout ce qu'il fallait pour le tutorial 3 sur ODE, mais lorsque je teste, cela me donne ça :

Raydium: Object: loading "cocorobix.tri", version 1
Raydium: Texture num 1 (ground.tga) loaded: 256x256, 3 bpp (b0 lm0)
Raydium: Texture num 2 (t_circuit-2f.tga) loaded: 2048x1024, 3 bpp (b0 lm0)
Raydium: ODE: Error: cannot set object internal colliding flag: invalid name or
index
Raydium: ODE: Error: Cannot delete object: invalid name or index
Raydium: Object: loading "clio.tri", version 1
Raydium: Texture num 3 (car00.tga) loaded: 256x256, 4 bpp (b0 lm0)
Raydium: Texture num 4 (vitre.tga) loaded: 8x8, 4 bpp (b1 lm0)

L'erreur est provoquée par les lignes suivantes :

raydium_ode_object_box_add("corps",a,1,1.2,0.6,0.4,RAYDIUM_ODE_STANDARD,0,"clio.tri");

Se peut-il que mon clio.tri ne soit pas le bon ?
Il fait 1 310 591 octets

VOyez-vous d'où cela peut-il venir ?

La dernière erreur est "volontaire", puisque le tutoriel tente d'effacer l'ancienne voiture (si elle existe) avant de créer la nouvelle. En revanche, la première est anormale.

Vérifie que tu disposes bien de "raydium_ode_object_create("GLOBAL");" dans la fonction "raydium_ode_init" (fichier ode.c, ligne 194 ou pas loin). Vérifie aussi que cette dernière fonction (raydium_ode_init) est bien lancée elle aussi (dans init.c). C'est une piste avec le peu d'infos dont je dispose
Il se passe quoi dans l'appli ?

Cool, merci Xfennec
J'avais effectivement oublié de positionné l'ODE_SUPPORT, donc dans init.c, cela n'appelait pas ode_init...
Là, je vois le paysage, vue de la voiture semble t-il, mais pas possible de bouger. Normalement, cela fonctionne à la souris et au clavier, non ?
Je vais voir si le support mouse est bien implémenté de mon coté. Si vous avez une idée, elle est la bienvenue.
Au fait, une fois tous les problèmes résolus, je peux faire un petit guide d'install avec les principales libs si vous voulez (en version windows + visual studio 2003) ?

ça y est, j'étais trop pressé. Je viens d'intégrer les timecall et cela passe. J'ai pas accès à la souris, mais le clavier, oui. Je continue l'intégration.

Quelques soucis avec les sons et musiques.

COmmençons par les sons. Si j'indique dans main.c les lignes suivantes :

int moteur=raydium_sound_LoadWav("murcielago.wav");
raydium_sound_SourcePlay(moteur);

J'obtiens le résultat suivant :
----------------------------------------------------
Raydium: Using Raydium 0.640
Raydium: command line args: OK
Raydium: Requesting 640x480:32 mode
Raydium: Got 640x480:32 mode
Raydium: using RADEON 9200SE DDR x86/SSE2, from ATI Technologies Inc. (version
.3.4955 WinXP Release)
Raydium: Signal Handler: OK
Raydium: Platform "4xfloat" vector size is: 16 byte(s) long
Raydium: OpenGL implementation maximum texture size: 2048x2048
Raydium: OpenGL hardware providing 6 texture unit(s)
Raydium: vertex arrays memory: OK
Raydium: keyboard: OK
Raydium: mouse: OK
Raydium: sound: Buffer creation successfull
Raydium: sound: OK
Raydium: atexit functions: OK
Raydium: lights: OK
Raydium: objects: OK
Raydium: network: OK
Raydium: timecall: win32 modulo every 19.98 minutes, modulodiv is 2^0
Raydium: timer: detection: 53 iterations: diff: 4 steps (3579545/sec)
Raydium: timecall: method accuracy = 0.001 ms (894886.25 Hz)
Raydium: timecall: Using basic gettimeofday() method
Raydium: timecall: OK (894886 Hz)
Raydium: timecall: softcall 0: 1 Hz (3579545 clocks interval)
Raydium: Raydium engine reseted to original state
Raydium: timecall: callback 1: 400 Hz (8948 clocks interval)
Raydium: physics: ODE Net: 10 element(s)/packet
Raydium: physics: OK
Raydium: Engine is now ready.
-----------------------------------------------------------
Raydium: Object: loading "cocorobix.tri", version 1
Raydium: Texture num 1 (ground.tga) loaded: 256x256, 3 bpp (b0 lm0)
Raydium: Texture num 2 (t_circuit-2f.tga) loaded: 2048x1024, 3 bpp (b0 lm0)
Raydium: ODE: Error: Cannot delete object: invalid name or index
Raydium: Object: loading "clio.tri", version 1
Raydium: Texture num 3 (car00.tga) loaded: 256x256, 4 bpp (b0 lm0)
Raydium: Texture num 4 (vitre.tga) loaded: 8x8, 4 bpp (b1 lm0)
Raydium: Object: loading "roue5.tri", version 1
Raydium: sound: ERROR : setting source pitch :40961
Raydium: sound: ERROR : setting source gain :40961
Raydium: sound: ERROR : setting source reference distance :40961
Raydium: sound: ERROR : setting source position :40961
Raydium: sound: ERROR : setting source velocity :40961
Raydium: sound: ERROR : attaching source to buffer :40961
Raydium: sound: ERROR : setting source loop state :40961
Raydium: sound: ERROR : setting listener position :40961
Raydium: Object: creating display list for object cocorobix.tri
Raydium: Object: creating display list for object clio.tri
Raydium: Object: creating display list for object roue5.tri

J'ai oublié quelque-chose ?

De plus, coté musique, si j'indique :

raydium_sound_load_music("Tetris.ogg");

J'obtiens :
Raydium: Using Raydium 0.640
Raydium: command line args: OK
Raydium: Requesting 640x480:32 mode
Raydium: Got 640x480:32 mode
Raydium: using RADEON 9200SE DDR x86/SSE2, from ATI Technologies Inc. (version 1
.3.4955 WinXP Release)
Raydium: Signal Handler: OK
Raydium: Platform "4xfloat" vector size is: 16 byte(s) long
Raydium: OpenGL implementation maximum texture size: 2048x2048
Raydium: OpenGL hardware providing 6 texture unit(s)
Raydium: vertex arrays memory: OK
Raydium: keyboard: OK
Raydium: mouse: OK
Raydium: sound: Buffer creation successfull
Raydium: sound: OK
Raydium: atexit functions: OK
Raydium: lights: OK
Raydium: objects: OK
Raydium: network: OK
Raydium: timecall: win32 modulo every 19.98 minutes, modulodiv is 2^0
Raydium: timer: detection: 53 iterations: diff: 4 steps (3579545/sec)
Raydium: timecall: method accuracy = 0.001 ms (894886.25 Hz)
Raydium: timecall: Using basic gettimeofday() method
Raydium: timecall: OK (894886 Hz)
Raydium: timecall: softcall 0: 1 Hz (3579545 clocks interval)
Raydium: Raydium engine reseted to original state
Raydium: timecall: callback 1: 400 Hz (8948 clocks interval)
Raydium: physics: ODE Net: 10 element(s)/packet
Raydium: physics: OK
Raydium: Engine is now ready.
-----------------------------------------------------------
Et là plantage !
Vous savez d'où ça vient ?
J'ai utilisé OpenAL v1.0 SDK - ça compile nickel pourtant.

Juste pour info tout de même, il y a une fonction que j'ai été obligé de couper pour l'instant :

int raydium_sound_Array3IsValid(ALfloat *a)
{
/* if( !raydium_trigo_isfloat(a[0]) ||
!raydium_trigo_isfloat(a[1]) ||
!raydium_trigo_isfloat(a[2]) )
{
raydium_log("sound : ERROR: invalid 3xALfloat array provided");
return 0;
} GREG */
return 1;
}

En fait, j'ai bien trouvé isNan pour Windows, mais j'ai pas réussi à trouver isInf. ça peut jouer ici ?

Non, je pense qu'OpenAL n'est pas (complétement) initialisé. Difficile de voir pourquoi à permière vue. Regarde du coté de l'initialisation si tu rencontre quelque chose de spécial, je vais fouiller de mon coté pour voir si certaines écritures sont "dangereuses" pour VC++.

Bon, je pense avoir suffisament bidouillé maintenant pour envisager le travail suivant :

1) Réaliser une compilation du code de Raydium avec Visual Studio et une petite doc pour aider d'autres utilisateurs à faire de même. Pour le PHP, je ne promets rien, mais je vais essayer de laisser Raydium tel quel en ajoutant quelques #ifdef pour visual studio puisque certaines libs n'existent pas telles quelles et qu'il faut faire quelques modifs mineures.

2) Créer lib, dll et .h pour une intégration plus facile des objets

Et après une petite réflexion, peut-être :
3) Réaliser une surcouche C++ pour ceux qui souhaite comme moi utiliser raydium sous forme objet. D'ailleurs, ce n'est pas très difficile car le code, même s'il est en C, utilise déjà cette philosophie, donc c'est juste pour ne pas avoir de variables globales et être encore un petit peu plus simple. Mais je ne sais pas si j'irais jusque là.

Qu'en pensez-vous ?

Ensuite, le moteur est tellement génial que ça donne envie de lui ajouter de nombreuses autres fonctions, nottamment coté dynamique. Pour ma part, mes compétences se situent surtout coté Algorithmes génétiques, réseaux neuronaux et systèmes experts. Y-a peut-être moyen d'en mettre un peu pour l'intelligence des bots par exemple. Mon objectif n'est pas le jeu, mais cela s'en approche tellement que je crois qu'il y a moyen de naviguer ensemble quelques temps. En tout cas, il faut garder la même philosophie : souplesse, efficacité et simplicité.

bonjour bonjour!
bon, c'est rare de me voir dans cette section, parceque je n'y connais rien du tout et que je comprends pas du tout ce que vous y racontez, mais le post juste au dessus de béni me fais penser (dis je une grosse betise?) que nous auront besoin a plus ou moins court terme de 'quelque chose' qui permette l'animation d'objets dans raydium non?
pour le moment si j'ai bien compris, toutes nos parties mobiles sont gérées par la physique.
ce serait quand meme pas mal de pouvoir avoir des objets créés directement avec des parties mobiles (squelettes etc...) et de pouvoir s'en servir comme ça sans avoir recour a la physique, tres gourmande...

mon post est il a sa place ou me suis je fourvoyé? est ma gueule de bois de ce matin qui m'a poussé a écrire ça? qui suis je finalement?...

_________________
bouffe la rouille et mort aux cons

Suite du thread ici : http://memak.cqfd-corp.org/viewtopic.php?t=239

neub : Même si ça n'est effectivement pas le sujet du thread, tu as raison pour le problème de l'animation, puisqu'elle n'est pas supportée autrement qu'avec la physique. Le sujet a déjà pas mal discuté, et la conclusion était que l'implémentation des squelettes dans Raydium demandait la ré-écriture du coeur de rendu de Raydium (qui n'a pas été prévu dès le début pour cette situation) , un nouveau format de .tri, adapté à ce nouveau moteur de rendu et au stockage des informations sur le squelette du modèle, ainsi que que son animation. Implicitement, des outils sont aussi a ré-écrire : scripts pythons pour Blender (et quelques scripts PHP), raydium_modler, mania2, et quelques autres.
Bref, c'est prévu, mais vu l'ampleur du boulot que ça demande, ça n'a jamais encore été placé dans les priorités du projet.

Mais rien n'empêche de faire plusieurs versions de fichiers .tri ... non ?
C'est dailleurs déja le cas, il me semble.

Sinon, peut être y a-t-il d'autres possibilités que les squelêtes ... Qui demanderaient moins de lignes de code.