PureBasic

Tout les exemple fonctionne parfaitement. c'est du très bon travail.
je vais jeter un oeil au makefile pour changé le nom.

Comment compte tu faire pour les commandes ?

Icommande
ou
n3xt_commande
n_commande
ncommande

comme Dobro le suggérais, je pensais tout simplement garder les mêmes nom qu'en ce moment
( iCommand ), cela garde une certaine analogie à Irrlicht. A voir, je ne veux plus de préfixe trop lourd, donc si ont change, cela sera nCommand.
A voir ce qui passe le mieux. (a moins qu'une majorité semble preférer autre choses bien sûr)

Par contre, les fichiers C++ seront renomés en n3xt_File par contre je pense à la place
de irrPB_File ...

Cpl.Bator a écrit :Tout les exemple fonctionne parfaitement. c'est du très bon travail.

Merci, dommage qu'il n'y ai pas un amateur MAC pour tester sur cette plateforme . Peut-être sur le forum off .

Ben tiens! Je suis heureux de voir que Cpl.Bator peut faire tourner la bête! On est donc "synchro" quelque soit l'OS désormais!

Personnellement, pour le nom des fonctions, je trouve en effet que le iFonction est super : c'est court, c'est explicite, et, pour ma part, je ne l'utilisais pas ailleurs, donc ça me semble très bien. Maintenant, c'est mon avis personnel...

Ollivier

Salut,

Vu les nouveaux exemples. Surtout le 31, ou il est question des Sahders HLSL .Le 32 avec les mêmes shaders en ASM est pas mal aussi .
Franchement, très bon boulot comme d'hab, car tes exemples prennent en compte DX9 ET OpenGL. GROS avantage d'un moteur multi-plateforme. Pas souvent vu ce genre de chose . Bravo.
Sinon, pour revenir au shaders, bin, c'est encore différent (voir mes autres posts - parfois sur d'autres forums - ), il faut a chaque fois s'adapter, a cause de l'interface moteur-shader qui change. Ici, les fichiers shaders sont plus simples car une plus grande partie du traitement est faite dans l'application principale ( "ProcedureC CallbackShader(*services.IMaterialServices, userData.l)" ) Avantage ou inconvénient? Trop tôt pour le dire Je subbodore ( J'aime ce mot - Entendu la première fois dans Star Wars IV, prononcé par Dark Vador , ya plus de 30ans.. Puiff, je vieillis... ), que l'outil RenderMonkey d'ATI sera un choix plus judicieux pour la conception des shaders ( Contrainement à FXComposer de NVidia ). Je radote, je radote . Je m'y colle et vous tiens a courant.
Longue vie aux combatants...( dit Paul Atréides dans Dune )..oupps à n3xt-D.
A tantôt Morphéus ( re-oops), tmyke ( décidement, la SF... ).

JP

Sinon, RenderMonkey est en effet une bonne alternative. D'ailleurs, si tu code régulièrement avec n3xt-D,
va faire un tour sur le forum officiel de Irrlicht, ou on en parle pas mal, RenderMonkey et shaders associé.

Effectivement, à chaque moteur sa technique de mise en oeuvre des systèmes de shader,
et s'adapter demande toujours un petit temps. Le système d'Irrlicht, comme tout, à ses bons cotés
mais aussi ses mauvais. Comme tu le dis, seul le temps et l'expérience diront si c'est globalement
bien ou pas trop bien. Ceci dit, même si la marge est étroite, on pourra toujours voir
pour améliorer tout cela.

Pour le moment, vue que je me concentre sur le codage du moteur, je laisse de coté le codage des shaders,
mais j'y reviendrais, ne serait-ce pour coder certains effet en natif bien intéressant et vraiment
important d'intégrer dans un moteur moderne...

j'ai un peu fait le tour du moteur.

il manque :

- Gestion basique de la 2D ( tracage de ligne , boite , plot , etc...)
- Shadow map ?

et la GUI ?

Cpl.Bator a écrit :j'ai un peu fait le tour du moteur.

il manque :

- Gestion basique de la 2D ( tracage de ligne , boite , plot , etc...)
- Shadow map ?

Progi1984 a écrit :et la GUI ?

Houlà, pas si vite les amis. Je sais que vous êtes impatients

Comme je l'ai souligné, je n'en suis qu'au début. Donc pour le moment les mesh statiques et ce qui tourne autour.
Vont venir en suite, les mesh animés, certains effets (shadows), la physique,
les fonction GUI, la 2D, Octree, etc.. Ce qui nous amènera a vue de pif cet été (une estimation hein ).

Donc plein de boulot et quelque 1500 fonction soit à coder ou à plus simplement à wrapper.

ha oui , il existe le système d'occlusion portal dans irrlicht ?

Cpl.Bator a écrit :ha oui , il existe le système d'occlusion portal dans irrlicht ?

Non, pas pour le moment, mais cela devrait être intégré dans la prochaine version. Mais cela a déjà été codé
en externe par des amateurs, basé sur des shaders.

les portals n'on rien à voir avec les shaders , c'est comme si tu me disait que les octrees sont gerer via un shader , ou alors j'ai rien compris.


imagine une map de se genre :



on a pas besoin de voir toutes les pièces. le "mappeur" créer des blocs ( portal ) de la tailles des pièces , le moteur , ensuite suivant la dispositions des blocs "portal" sait , si tel ou tel pièce est visible.

Cpl.Bator a écrit :j'ai un peu fait le tour du moteur.

il manque :

- Gestion basique de la 2D ( tracage de ligne , boite , plot , etc...)
- Shadow map ?

et la ligne en 3D n'oublie pas mon petit golo3D

une truc genre x,y,z to x2,y2,z2

bien sur taille x,y,z qui va avec .... pour Noel prochain ?

pour faire des ligne de taille diferente , larg, long, haut
donc des murs

Cpl.Bator a écrit :les portals n'on rien à voir avec les shaders ...

Tu as parfaitement raison, j'ai répondu trop vite, pensant que tu parlais d'Ambient Occlusion.
Pour répondre plus précisément à ta question, il existe quelques codes sous Irrlicht qui semble bien
fonctionner, il a été demandé d'intégrer la chose dans la version 1.6 d'Irrlicht (on en est à la version
1.5), à voir si cela sera fait. Sinon, rien n'empêchera de la coder en externe sinon.

Dobro a écrit : et la ligne en 3D n'oublie pas mon petit golo3D

une truc genre x,y,z to x2,y2,z2

bien sur taille x,y,z qui va avec .... pour Noel prochain ?

pour faire des ligne de taille diferente , larg, long, haut
donc des murs

Les lignes 3D, en ligne simple pour le moment il existe une instruction pour
cela, même si tu ne peux pas regler l'épaisseur (iDrawLine3D() ).
Pour aller plus loin, tu peux passer par les 'bolt' (sample028) ou tu pourras définir de façon plus
fun les lignes à tracer. Certainement moins simple d'utilisation, mais aux rendu qui peuvent être bien sympa

ok je regarderai ça merci

j'ai encore le nez dans mon prg pour le moment

Dobro a écrit :ok je regarderai ça merci

j'ai encore le nez dans mon prg pour le moment

je suis également très occupé, mais j'ai pris le temps de tester, et c'est bien beau !

Le sample 41 pose problème: invalid memory access( read error at address 1024862270)