Bonsoir à tous,

Je cherche à utiliser la version 1.8 d'Irrlicht, elle m'intéresse pour plusieurs points indiqués sur la liste des modifications.

Je viens de pas mal me balader sur le forum d'Irrlicht (http://irrlicht.sourceforge.net/) et je ne trouve rien de vraiment similaire à mon problème.
En résumé, ça crash dès le début de l'application alors que je n'ai aucun problème avec la version 1.7.2.

Apparemment, d'autres personnes ont des problèmes de crash.

Le code qui fonctionne en 1.7.2:

SIrrlichtCreationParameters parameters;         // Paramètres d'initialisation vidéo pour Irrlicht.

    parameters.AntiAlias = 16;                      // option: Anti-aliasing ou non.
    parameters.Bits = 16;
    parameters.DriverType = EDT_OPENGL;             // Choix du driver OpenGL ou DirectX.
    parameters.Fullscreen = false;                  // option: pleine écran ou non.
    parameters.HighPrecisionFPU = false;
    parameters.Stencilbuffer = true;
    parameters.Vsync = true;                        // option: synchronisation verticale ou non.
    parameters.WindowId = windowsID;                // Identifiant de la fenêtre.
    parameters.WindowSize = dimension2d<u32>(width,height);

    m_device = createDeviceEx(parameters);          // Création du device.
    if( m_device == 0 ){
        m_info += "Création du driver 3D Irrlicht: Erreur.\n";
        return;}
    else
        m_info += "Création du driver 3D Irrlicht: OK.\n";

    IVideoDriver* driver = m_device->getVideoDriver();

    // Verifie le support des shaders
    bool pixel_shader_support = ( driver->queryFeature ( EVDF_PIXEL_SHADER_1_1 ) || driver->queryFeature ( EVDF_ARB_FRAGMENT_PROGRAM_1 ) );
    bool vertex_shader_support = ( driver->queryFeature ( EVDF_VERTEX_SHADER_1_1 ) || driver->queryFeature ( EVDF_ARB_VERTEX_PROGRAM_1 ) );

Le plantage se fait sur la fonction "queryFeature".
Si je commente ces fonctions, le plantage se fait sur une autre fonction, ça donne vraiment l'impression que le pointeur du "device" n'est pas bon ou non utilisable.

Est-ce que quelqu'un à le même genre de problème ? Avez-vous testé la nouvelle version ?
          Merci.

Dernière modification par Gehogor (18-11-2012 19:49:35)

Ta regardé si ton pointeur m_device est null ?
Je peux avoir le code complet ou un code minimal ?

Dernière modification par OzVessalius (18-11-2012 19:36:45)

Merci pour ta réponse rapide, mais oui, il y une vérification, je viens de compléter le code pour qu'il n'y ait plus de confusion à l'avenir.
J'ai déjà testé en mode debug et mon pointeur est non nul.
Sinon, mettre plus de code serait difficile, trop gros.

Ce qui serait bien, c'est qu'il y ait des gens qui testent la 1.8, me donne leur config et me disent, "moi, pas de problème de mon coté" ou pas d'ailleurs !
    Merci encore.

Dernière modification par Gehogor (18-11-2012 20:21:04)

Bah, actuellement, j'ai testé la 1.8, je suis sous Ubuntu 12.04, mais, j'utilise pas CreateDeviceEx mais CreateDevice.
Donc, d'après ce que j'ai testé, CreateDevice marche nickel avec ton code (en adaptant).
Je suppose que ça doit survenir au niveau du Handle, tu es sous Windows ou Linux ?
Ta tenté au débugger d'isoler le problème ?
Backtrace ?

Ok, j'ai également testé avec un simple createDevice, sans handle et ça plante aussi.
Si je teste la version 1.7.2 avec un simple createDevice, j'ai une nouvelle fenêtre Irrlicht qui s'affiche, exactement comme ça doit se passer.

Je me demande si ce n'est pas pas la version compilé qui est foireuse.
Je suis sous windows 7, avec Gcc (MinGW x86 32bit). La précompilation se fait avec CMake.

Juste un truc comme ça mais une autre personne avait eu un probleme en utilisant "EVDF_PIXEL_SHADER_1_1". Apparement le minimum serait "EVDF_PIXEL_SHADER_2_0" car le PS et VS 1.1 serait propre à DX8. Je pense que tu devrait remplacer tout les "EVDF_PIXEL_SHADER_1_1" par des "EVDF_PIXEL_SHADER_2_0" même si techniquement le 1.1 suffit. Bien sûr, fais le aussi pour les vertex shader.

Tu l'as compilé ou tu as utilisé les binaires fournis ?
Si tu as utilisés les binaires fournis, il se peut que ça soit à cause de ça, tente de compiler toi-même.

- Merci johnplayer,
Dans la suite du code (qui n'est pas affiché), je fais également le teste avec EVDF_PIXEL_SHADER_2_0 et EVDF_VERTEX_SHADER_2_0. De toute façon, une fois le problème du crash résolu, je reviendrai vers vous pour essayer d'améliorer le visuel globale de l'application, avec une bonne gestion des shaders, car je suis plutôt nul dans ce domaine...

- OzVessalius,
Je récupère les binaires fournis comme d'habitude, mais là je crois que je vais devoir la recompiler...

Dernière modification par Gehogor (18-11-2012 20:43:57)

Moi c'est pareil, les shaders me donne du fil à retordre. C'est assez tendu à cause des transformations à faire avec les matrices, j'ai un peut de mal à savoir quelle matrice fais quoi. Dans Irrlicht je m'en sors, je change de repère facilement avec avec driver->setTransform() mais dans les GLSL je patauge un peu. En tout cas, préviens si ça a résolu ton problème.

J'ai fait un package avec Irrlicht 1.8 compilé en "debug" et "release accurate math" avec DirectX9 et un projet exemple pour code block.
Voilà le lien : lien

Ok, merci, je télécharge, je teste, là je recompile pour tester "le teste des shaders 1.1" en moins, on ne sais jamais !
Après, je re-teste avec les nouveaux binaires.

--> Et donc le bilan:
Quand je désactive complètement l'utilisation des shaders, ça crash.
Quand j'utilise les binaires de jonhplayer (merci d'ailleurs !!), ça crash.

