Discussion :

[victor_gasgas]

Bonjour à tous!

Je viens solliciter votre avis sur la conception et le design d'un ensemble de classes, dans le but d'uniformiser l'utilisation d'APIs (DirectX et OpenGL, mais ça pourrait être autre chose).

Ci-dessous mes contraintes:
- Le choix de l'API est déterminé par à la compilation (et je pense que cela va jouer un grand rôle pour la suite!).
- La possibilité d'utiliser boost et c++11
- Les classes représentant une ressource côté GPU (typiquement texture, shader, framebuffer, etc), ne contiennent pas les opérations de traitement. En effet, elles se trouvent dans un autre ensemble de classes!

Donc on tombe sur le code suivant pour les ressources GPU, et les classes de traitements:

Code :

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

1
2
3
4
5
6
7
struct shader {};
struct shader_ogl : public shader {};
struct shader_dx : public shader {};
 
struct renderer {};
struct renderer_ogl : public renderer {};
struct renderer_dx : public renderer {};

Cela concerne la gestion des APIs, mais par ailleurs dans le code j'ai par exemple une classe material, qui contient un shader, et se moque de savoir quelle API est utilisée.

Code :

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

1
2
3
4
5
class material
{
    // Par exemple
    void addShader(const std::shared_ptr<shader> &s);
};

Donc naturellement je pensais me dirigé vers un double-dispatch, seulement voila:
- Ne perd t-il quelque peu de son intérêt du fait que l'API est choisit à la compilation
- D'après un article d'Emmanuel Deloget http://blog.emmanueldeloget.com/inde...comme-visiteur, il ne respecte pas l'OCP, et en cas de grosse hiérarchie, ça peut vite devenir compliqué.

Dans un contexte très similaire, sur un article de Laurent Gomilla http://loulou.developpez.com/tutorie.../partie8/#L4.3, ce dernier reçois dans ses renderer spécialisé des shader, auquel il applique un static_cast vers la bonne classe dérivée comme il est "sûr" de ce qu'il va recevoir.

Code :

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

1
2
3
4
5
6
void COGLRenderer::SetVertexShader(const IShaderBase* Shader)
{
    const COGLShader* OGLShader = static_cast<const COGLShader*>(Shader);
 
    // Traitement ...
}

Je me tourne donc vers vous pour connaître votre avis sur le choix de conception à employer (surtout que je connais l'API utilisé à la compilation!)!

Merci d'avance!

[Flob90]

Bonjour,

Il y a du code en commun entre les classes pour les différentes API ?

Comment exactement détermine tu l'api à la compilation ?

Tu as essayé une solution à base de template et de spécialisation, en jouant avec des struct dx et struct ogl ?

PS: Je ne pense pas que tu ais réelement besoin de méta-prog.

[Bousk]

Bonjour,

Dans un contexte très similaire, sur un article de Laurent Gomilla http://loulou.developpez.com/tutorie.../partie8/#L4.3, ce dernier reçois dans ses renderer spécialisé des shader, auquel il applique un static_cast vers la bonne classe dérivée comme il est "sûr" de ce qu'il va recevoir.

Code :

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

1
2
3
4
5
6
void COGLRenderer::SetVertexShader(const IShaderBase* Shader)
{
    const COGLShader* OGLShader = static_cast<const COGLShader*>(Shader);
 
    // Traitement ...
}

tel que je le vois, tu as donc spécialiser tes shader en plus de l'interface de base qu'ils partagent.
Une autre solution serait d'étoffer l'interface de base et de ne tenir compte que des informations nécessaires de chacun dans la spécialisation (des paramètres inutilisés donc).
Ou, puisque tu connais à la compilation (avec defines et config de projet je suppose - en tous cas c'est ce que j'ai de mon côté), tu peux conditionner l'interface de base (ifdef etc) pour correspondre à la spécialisation. Je trouve ça moins propre.

[victor_gasgas]

La solution a basse de preprocesseur, si j'ai bien compris, poserait comme problème d'etre instrusive, et par consequent difficile a gérer si j'ajoute une autre API.

Par contre en reflechissant, je pense pouvoir m'en sortir facilement a base de polices et classe de traits, avec deux classes, ogl et dx!
Sinon oui il m'arrive d'avoir du code en commun comme par exemple tout ce qui touche a la verification des ressources CPU avant de les passer sur GPU.

Merci de vos reponses!

[victor_gasgas]

Par contre quand tu parles de specialisation de template, dans ce cas la, tu specialiserais quoi toi?

[Flob90]

Je vois deux solutions :

• Directement des classes du genre renderer<api> (ou api serait le nom de l'api, donc ogl/dx).
• Ou alors des classes de traits intermédiaires pour laisser l'implémentation des couches d'abstraction des api plus libre.

Je ne sais pas exactement quel solution est la mieux (ca dépend surment de la nature exacte des besoins, et comme j'y connais rien en api "3d", je dois pas voir tout les détails). Cependant une solution à base de renderer<api>, shader<api> me fait douter pour l'évolution du code. Alors qu'une solution a base de trait est plus libre de ce coté.

Une fois que tu as écrit ta classe pour une api, tu spécialises le trait, et ensuite tout les détails "techniques" (lié au langage) qui apparaitront à cause du reste de ta bibliothèque, pourront, peut-être, être résolue en ajoutant des informations dans la classe de trait sans "poluer" la classe d'origine.

Il faut y réfléchir un peu plus, mais dans les deux cas l'idée est la même : spécialiser une classe selon un paramètre réprésentant l'api.

Dans tout ce qui est commun, il y a des données membres (des vraie ressources) ou c'est juste des fonctions ?

[victor_gasgas]

Merci de la reponse!

Pour ce qui est des donnees membres communes, je peux en avoir oui sivant les classes. Sur quoi je pourrait m'orienter sinon?

Je pense m'orienter vers la solution des traits pour me faire une idee!