So my confidence is way up... But I''m still wondering if this elegance is really worth it? Lets say I''m making a game, would this overhead DRAMATICALLY affect my game if I keep all my textures, player models, player data in a resource manager and dynamically request them recasting EVERY single time?
Engine design overhead involving casting
Author
I''m just starting to work on an engine and I''ve hit a couple brick walls in terms of performance vs ease of use. I''ve found a way to encapsulate a "resource" with all resources as children of the base class "resource"... This way I can treat all my resources the same, and keep track of them better. The problem is that whenever I need the specific resource, I would need to cast back to the dynamic type. I''m not sure if this is a big problem but I''m very keen on speed. Will casting back and forth many times a frame result in speed issues? I''m pretty happy I found this solution by myself, and then read it on Gaming Gems by one of the Lithtech guys So my confidence is way up... But I''m still wondering if this elegance is really worth it? Lets say I''m making a game, would this overhead DRAMATICALLY affect my game if I keep all my textures, player models, player data in a resource manager and dynamically request them recasting EVERY single time?
So my confidence is way up... But I''m still wondering if this elegance is really worth it? Lets say I''m making a game, would this overhead DRAMATICALLY affect my game if I keep all my textures, player models, player data in a resource manager and dynamically request them recasting EVERY single time?
It always helps to assemble your code, check the differences and see for yourself what code makes the most asm. Casting doesn''t really cause much an overhead in this way, but doing it often can cause probs, esp in a loop (which is inevitable ,yeah ?)
So as I say do both methods, assemmble and disseminate !
djsomers
So as I say do both methods, assemmble and disseminate !
djsomers
Author
I would, and I plan on doing it when I get the chance, but the larger the program gets, its kinda hard to "test" both approaches with time constraints... I just wanted to know if anybody has bumped into this problem and if they are willing to share some solutions... since this is a forum..
hi there
now, what I''m about to say may be totally wrong, I''n no expert, but here goes anyway.
I think it depends on what you mean by casting. Casting, say, a float to an int certainly has overhead, since you are actually calculating a new value (truncating the float). However, as far as I''m aware, casting a pointer/reference to an object, from a base class down to a child class, does nothing extra when compiled - it is just telling the compiler that you know what type of object the pointer is actually pointing at, and you want access to its interface, rather than that of the base class. I''m not sure though if this is what you mean (are you explicity casting to a type that you know the object is?), or if you''re talking about using virtual functions, or run-time type info, which would give overhead.
Either way though, I''d guess that any overhead from this sort of thing would not be enough to worry about, compared to the time taken to actually load/use the resource, etc.
hope I made some sense. also, i''d be interested if anyone could tell me if what I''ve said about casting is actually true.
Cameron
now, what I''m about to say may be totally wrong, I''n no expert, but here goes anyway.
I think it depends on what you mean by casting. Casting, say, a float to an int certainly has overhead, since you are actually calculating a new value (truncating the float). However, as far as I''m aware, casting a pointer/reference to an object, from a base class down to a child class, does nothing extra when compiled - it is just telling the compiler that you know what type of object the pointer is actually pointing at, and you want access to its interface, rather than that of the base class. I''m not sure though if this is what you mean (are you explicity casting to a type that you know the object is?), or if you''re talking about using virtual functions, or run-time type info, which would give overhead.
Either way though, I''d guess that any overhead from this sort of thing would not be enough to worry about, compared to the time taken to actually load/use the resource, etc.
hope I made some sense. also, i''d be interested if anyone could tell me if what I''ve said about casting is actually true.
Cameron
Author
to clarify my question..
I have a base class (say baseResource)
I have children of baseResource (say textureResource, soundResource.. modelResource etc.)
I also have a resourceManager (say resourceManager)
Whenever I am in a situation that I need a resource I request the resourceManager to find it. The thing is, it will return a baseResource type so I would need to cast it to the specific child class type (textureResource, soundResource...) to use the specifi resources.
textureResource* texture = (textureResource*)resourceManager->GetResource(someid);
My question is, this casting back and forth, does it create a lot of overhead? Think of getting multiple textures/sound/models in a single game loop... Would it be worth the time to do it this way?
1) if baseResource has pure virtual functions that the child classes (ex texture resource) are suppose to implement, does that create more overhead than...
2) if baseResource does not have pure virtual functions...
do pure virtual functions have anything to do with overhead when casting?
I have a base class (say baseResource)
I have children of baseResource (say textureResource, soundResource.. modelResource etc.)
I also have a resourceManager (say resourceManager)
Whenever I am in a situation that I need a resource I request the resourceManager to find it. The thing is, it will return a baseResource type so I would need to cast it to the specific child class type (textureResource, soundResource...) to use the specifi resources.
textureResource* texture = (textureResource*)resourceManager->GetResource(someid);
My question is, this casting back and forth, does it create a lot of overhead? Think of getting multiple textures/sound/models in a single game loop... Would it be worth the time to do it this way?
1) if baseResource has pure virtual functions that the child classes (ex texture resource) are suppose to implement, does that create more overhead than...
2) if baseResource does not have pure virtual functions...
do pure virtual functions have anything to do with overhead when casting?
ok, basically, in this case, you should either need to cast, or use virtual functions, but not both methods. If you used virtual functions, then the whole point of them is that you dont need to cast, just call it on a pointer to base class object, and it will automatically call for you the version of the function in the child class. However, this requires you to have the same functions in all child classes to make use of it. I assume this isn''t the case, since you''re going to be wanting to different things with textures than with sounds etc.
Therefore you should probably not be using virtual functions here. Sorry if I confused you with bringing them up.
So, from the line of code you gave, it seems you do know that at that particular point the ID you''re passing is for a texture resource, and so you can safely cast it as you''ve done. In this case, what I said in my last post about the casting applies (assuming what I said is correct, I think it is) - the casting shouldn''t really give you any overhead. So in my opinion, what you''re doing there is fine and shouldn''t slow you down.
Cameron
Therefore you should probably not be using virtual functions here. Sorry if I confused you with bringing them up.
So, from the line of code you gave, it seems you do know that at that particular point the ID you''re passing is for a texture resource, and so you can safely cast it as you''ve done. In this case, what I said in my last post about the casting applies (assuming what I said is correct, I think it is) - the casting shouldn''t really give you any overhead. So in my opinion, what you''re doing there is fine and shouldn''t slow you down.
Cameron
Author
.... makes me all giddy inside...thank you!
Edited by - dynamicman on October 15, 2001 3:58:54 PM
If this is your architecture, there is a minor cost for the dynamic_cast. I don''t remember exactly what it does, but it needs to find the correct vtbl to use, which means a simple index and dereference. Not something you''d want in a hard-loop, but negligible in most cases. That''s how it works without RTTI . If you''re doing a dynamic up-cast that requires RTTI, it''s a little more complicated, but still negligible compared to how long it takes to load something from disk.
IResourceManagero|CResourceManageer | +-> Collection IResourceIResourceo|IBitmapResourceo|CBitmapResourceIResourceo|IWaveResourceo|CWaveResourceetc...//I think this needs RTTI (or QueryInterface magic)IResourceo| IWave| o| |CWaveResource This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
