Gestionnaire de ressources [Résolu]

[Kromagg]

Bien le bonjour,

Je travaille sur un moteur de rendu en OpenGL et j'arrive maintenant sur la gestion des ressources. J'ai vu deux façon de faire lors de la création d'une ressource. La première, classique, consiste à retourner un pointeur sur la ressource créée

Code :

1
2
3
4
5
6
7
8
9
10
11
 
class Renderer
{
public:
     VertexBuffer* CreateVertexBuffer(...);
     IndexBuffer* CreateIndexBuffer(...);
 
private:
     std::vector<VertexBuffer*> m_vVertexBuffers;
     std::vector<IndexBuffer*> m_vIndexBuffers;
};

La deuxième consiste à retourner un handle sur la ressource créée. L'utilisateur doit ensuite interroger le gestionnaire de ressources avec cet handle pour obtenir un pointeur sur la ressource.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
class Renderer
{
public:
     int CreateVertexBuffer(...);
     int CreateIndexBuffer(...);
 
     VertexBuffer* GetVertexBufferByIndex(int Index);
     IndexBuffer* GetIndexBufferByIndex(int Index);
 
private:
     std::vector<VertexBuffer*> m_vVertexBuffers;
     std::vector<IndexBuffer*> m_vIndexBuffers;
};

Dans le deuxième cas je cite la documentation du moteur dans lequel je vu l'implémentation
"The renderer provides the ability for other classes to create and reference the various Direct3D 11 objects. The primary objects that other non-rendering system classes will be interested in are the memory resource classes, which represent buffers and textures. The renderer allows creation of these objects, but retains ownership of them and returns only an ID to the caller. That ID is then used by the caller any time they want to reference a particular resource.
This pattern is also followed for non-resource classes as well, such as shader objects, samplers, input layouts, and so on. Instead of making the other classes work with direct references to D3D11 objects, they are instead referenced by IDs. This allows the renderer to keep control over how and when the D3D11 objects are used, and minimizes the direct knowledge needed by the application to use the engine."

Quel pattern utilisez-vous le plus et pourquoi ?

Kromagg

[Djakisback]

Salut,
personnellement j'utilise une variante du 2e pour garder une trace de toutes les ressources créées et pouvoir les libérer/y accéder plus facilement. J'ai aussi une surcouche car je stocke, par exemple, les identifiants de textures dans des objets de classe Texture. C'est donc ensuite une liste de Texture que je stocke dans le Renderder et non pas une liste d'IDs.

[LittleWhite]

Bonjour,

Comme tu l'énonce, ta première méthode, tu dépend trop de l'API sous jacente. Imagine que tu veuille faire du DirectX, de l'OpenGL et d'un troisième truc ... bah en retournant les objets eux mêmes (ou les pointeurs, peut importe) tu te lie trop au type en question.

[Kromagg]

Envoyé par LittleWhite

Bonjour,

Comme tu l'énonce, ta première méthode, tu dépend trop de l'API sous jacente. Imagine que tu veuille faire du DirectX, de l'OpenGL et d'un troisième truc ... bah en retournant les objets eux mêmes (ou les pointeurs, peut importe) tu te lie trop au type en question.

Prenons l'exemple d'une ressource de type Texture2D.

Avec la première méthode je retourne directement un pointeur sur un objet de type Texture2D.
Avec la seconde méthode je retourne un handle sur l'objet. Mais quand je vais accéder à la ressource en elle-même grâce à son handle je vais également obtenir un pointeur sur un object de type Texture2D.
Dans ce cas, quelle différence y'a t-il entre la première et la deuxième méthode ?

Kromagg

[LittleWhite]

Envoyé par Kromagg

Avec la seconde méthode je retourne un handle sur l'objet. Mais quand je vais accéder à la ressource en elle-même grâce à son handle je vais également obtenir un pointeur sur un object de type Texture2D.

Non, parce que là, à la OpenGL (qui te retourne que des int), tu vas utiliser ton handle dans des fonctions genre :

bindTex2D()
deleteTex2D()

(Après, ton moteur pourra faire toujours un test si l'ID passé correspond bien à la plage des Texture2D), mais au moins, dans ce cas là, tu n'aura jamais d'objet Texture2D réellement visible.
Mais, je trouve mon approche trop C.

Sinon, la méthode une est mieux, dans le style approche C++, si le pointeur que tu renvoie est une interface. Cela n'empêche pas de garder trace de tout ce qui est fait.