Jump to content

  • Log In with Google      Sign In   
  • Create Account


How is a system with render dependent resources structured.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 korvax   Members   -  Reputation: 296

Like
0Likes
Like

Posted 11 April 2014 - 06:03 AM

Hi, this question is more of a structural and code based.

Lets say you have some sort of engine in lack of a better name, has as a rendersystem.  The Rendersystem could be OpenGL or DX based.

The Engine have knowleage of some of the common render objects, like Shader, ShaderView, meshes and so on. It does not now what a OpenGL and DX Shader is. How does the more professional systems handle this?

 

I can think of two solutions, one is that the rendersystem has a list of all DX Shader and the Shaders in the engine has an ID to that list (alt 1),

Or that OpenGL Shader would be a subclass of the Engine Shader and cast to a OpenGL Shader every time its beeing used in the Render system (alt 2).

 
(alt 1)

void OpenGL::ShaderInput(EngineShader* pShader)

{

OpenGL* pOpenGLShader = GetOpenGLShader(pShader->ID);

}

 

(alt2)

void OpenGL::ShaderInput(EngineShader* pShader)

{

OpenGL* pOpenGLShader = static_cast<OpenGLShader>(pShader);

DoSomething(pOpenGLShader)

}

 

Just think both solutions seems a slow and maybe a bit wasteful. 

any thoughts pls?



Sponsor:

#2 Hodgman   Moderators   -  Reputation: 29313

Like
6Likes
Like

Posted 11 April 2014 - 09:48 AM

Alt2 is very fast - static_cast is free, so this method of implementation-hiding is very common in engines. The user actually has a pointer to a platform specific resource, but they just think that it's an agnostic resource thanks to clever casting.

Alt1 is also very useful. Believe it or not, in certain situations it can actually improve performance due to having good locality of reference (cache friendliness) due to all your used resources being allocated in a compac array. IDs can also be handy because they allow the underlying pointer to change -- e.g. We use them so that the user can have a TextureID even before a texture has been loaded from disk, and if we reload a different texture in its place, the user can keep using the same ID even though we've switched the actual GL resource they're using behind the scenes.

#3 korvax   Members   -  Reputation: 296

Like
0Likes
Like

Posted 11 April 2014 - 02:49 PM

Thank you Hodgman, excellent answer!






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS