Hello,
Currently I have a pathfind algorithm for a set of enemies, which uses quite alot of resources and CPU time. So before I ran the algorithm each frame, causing alot of FPS lag. So I made a class with a thread, that takes care of the calculation.
So here's a sketch of what I have:
Npc class
class NPC {
public:
void setPath(std::vector<Node*>);
void walkPath();
....
private:
std::vector<Node*> m_path;
}
void walkPath() {
if(m_path.size() >= 2) {
walkToNode(m_path.at(1));
}
Now for each new NPC I create, I create a thread managing the path calculations
Thread
class Thread {
private:
m_player;
m_enemy;
}
void Thread::run() {
sf::Mutex mutex;
mutex.lock();
std::vector<Node*> path = findPath(m_enemy, m_player);
m_enemy->setPath(path);
mutex.unlock();
}
that's a pretty rought sketch, but you see what I mean.
Also, with the walkPath method, I just always walk to the second element because, by the time the enemy gets there, i'll probably have a new path, calculated from the node the enemy arrives on and just goes from there
Right now, the program just crashes when I use the thread instead of calculating the path each frame due to a segmentation fault. I don't know what I'm doing wrong...
Please help me, thanks!
void Stroustrup_Time()
{
std::cout<<"Sorry. I don't do (other people's) homework."<<std::endl;
}
http://www.stroustrup.com/bs_faq.html#homework
;D
Sorry.. I couldn't keep myself from doing that..
Anyway, threading is probably way more complex than algorithms(for which you can google pseudocode), since it craps on the basic rule of things happening in code till now: only one at a time (at least it felt that way for me). Maybe you shouldn't run the pathfinding each frame? I mean, how much can your things move in a reasonably high fps game(~60, limited by avoiding tearing, but still making each frame last very little)? Almost surely not far enough to invalidate their path instructions from the last frame?
However, if you insist on threads, I understand the pain of uni(Grr..evil uni >:() and here is a small explanation, hope I didn't make any mistake, I'm quite new to threads and I didn't need them so far:
sf::Mutex when locked stops thread if it's already locked by another thread, so you'd want to do something along the lines of:
Have a function that can change some data in a class, with sf::Mutex as a member of that class, constructing a lock on sf::Mutex while you enter that function. The idea is to have any writing happen during sf::Lock's lifetime.
Another use of threads I've seen is creating several threads to process unrelated data, instead of counting 3 vector sums, each with bilion elements, one after another, we create 3 new threads, tell them to do that and give us back the result somehow and launch them from main thread and imidiately tell them to .wait() so that our main thread waits till all three are done, and then display the 3 sums.
You should really consult documentation of both SFML and/or <thread>(if using a c++11 compiler, <thread> is more powerfull than what SFML offers). Googling your questions about threads or algorithms might help too.