The dynamic/static cast trick is only for omit the dynamic cast (which can be omitted, i.e, the type won't really be unknown or wrong at runtime) overhead. It was to answer your "Right now I use a dynamic_cast on this to check for NULL exception (different type)"
So if you can always use static cast, or jthe overhead of dynamic_cast is not a problem, that's fine.
For the last question, I have some answer in my another thread (I gave the link before), here is a very short summary, so no new thread, :-)
1, I use integer ID instead of string name at runtime. So even I use map, it's much faster than string.
2, I use the ID as the index of an array. So the time complexity is always O(1) to get a component.
3, If array memory is a problem, I can use some sparse array for it (0..N-1 is in one array, N..2N-1 is in second array, so if no N..2N-1, I don't need to allocate it).
Even if performance is not an issue to you yet, it will not harm if you use integer ID internally instead of string name. Just a suggestion.
Components and Attribute linking
Quote:Original post by wqking
The dynamic/static cast trick is only for omit the dynamic cast (which can be omitted, i.e, the type won't really be unknown or wrong at runtime) overhead. It was to answer your "Right now I use a dynamic_cast on this to check for NULL exception (different type)"
So if you can always use static cast, or jthe overhead of dynamic_cast is not a problem, that's fine.
For the last question, I have some answer in my another thread (I gave the link before), here is a very short summary, so no new thread, :-)
1, I use integer ID instead of string name at runtime. So even I use map, it's much faster than string.
2, I use the ID as the index of an array. So the time complexity is always O(1) to get a component.
3, If array memory is a problem, I can use some sparse array for it (0..N-1 is in one array, N..2N-1 is in second array, so if no N..2N-1, I don't need to allocate it).
Even if performance is not an issue to you yet, it will not harm if you use integer ID internally instead of string name. Just a suggestion.
The only problem I have with changing to static_cast, is that I won't be able to handle the exception gracefully. The application would just crash hard as it tried to access garbage. While dynamic_cast actually returns NULL if the types don't match, so I can handle it with a good exception message to the user. But yeah, we understand each other here I'm sure :)
Right, integer IDs is a good optimization over strings, but can also be quite difficult to work with from a programmer's perspective. Like, if you choose to use an enum list, you have to update this enum every time you add a new component type, which results in a deep recompile of the engine. Also, using enums might become a bit difficult if you want to mix C++ defined components and script defined components (if you start to script components in eg. Lua). Strings here works more streamlined and conveniently, but with an extra overhead on performance of course. So it's a trade of development convenience vs performance. One could always go through the engine and change to enums at the end of the project, before public release is made, or add in some compiler #if's to handle this maybe... I'm sure there are other smart ways to optimize this as well... but I haven't really looked into it yet, as it hasn't really been an issue for me thus far. Strings are just very convenient, and you can in fact do quite a few compares each frame without it tolling performance too badly (on PC that is). Integers are definitely a huge optimization compared to strings though, I'm not neglecting that argument, I've just chosen to trade that for development convenience thus far.
One easy way, as recommended by Jason Gregory and used by myself, is to use the hash produced by a string as its id. Then you just have to maintain an associated table. How you want to maintain that table is up to you. I maintain a global table outside of my program using a local SQL database for small projects, and then run a pre-process on my code before it is compiled to replace any instances of strings with their id. The pre-process also checks to make sure that there is no collision, but with the murmur hash I have never had a problem with that on all of my projects.
Of course you could simplify the process a great deal, and even modify your approach. The approach above is just what works best for myself.
Of course you could simplify the process a great deal, and even modify your approach. The approach above is just what works best for myself.
That's a very interesting technique, and I definitely have had some form of hashing in mind for optimizing my component system, though especially use of hash maps. Looking up based on the hash of strings sounds very both fast and convenient! I love it when you can get the both of two worlds! :D Of course, you will run the risk of conflicts, as strings do take up more bits than say 32 bit integer hash... but sounds like you haven't had problems with this as of yet :) I saw the link you gave supports up to 128 bit hash with good performance! Sounds promising :)
Author
Quote:Original post by Halifax2
One easy way, as recommended by Jason Gregory and used by myself, is to use the hash produced by a string as its id.
Where is this detailed? I do have a copy of Game Engine Architecture, but I don't remember seeing this in it.
Thanks trefall. Simotix, he addresses the subject starting on page 242, 5.4. Strings, to the end of page 247. He speaks of how Naughty Dog uses a variant of CRC-32 (versus my murmur hash), and has never experienced a collision in over two years of development on their title Uncharted: Drake's Fortune. After that he explains some of the details of how they allow runtime-hashing of ids as well as preprocessed ids.
I'm also using MurmurHash for resource identification purposes. It was worked well so far, though I don't have many resources yet.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