Quoi qu'il arrive, en mode debug, ça plante sur le "createDeviceEx" en EDT_OPENGL,EDT_DIRECT3D9 et EDT_SOFTWARE.
Par contre, avec le "createDevice", sans gestion des shaders, l'application plante sur:

m_cameraFPS = m_device->getSceneManager()->addCameraSceneNode();

Ce qui revient à dire la suite du code.

Conclusion, dès que j'utilise le device généré par createDevice, qui est, je le rappelle, non NULL, ça plante.
Là, je crois que ma DLL (mes DLLs, si je prends celle de jonhplayer) ne va pas.

--> Sinon, johnplayer, pour les exemples que tu m'as filé, ils démarrent sans problème mais le viewport ne m'affiche que du rose saumon.

Dernière modification par Gehogor (18-11-2012 21:39:01)

Normal pour l'écran rose saumon! Ce n'est qu'un projet de base et dans beginscene j'ai mis une couleur au hasard.
Par contre, j'ai une remarque qui ne résoudra rien mais bon : parameters.Bits mets-le à 32 car 16bits=65356 couleurs c'est pas top.^^

Je suppose que tu recupères le WinID du QWidget, c'est bizarre je suis passé à irrlicht 1.8 et je n'ai eu un aucun changement à faire, Qt et Irrlicht s'accordent sans problème. Et tu sûr que ton windowsID est bon? Et c'est vrai que le problème semble venir de device mais le test que tu fais, affiche que c'est OK? Peut-être devrais-tu tester "m_device->getSceneManager()" au cas où.

visiblement getVideoDriver fonctionne, donc ça viens du driver, donc il aurait fallu faire un watch du pointer a l'executtion, et il y a de forte chance qu'il soit null, selon ce que tu mentionne
donc l'initialisation d'opengl fails, en utilisant un driver <<software>> esque ça marche ?

si je ne m'abuse evite parameters.Bits = 16, en rêgle général ça n'apport pas d'optimisation, de plus la création du driver peut fails dans le cas ou la valeur que tu rentre est inferieur a la valeur que ton os utilise
soit 24 le plus souvent, sa ce produisait sur les vielles version d'irrlicht

parameters.Vsync = true; boff la vsynch diminue les performances
je fonctionne sur la 1.8svn pas de soucis a reporter (slackware64) a par des mem-leak sur string<T> et array<T>,
j'utilise des paramêtre plus ou moin similaire, essaye de recompiler maison

L'initialisation du driver avec <<software>> ne fonctionne pas non plus.

Pour l'option "parameters.Vsync = true;", c'est historique, je voulais avoir un traitement de la boucle d'évènement stable (60 Hz) pour des calculs de vitesses et d'accélérations. Aujourd'hui, tout est fait ailleurs et indépendamment, donc je le désactive. Merci pour cette petite remarque.

Je testerai  parameters.Bits = 24 au lieu de  parameters.Bits = 16.
Si tu utilises la version du SVN et que tu n'as pas de problème, ça renforce mon idée que j'ai un petit soucis.

J'ai recompilé et tester plusieurs configurations, ça crash toujours autant, n'ayant pas le temps, je vais rester sur la 1.7.2 en attendant. Je retenterai dès que possible. Merci à tous pour votre aide.

Bonsoir à tous, et bien voilà, je reviens vers vous car j'ai des indications sur mon crash au démarrage de l'application VEM en version 1.8.

J'ai mis un de mes potes sur le problème car je devais passer sur 1.8 pour un bug sur la fonction "getRotationDegrees" de la classe "CMatrix4" (singularité pas correctement gérée et corrigée sur la 1.8) et je ne trouvais pas l'erreur dans le code. Et pour cause, l'erreur n'y était pas !

Lorsqu'on compile en cross-compilation pour windows avec Linux, la DLL générée plante directement (pourquoi, bug dans le compilo peut être... hyper peu probable mais bon...), je pense que les créateurs d'Irrlicht la compile de cette manière, c'est très pratique.

Par contre, si on compile sur windows, il faut déjà corriger le makefile qui ne fonctionne pas directement (problème pour le compilo pour trouver les "sous lib" dans les sous-dossiers comme la zLib par exemple) et après on obtient les fichiers *.a et *.dll fonctionnels.

          Si des personnes ont rencontré le problème, je pourrai normalement dépanner. Mais j'ai l'impression que je suis seul...

Dernière modification par Gehogor (23-04-2013 20:50:32)

Salut Gehogor, j'ai eu des soucis similaire avec une version de GCC, je suis passé sur une autre version et pouf plus de crash au démarrage.
Peut-être qu'une partie de ton soucis se situ par là aussi.
En tout cas, merci pour le retour ça sert toujours.

Ok, je note. Je ferai l'essai avec un autre version... Merci pour l'info.