Discussion :

[Hibernatus34]

Bonjour,

Je n'ai pas trouvé sur internet de wrapper OpenGL correct pour WinDev, ni de solution pour utiliser les extensions.
J'ai donc créé une petite collection de procédures, dont le code a été généré à 99%. Donc il n'y a pas de risque de faute de frappe, mais ça ne veut pas dire qu'il n'y a pas de bug.
J'ai aussi une solution pour les extensions (une DLL), en revanche je n'ai pas fait de wrapper pour ça, je pense rajouter les fonctions dont j'ai besoin au fur et à mesure.
Je ferai peut-être pareil que pour les fonctions de base un peu plus tard.

Un conseil : le coût des appels de fonctions avec API/AppelDLL32 est grand dans WinDev. Compte tenu de leur quantité pour de l'OpenGL, utilisez un maximum les display lists, VA ou VBO.
Pour afficher une animation fluide, il ne faudra pas utiliser un timer, il vaudra mieux avoir une boucle infinie avec un Multitâche(-1) à l'intérieur, et synchroniser avec l'affichage grâce à wglSwapIntervalEXT (VSync). Sans la VSync, j'ai pu faire du 3000 i/s sur un rendu simpliste dans une petite fenêtre, ce qui est la vitesse normale sur mon poste.

Important : ma solution pour utiliser les extensions ne marche qu'en 32bits, je ferai la version 64bits à l'occasion, mais je n'ai pas de système 64bits pour tester.

Bon dev,

Thomas

[Hibernatus34]

OK, vite fait, un objet simple (petit dodécaèdre étoilé) qui suit la souris et un petit effet visuel en fond, à la manière des players mp3.

[sphynxounet]

Petite question concernant les performances. J'avais développé une classe et toi tu utilises les procédures générales, cela change-t-il quelque chose de passer par l'un ou par l'autre ?

[Hibernatus34]

Bonjour,

Concernant les performances, c'est une question à laquelle il n'est pas facile de répondre, voici un projet permettant d'avoir une petite idée de ce qui est plus rapide comme appel de fonction, mais de toute façon la différence est souvent négligeable. (Normalement, pour que les fonctions soient comparables aux méthodes de classe, je devrais rajouter une structure passée en paramètre.)

Le but premier de ma collection de procédures est de donner accès aux fonction OpenGL et d'apporter une sécurité au niveau des types des paramètres. En gros, faciliter l'utilisation de API().
Pour cela, une classe n'aurait aucun intérêt. (fonctions gl-, glu-, wgl-)

Là où une classe aurait peut-être un intérêt, c'est pour les fonctions qui aident à créer un contexte OpenGL. En effet, on pourrait vouloir une gestion de plusieurs contextes, et donc pourquoi pas un objet par contexte. Mais les fonctions gl- resteraient des procédures globales et on changerait de contexte en appelant une méthode de la classe qui utiliserait wglMakeCurrent.

Rien n'empêche ensuite de développer une couche objet pour simplifier l'usage d'OpenGL selon vos besoin, c'est même conseillé.

[Hibernatus34]

Bonjour,

J'ai fait évoluer un petit peu l'exemple, de manière à montrer comment charger facilement une texture PNG avec l'Alpha. J'utilise GDI+ via .NET, mais il est possible de se passer de .NET en écrivant un wrapper pour GDI+ natif avec une DLL en C++ et des classes WinDev basées sur cette DLL. Je l'ai déjà fait, mais n'ayant pas la propriété du code je ne peux pas le diffuser.
Je montre aussi comment utiliser glDrawArrays quand on ne peut pas utiliser les Display Lists. Au niveau performances c'est pas génial.

[sphynxounet]

Et si on passait une instance d'une structure avec tous les attributs d'OpenGL en paramètre des procédures ?

Le but serait de pouvoir avoir plusieurs instances de la structure (donc éventuellement plusieurs contextes). Le point négatif est qu'il faut définir les attributs de la structure avant donc on doit rajouter une ligne avant chaque appel de procédure ...

[Hibernatus34]

Dans ce cas, c'est des classes qu'il faut faire. Mais il serait vraiment lourd de vérifier qu'on est dans le contexte de l'objet à chaque appel de fonction :
(code approximatif sans gestion d'erreur)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
FONCTION VérifContexte()
nDC est entier système
SI ::g_nContexteEnCours <> :m_nMonContexte ALORS
    wglMakeCurrent(0, 0)
    SI ::g_nContexteEnCours <> 0 ALORS
        SysLibèreDC()
    FIN
    ::g_nContexteEnCours = 0
    nDC = SysRécupèreDC(:m_nHandleFenêtre)
    wglMakeCurrent(nDC, :m_nMonContexte)
    ::g_nContexteEnCours = :m_nMonContexte
FIN

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
FONCTION glMachin()
:VérifContexte()
API(...)

Il vaut mieux appeler explicitement VérifContexte() 1 seule fois avant chaque rendu, et la renommer en "ActiveContexte()" ou quelque chose dans le genre.
Et là on retire toutes les fonctions gl- de la classes, elles restent globales.
En gros la classe sert uniquement à gérer les contextes OpenGL, avec très peu de méthodes.

En faisant du multi-thread on évite de faire ça, car le contexte en cours est local au thread. Mais avec WD je ne pense pas qu'on puisse gérer ça correctement.