[n3xt-D] un moteur pour PureBasic

[tmyke]

[tmyke]

Vacances terminées, moi rentré.

Je me remet au travail, en particulier les histoires de limière et tout ce qui tourne autour.

[Anonyme]

il manque ces constantes pour la création de textures :
(source irrlicht doc)

Enumerator:
ECF_A1R5G5B5 16 bit color format used by the software driver.

It is thus preferred by all other irrlicht engine video drivers. There are 5 bits for every color component, and a single bit is left for alpha information.
ECF_R5G6B5 Standard 16 bit color format.
ECF_R8G8B8 24 bit color, no alpha channel, but 8 bit for red, green and blue.
ECF_A8R8G8B8 Default 32 bit color format. 8 bits are used for every component: red, green, blue and alpha.
ECF_R16F 16 bit floating point format using 16 bits for the red channel.

Floating Point formats. The following formats may only be used for render target textures.
ECF_G16R16F 32 bit floating point format using 16 bits for the red channel and 16 bits for the green channel.
ECF_A16B16G16R16F 64 bit floating point format 16 bits are used for the red, green, blue and alpha channels.
ECF_R32F 32 bit floating point format using 32 bits for the red channel.
ECF_G32R32F 64 bit floating point format using 32 bits for the red channel and 32 bits for the green channel.
ECF_A32B32G32R32F 128 bit floating point format. 32 bits are used for the red, green, blue and alpha channels.
ECF_UNKNOWN Unknown color format:.

[Anonyme]

iCreateTexture() renvois 0.

[tmyke]

il manque ces constantes pour la création de textures :
(source irrlicht doc)

Enumerator:
ECF_A1R5G5B5 16 bit color format used by the software driver.

It is thus preferred by all other irrlicht engine video drivers. There are 5 bits for every color component, and a single bit is left for alpha information.
ECF_R5G6B5 Standard 16 bit color format.
ECF_R8G8B8 24 bit color, no alpha channel, but 8 bit for red, green and blue.
ECF_A8R8G8B8 Default 32 bit color format. 8 bits are used for every component: red, green, blue and alpha.
ECF_R16F 16 bit floating point format using 16 bits for the red channel.

Floating Point formats. The following formats may only be used for render target textures.
ECF_G16R16F 32 bit floating point format using 16 bits for the red channel and 16 bits for the green channel.
ECF_A16B16G16R16F 64 bit floating point format 16 bits are used for the red, green, blue and alpha channels.
ECF_R32F 32 bit floating point format using 32 bits for the red channel.
ECF_G32R32F 64 bit floating point format using 32 bits for the red channel and 32 bits for the green channel.
ECF_A32B32G32R32F 128 bit floating point format. 32 bits are used for the red, green, blue and alpha channels.
ECF_UNKNOWN Unknown color format:.

Les quatres premières sont définis dans N3xtD, et les autres ne sont plus dans Irrlicht 1.5

iCreateTexture() renvois 0.

Exact, il y a un petit bug, j'ai corrigé, je met à jour avant ce soir l'archive.

[tmyke]

Update effectué.

[Progi1984]

Ca, ca sent le retour de vacances :p

[dakota]

je me demande si on peut utiliser les infos iPositionNode ,iTargetCamera,iUpVectorCamera d'une *camera pour aligner par la suite un *objet exactement sur la camera .
Peut être en utilisant sa matrice et en l'appliquant sur l'objet,mais là je suis un peu largué.
J'ai regardé l'aide mais c'est loin d'être claire.
il manque quelques exemples car pour un débutant c'est encore ce qui convient le mieux.
Ceci dit je m'amuse bien

[tmyke]

Tout dépend ce que tu entends par 'aligner'.

Une méthode de base serait tout simplement de récupérer les valeurs de rotation absolues de la
camera (iNodeRotation) et de les appliquer à ton objet. Il aura de ce fait la même attitude que ta camera.
Après, ne connaissant pas la finalité de ton objectif, je ne peux t'en dire plus

il manque quelques exemples car pour un débutant c'est encore ce qui convient le mieux.

heuu, il y a quelques 85 exemples dans le package (volontairement simple) , donc je ne sais pas ce qu'il faut
Alors c'est vrai qu'ils ne couvrent pas tous les cas de figures que peuvent rencontrer les amateurs, mais je ne
sais pas si la plupart des moteurs et autres packages peuvent se venter d'en avoir autant.

Ceci dit je m'amuse bien

C'est en soit le principal

[dakota]

