Raydium 3D Game Engine

Lorsque j'aurais réussi à compiler raydium, jaurrais besoin de savoir comment l'utiliser et je trouve que la doc est un peu faible ...
Il serait bien alors de définir un format de docstring dans le code source. Même si dans un premier temps, on ne génère pas la doc, ca peut être très intéressant.

Je pense que le format de docstring doit être simple. Pas d'indentation devant chaque ligne (principalement car j'utilise KWrite qui ne permet pas a ma conaissance des commentaires /* */ compliqués). je propose le format suivant:


C'est pas très compliqué ...
A mon avis, pas besoin de plus: le texte seul suffit à mon avis pour documenter le symbole (fonction, variable, structure)

En fait, j'aimmerais a partir des tutoriaux et de la doc du Wiki mettre ces informations dans le code source pour mieux apréhender raydium.

A mon avis, ces informations devraient être en francais, cest plus simple ... Rien n'empêche après de traduire en anglais.

Mildred qui devrait dormir.

PS: ou peut on trouver une liste exhaustive des fonctionnalités de raydium ? (est il possible de faire une étendue d'eau où on peut nager ?)
PPS: j'aimmerais bien faire une api python car même si j'aprécie php, je trouve ce language un peu limité (au niveau des erreurs notament. si l'erreur provient d'une fonction, on ne sait pas quel code a appelé cette fonction)
PPPS: je stoppe la le HS.[/code]

A propos de la doc : Au travers du "API Reference guide", elle est (je pense) correcte et précise, mais tout à fait incomplète. L'ensemble des domaines avancés (physique, réseau, parsing, particules, scripting, ...) ne sont pas couvert, mais j'ai bien l'intention de combler le vide (et c'est d'ailleurs ce qui se passe petit à petit). Reste qu'elle est destinée à des gens qui connaissent déjà les concepts de Raydium. L'autre pièce manquante de la doc est le "Developer's guide", et j'ai la franche impression que les tutoriaux jouent ce rôle à merveille (reste à les terminer, et à les traduire).
Si quelqu'un souhaitait appréhender Raydium maintenant, je lui conseillerais de bien se faire les dents sur les tutoriaux de facon à bien comprendre la logique de Raydium (logique des noms de fonctions, logique des correspondances "id"-"nom", logique du déroulement du code). C'est l'affaire de quelques heures, tout au plus. Etant donné que tout le reste se passe au travers de la physique (qu'on l'utilise ou non), l'étape suivante est de comprendre les principes de base des moteurs physiques, et là encore, c'est une chose simple au travers du tutoriel, éventuellement précédé d'un article de vulgarisation (pub, mais : http://www.nofrag.com/2004/oct/23/14529/ ) ... puis reste à mettre le nez dans ode.c pour les trucs "avancés" (y'a moyen de faire beaucoup de choses sans ça )
Pour reprendre ton exemple de l'eau, la physique te permet virtuellement tout, mais tout dépend de te besoin (quel niveau de modélisation, que signifie "nager", etc).

Reste que la doc n'est pas complète, c'est un fait, et j'y travaille (et si ça vous intéresse de donner un coup de main, c'est avec plaisir). Après, wiki ou doc intégrée au sources ... j'ai du mal à peser le pour et le contre.

Ah ! sinon PHP se debug très bien, rassure toi http://php.planetmirror.com/manual/en/ref.apd.php

En fait, c'est simple: je cherche la correspondance d'un concept que j'au connu avec UnrealEngine (WheelOfTime): les zones.
Il suffisait d'ajouter un objet virtuel qu'on apelle "zone" dans un espace fermé pour que les paramètres de cette zone soient déployés sur toute la zone ... Par exemple, on ajoutait un WaterZone dans un trou au sol. Entre le trou et au dessus, on mettait un plan qui représente la surface de leau et lorsque le personnage entre dans l'eau: il passe en mode nage (il y a aussi un petit bruit deau lorsqu'on entre dans l'eau ...)



A mon avis, ce serait intéressant de mettre la documentation dans les sources pour la simple et bonne raison que ce serait plus facile de créer cette documentation. Lorsqu'on crée une nouvelle fonction par exemple on peut directement ajouter la documentation (rien que dire quels sont les paramètres en entrée, ce que la fonction retourne et ce quelle fait).
C'est plus simple que d'aller voir sur le wiki en même temps et de mettre la doc de la fonction créée.
J'avais aussi pensé à autre chose mais j'ai oublié.


Oui, c'est bien (merci, conaissait pas). Mais en fait, ce qui me gêne le plus c'est que dans une fonction il n'y a pas moyen de connaître quel est le fichier et la ligne qui a appelé la fonction. Ce serait très pratique pour soulever des erreurs (trigger_error).

Mildred

Raydium est bien plus généraliste que ça Il ne prendra pas la responsabilité de jouer un son à ta place, par exemple.

Par contre, rien ne t'empêche de coder toi même ces comportements, avec toutes les nuances que tu souhaites. Une des idées possibles, par exemple, serait d'utiliser une geom statique (boite, probablement) et de surveiller les collisions entre ton/tes perso(s) et cette boite. A toi de programmer le comportement dans l'eau, aussi (probablement avec, entre autre, une gravité de zero, par exemple).


J'utilise assez régulièrement Doxygen au boulot, et franchement je ne suis pas convaincu de l'intérêt pour Raydium.
D'un, la sortie est très basique, confuse, le code source est surchargé de \fn, \param qui rallongent d'autant le code source, et on se retrouve à maintenir deux choses différentes au même endroit.
Ensuite, en pratique, on code son algo et/ou son bloc de 10 fonctions (parce qu'on a la tête dedans), et on revient seulement après pour documenter (note : j'ai bien parlé de documentation, pas de commentaires).
Pourquoi ne pas plutot se rendre sur le Wiki, autrement plus convivial à la saisie et surtout à la lecture, pour réaliser cette tâche ? documentation toujours à jour, pour tout le monde.
Ce que j'essaye de dire, ça n'est pas que ces systèmes ne sont pas intéressants (au contraire, et sinon je ne m'en servirait pas pour mes dev ), mais plutôt qu'il ne sont pas forcéments si adaptés que ça pour produire une doc destinée à un utilisateur "final" de l'API, mais plus (à mon avis) pour produire de l'information à destination des autres développeurs du projet.
En résumé je ne sais pas ... peut être même que les deux solutions sont complémentaires.


Même si je n'ai jamais essayé, APD doit être capable de d'envoyer toutes ces infos au travers de apd_callstack().
Mais rien ne t'empêche d'implémenter un module Python, encore une fois

Bien sur, je n'attends pas cela de raydium ...

L'idée de la boîte est pas mal mais cela comporte aussi quelques inconvénients par rapport à la détection d'un espace fermé. C'est sans doute plus facile à faire ausi.
Je pense que cette fonctionnalité (les zones qui permettent au programmeur de surveiller les entrées/sorties de ces zones) peuvent être intégrées dans raydium.
Mais il faut voir. Mais a mon avis, ce serait une fonctionnalité intéressante et un moyen simple de gérer des choses comme l'eau (ou d'autres choses pas forcément aussi évidentes).

Je vais déja essayer de compîler raydium, ensuite, je chercherais comment faire ...


Peut être pas aussi compliqué que doxygen. Un système plus simple comme j'ai proposé serait peut être mieux.
Ou même, simplement mettre eds commentaires lorsqu'on développe une fonction.

Bien sur, mais pour la documentation des fonctions c'est amha plus pratique pour le développeur de le mettre dans le code source.
Je ne parle pas d'une grosse documentation: juste une ou deux lignes ...
Le Wiki c'est bien mais je crois que pour beaucoup de fonctions ces une ou eux lignes sont inexistantes alors c'est pas très simple.

Bien sur. A mon avis, cela ne peut servir que pour documenter l'API mais c'est quand même pratique d'avoir des commentaires dans le code source pour savoir un minimum ce que fait une fonction plutot que rien du tout.

Mildred