Messages

1

SFML projects / Re: Thor 2.0 released!

« on: August 19, 2016, 07:09:07 pm »

Is this bug official and there an issue for it? If not, have you reported it?

p.s. I'm not sure why you changed the thread's subject.

Yep there's all of that as well as a fixed branch already up, the 2.4.0 version just released may have already fixed it too.

p.s. I'm not sure how that happened either.  It was late and I guess I accidentally pasted over that field without realizing it, sorry!

2

General / Re: [SFML 2.0]Problem with A* algorithm

« on: August 19, 2016, 08:07:03 am »

A class can't contain itself as a stack member field, but it CAN contain a pointer to its type.  That is,

class Node
{
public:
     Node();
private:
    Node parentNode;  //Not okay.
}

is illegal, but

class Node
{
public:
     Node();
private:
    Node* parentNode;  //THIS Node* is ok
}

is totally valid and how linked lists are done in C++.  Doing your comparison to EndNode check via pointer address is also what you want to do instead of comparing data fields (like you're doing now) anyway.  This is because in general when doing this kind of check, you want to know if the CurrentNode IS the EndNode (that is, literally the same object at the same place in memory), while your method now doesn't care whether CurrentNode actually IS EndNode, just that they share some equivalent values.  I don't think it matters in this particular case, but most of the time it WILL matter.  It's super imperative to understand this distinction or you're gonna have a really bad time sooner or later

3

SFML projects / Re: A promising future

« on: August 19, 2016, 07:38:44 am »

Aren't there several issues with SFML resources being loaded from other threads, especially textures? Since Thor is almost always used together with SFML, this is something I have to keep in mind.

I use (my own) multithreaded-ressource loader for (sfml-)textures and it works quiet well until now, but its unfinished. It works with callbacks, instead of futures, means that the method that requests a resources gets a lambda-expression that is invoked for the texture once its loaded (you can attach the texture to a sprite in there or something like that).

Post any progress in terms of multitreading you may make here, if you like. I would appreciate it.

Are you using the current release version of SFML?  I'm curious how you're getting multithreading to work if so.  There's a pretty gnarly bug that causes SFML to overflow the stack recursively creating openGL contexts if you try using a background thread to load textures (or do anything else OpenGL-related).

I ran into it a couple days ago and ended up having to use the dev branch of SFML from pending pull requests that removes the nested contexts entirely.  I'd rather use the official source though if you have a good solution to the problem!