C'est vrai il y a beaucoup d'exemples et c'est bien la premiere fois que je
trouve enfin quelque chose qui m'a l'air "accessible" en 3D .
J'ai expérimenté avec succes et compris les différences entre toutes les fonctions de rotation (iRotateNode,iTurnNode,iTurnAirNode)
Dans mon cas iTurnAirNode me semble parfait pour un avion.
j'ai cependant un petit problème de compréhension pour certaine commande .je pense que ma question vat en faire sourire beaucoup mais chez moi ca ne marche pas car je ne comprend pas la syntaxe et donc plantage.
par exemple pour iRotateNode(*node.INode, x.f, y.f, z.f) ou iScaleNode(*node.INode, x.f, y.f, z.f) pas de probleme .par contre pour retrouver les angles ou l'echelle avec iNodeRotation(*node.INode, *vect.VECTOR3) et iNodeScale(*node.INode, *vect.VECTOR3) je ne sais pas comment recuperer les anles ou l'echelle avec *vect.VECTOR3.
Si j'avais un petit exemple tout bête je pourais l'etudier car il y a beaucoup de fonctions qui utilisent cette notion.
Dans irrlucht il y a une gestion des joystiques avec plus de deux axes ,est-ce prevu pour nextD car dans PB c'est la misere ?.
Bon courrage pour la suite ...

[tmyke]

Tout d'abord, pas de soucis, il n'y a jamais de questions 'bêtes'

Pour ce qui est de la récupération des angles par exemple, c'est plus simple que cela en a l'air.
tu peux écrire plus simplement:

Code : Tout sélectionner

Dim angles.f(2)
iNodeRotation(*node, @angles(0) )

; les angles des 3 axes sont dans angle(0), angle(1) et angle(2), en degrés.

Pour ce qui est de la gestion des joysticks, effectivement, il n'y a pas d'élément dans N3xtD.
En fait, la partie Entré est toujours dévolue à PB, et donc est laissé au langage natif.
Maintenant, dans un avenir plus ou moins proche, rien n'empêche d'intégrer ces fonctions au
sein même de N3xtD.

[dakota]

Merci , ça marche très bien
C'est vrai que là c'est plus simple pour moi.
Pour ce qui est de la gestion des joystiques avec PB c'est impossible avec
plus de deux axes , un comble en 2009 !

[tmyke]

Et, oui PB est très à la traine sur certains truc Je vais voir pour implémenter cela
dans un délais raisonnable.

[Ollivier]

Salut Tmyke,

Je me permets d'oser une suggestion même si je n'ai pas pu télécharger ta bête depuis la page 2 de ce sujet (un comble).

Mais vu les résultats de départ, il faudra bien que je m'y fasse, ça a détrôné Ogre.

Voilà, avec Ogre, il y a un truc qui m'ennuie c'est le retour de fichier LOG. Je trouve beaucoup plus commode que chaque détail trouve sa fonction respective et que l'on aie accès à ces fonctions depuis un programme, plutôt qu'un accès à un fichier ou à une console.

Est-ce qu'il serait possible de marier ces deux (ou trois) retours d'infos? C'est-à-dire de pouvoir choisir par un iSetMachin(#iSysInfoResult) quelconque, le type de retour d'info système souhaité:
1) Un retour dans un fichier LOG
2) Un retour dans la console (qui donnerait lieu à un pipe possible logiquement)
3) Un retour à sous-bibliothèque de fonctions

La 3ème option me semble beaucoup plus pro car tout devient accessible depuis le code en une seule fonction par détail d'information.
Je parle de "mariage" d'infos car il est impensable de demander de changer et donc, indirectement de supprimer des méthodes auxquelles d'autres personnes sont habituées (Je vois que Cpl.Bator, pour ne pas le citer, et d'autres bien sûr sont carrément à l'aise avec ce qui se fait actuellement)

[tmyke]

Il est certain que le système de log sous N3xtD (comme Irrlicht d'ailleurs) n'est pas vraiment différent
de celui de pas d'autre librairies (comme Ogre par exemple).
Avec N3xtD tu as deux possibilités
- une console ou tu as directement les message du moteurs
- un traditionnel fichier log.

Tu peux choisir aucune des deux, ou les deux ou seulement un des deux.

En règle générale, c'est suffisant. Par contre, pour ce qui est du controle de l'application, c'est
effectivement pas toujours top. Et il y a de amélioration à apporter la dessus. Surtout pour des
applications un peu lourdes, ou le debugage prend tout son sens.


PS: petit message perso pour dakota, la gestion des Joystick est implenté dans N3xtD, cela tourne
et donc dispo dès la prochaine mise à jour. (j'ai du acheter un Joy pour faire les test, je n'en avais pas ).