static bool CompareObjects(Object* obj1, Object* obj2)
{
return obj1->GetDepth() < obj2->GetDepth();
}
void Level::DrawObjects(Graphics& graphics, const SDL_Rect& view) const
{
//Create "set" list and use "CompareObjects" to order them using their depth.
std::set<Object*, bool(*)(Object*, Object*)> drawList(CompareObjects);
//Add player objects
for(PlayerManager::const_iterator it = playerList.begin(); it != playerList.end(); ++it)
drawList.insert(it->second);
//Add foreground tile objects
for(std::list<ForegroundTiles*>::const_iterator it = foreTilesList.begin(); it != foreTilesList.end(); ++it)
drawList.insert(*it);
//Draw the objects
for(std::set<Object*>::iterator it = drawList.begin(); it != drawList.end(); ++it)
{
Object* obj = *it;
obj->Draw(graphics, view);
}
}Is std::set any good?
Author
I want to use std::set to automatically order objects in my game before they're drawn. Whenever the game calls Level::DrawObjects(..) it adds various objects to a std::set which should order them based on their depth. Was wondering if std::set would be fast or would creating an array, then calling std::sort be faster? Heres the code i got now:
Yes it would be (depending on the data and sort algorithm) since it would put the objects in the correct order right the way. A thought about your implementation though, why would you want to create this every frame? It would be more effective to keep this list in memory and just update it on changes.
You really should change your thread title "Is std::set good for this?" would be a lot less provocative.
Actually, in this case std::set would not be the best choice, and here's a number of reasons why:
Container choosing rule number one, is that the first choice of container you should consider is always the vector. Only if you find a reason that using a vector would not suit do you ever consider something else. In this case, a vector will perform every function you require using algorithms with a Big-Oh expression that can't be beaten by any of the other container types. Sorting a vector tends to be somewhat faster than inserting all items into a set. You're only inserting items at the end and this an be done in constant time with a vector.
A vector has zero per-item overhead. A set most likely has around 12 or more bytes of per-item overhead.
A vector is contiguous in memory and that makes it faster for caches and means less memory fragmentation.
Even more reasons to use a vector are that you can probably perform sorting in even less time than std::sort by using a well-written radix sort, if there are enough items.
Having said that, std::set isn't a bad choice, it's just not the preferred choice for your situation.
Actually, in this case std::set would not be the best choice, and here's a number of reasons why:
Container choosing rule number one, is that the first choice of container you should consider is always the vector. Only if you find a reason that using a vector would not suit do you ever consider something else. In this case, a vector will perform every function you require using algorithms with a Big-Oh expression that can't be beaten by any of the other container types. Sorting a vector tends to be somewhat faster than inserting all items into a set. You're only inserting items at the end and this an be done in constant time with a vector.
A vector has zero per-item overhead. A set most likely has around 12 or more bytes of per-item overhead.
A vector is contiguous in memory and that makes it faster for caches and means less memory fragmentation.
Even more reasons to use a vector are that you can probably perform sorting in even less time than std::sort by using a well-written radix sort, if there are enough items.
Having said that, std::set isn't a bad choice, it's just not the preferred choice for your situation.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement