boost::any: how fast/how slow is it?
Author
Has anybody ever had problems regarding permance with the boost::any object? I'm calling the boost::any_cast about 3 times for every sprite I render. Would that be too much?
I've read that it is quite slow, but again, if you're not going to use it in critical parts of the code or accesing it hundrieds of times it gets the job done. It might get the job done then anyway.
Run a bechmark yourself in a test that resembles the code you're going to implement with and without any.
google for other benchmarks people have run.
Run a bechmark yourself in a test that resembles the code you're going to implement with and without any.
google for other benchmarks people have run.
Are these transgender sprites having an identity crisis? Why are they hiding in the any closet?
They are sprites, why not declare them as such.
They are sprites, why not declare them as such.
Author
Quote:Original post by Antheus
Are these transgender sprites having an identity crisis? Why are they hiding in the any closet?
They are sprites, why not declare them as such.
They aren't. I was just experimenting with a modular rendering plug-in system. Then I have saved all API specific information before rendering to avoid using any_cast during the rendering and I had my FPS rate considerably increased.
I'm making a class that abstracts all sprite rendering, doesn't matter what API it uses. It is something like this:
class Renderer{ // ... ... ... virtual boost::any GetRenderContext() = 0;};class Sprite{ // ... virtual bool Draw() = 0; virtual bool CreateSprite(RendererPtr renderer) = 0;};This way I may implement a D3D9Renderer and a D3D9Sprite and use GetRenderContext to give me the device pointer.
Then the sprite is holding a reference to a generic renderer because, depending on what graphics API we're using, the sprite renderer would need specific data, like a device or other context stuff.
I'm not sure if it's the best way to go but it has worked for me so far.
What is a RenderContext, then? What types will you be any_cast<>ing to? And why aren't those types related by polymorphism?
Why does it need to be "anything"? In almost every case I can think of I was able to use some parent interface (eg ISprite which then has D3D9Sprite and D3D11Sprite implementations) which also meant I could use fast static casts (and double checks with dynamic_cast in debug builds).
Why can you not make an IRenderContext? If your just returning say a IDirect3DDevice9 type thing you could also use the COM interfaces (IUnknown and QueryInterface) or you could use a void* with an unsafe cast and check the type data from somewhere else (eg a GetRendererType method which returns an enum to id the implementations, eg D3D9, D3D10, OPENGL, etc).
Why can you not make an IRenderContext? If your just returning say a IDirect3DDevice9 type thing you could also use the COM interfaces (IUnknown and QueryInterface) or you could use a void* with an unsafe cast and check the type data from somewhere else (eg a GetRendererType method which returns an enum to id the implementations, eg D3D9, D3D10, OPENGL, etc).
Author
Quote:Original post by Zahlman
What is a RenderContext, then? What types will you be any_cast<>ing to? And why aren't those types related by polymorphism?
RenderContext, in the Direct3D implementation, will be the device.
The Renderer object takes care of general render states and window related operations.
The Renderer represents the device as a polymorphic class itself. But for some API's, such as Direct3D, we still need a pointer to the device instance in order to load resources and buffers. That means other objects could use it.
Quote:Original post by Fire Lancer
Why does it need to be "anything"? In almost every case I can think of I was able to use some parent interface (eg ISprite which then has D3D9Sprite and D3D11Sprite implementations) which also meant I could use fast static casts (and double checks with dynamic_cast in debug builds).
Why can you not make an IRenderContext? If your just returning say a IDirect3DDevice9 type thing you could also use the COM interfaces (IUnknown and QueryInterface) or you could use a void* with an unsafe cast and check the type data from somewhere else (eg a GetRendererType method which returns an enum to id the implementations, eg D3D9, D3D10, OPENGL, etc).
I thought it would be nice to let it be anything because then it would be capable of implementing any graphics API. This way it woudn't let the user pass an OpenGL Renderer to implement a DIrect3D 9 Sprite. That would be stupid, but still, the code is safer. Am I being over protective? Anyway, it would not affect performance since I do all of it in load time.
I don't want to return IUnkown because then I would HAVE to inclue MS headers (please correct me if I'm wrong), and that kills my cross-platformbility.
I still don't see why you can not have a common interface.
Eg I have an "IGraphicsDevice" interface (with implementations for each renderer). My D3D9GraphicsDevice class holds the IDirect3DDevice9 object, and provides a "GetDirect3DDevice()" method. Any class which operates with Direct3D at a low level and needs the underlying IDirect3DDevice9 can down cast IGraphicsDevice to D3D9GraphicsDevice (I generally use static_cast for release builds, the chances of getting it wrong is fairly low and their are debug builds for that) to get the device. I can do similar things for getting a IDirect3DTexture9 from my ITexture interface.
In this way I have a set of common interfaces which is all mayby 90% of my game code needs, and can get the low level under laying DirectX objects where really needed.
Also what's wrong with my GetRendererTyoe suggestion? As long as you make sure each of your implementations uses a different return value for it your sorted as it effectively forms your own RTTI system. A given implementation doesnt have to know about any others, if your Direct3D9 implementation used a value of 2 and when you tried to create a Direct3D9 sprite the renderer returned a type value of 5 (perhaps OpenGL) you know it is wrong. (this obviously assumes that casting the void pointer to your type will work, and the pointer does not need adjusting due to multiple inheritance of other complexities).
Eg I have an "IGraphicsDevice" interface (with implementations for each renderer). My D3D9GraphicsDevice class holds the IDirect3DDevice9 object, and provides a "GetDirect3DDevice()" method. Any class which operates with Direct3D at a low level and needs the underlying IDirect3DDevice9 can down cast IGraphicsDevice to D3D9GraphicsDevice (I generally use static_cast for release builds, the chances of getting it wrong is fairly low and their are debug builds for that) to get the device. I can do similar things for getting a IDirect3DTexture9 from my ITexture interface.
In this way I have a set of common interfaces which is all mayby 90% of my game code needs, and can get the low level under laying DirectX objects where really needed.
Also what's wrong with my GetRendererTyoe suggestion? As long as you make sure each of your implementations uses a different return value for it your sorted as it effectively forms your own RTTI system. A given implementation doesnt have to know about any others, if your Direct3D9 implementation used a value of 2 and when you tried to create a Direct3D9 sprite the renderer returned a type value of 5 (perhaps OpenGL) you know it is wrong. (this obviously assumes that casting the void pointer to your type will work, and the pointer does not need adjusting due to multiple inheritance of other complexities).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
