Messages

1

Graphics / Re: Creating a Vector of Shapes

« on: January 12, 2014, 05:25:53 am »

It works fine for SFML 2.0. Are you using a different version?

2

System / Re: Footprint size of sf::Mutex

« on: January 11, 2014, 03:55:24 am »

Is it possible to find out how many bytes an sf::Mutex takes up on each platform?

On Unix systems sf::Mutex contains a pthread_mutex_t object which size should be 40bytes.
On win32 systems it contain a CRITICAL_SECTION object which has 24bytes.


AlexAUT

On Windows, CRITICAL_SECTION may or may not be larger than 24 bytes since it has several pointers to other structures (one of them I looked at being at least 32 bytes) and handles. I'm not sure if the object that a pointer points to counts in the size factor, though.

With so many entities, it is highly unlikely that the same entity will be processed by multiple systems at any given time. Since all logic goes in systems, and systems can only communicate via thread-safe events, I think it might be feasible.

Given that 1 million windows CRITICAL_SECTIONs lock and unlock operations takes only 23.5 nanoseconds, I think the mutex overhead will be negligible. http://preshing.com/20111124/always-use-a-lightweight-mutex/

And finally, I'm just experimenting, having fun, and learning. Besides, someone has to at least attempt it

I honestly don't understand what the point of using 1 million mutexes could solve. If you're going to have 1 million entities as a shared resource, and assuming they're all in a vector or some container for processing by iteration, when the system goes to process the shared resource, just lock down the vector with a single mutex, process, then unlock that one mutex.

3

Network / Re: Checking incoming data

« on: January 09, 2014, 04:43:28 am »

I believe so, but you will need to provide your own overloaded insertion/extraction operators for your own types.

4

Window / Re: [SFML 2.1 with VS2012] Event Help - keyboard and mouse problem

« on: January 08, 2014, 02:33:54 am »

It's hard for me to tell, since this isn't a minimal example, but I can already tell that you're trying to handle one window's events in 3 different places which indicates to me a starting point to finding a solution to your problem.

I suggest handling a single window's events in one place and acting on events via a state variable. For example, if the state is "showing splash screen", then while that is true, show the splash screen until an event (such as any key released) occurs that turns that variable false which will break the loop and allow you to continue to the next subroutine.

5

Graphics / Re: Thread causes a crash in SFML/wxWidgets app

« on: January 05, 2014, 02:36:12 am »

Does that solve your problem? If so, please mark it so.

6

Graphics / Re: Thread causes a crash in SFML/wxWidgets app

« on: January 05, 2014, 02:11:55 am »

Your thread object goes out of scope before it really has a chance to do anything. Put your thread object somewhere where its scope will outlast the execution of its callback.

7

General discussions / Re: Understanding The syntax of SFML.

« on: January 04, 2014, 04:22:50 am »

It is a namespace like std. Use

using namespace sf;

if it bothers you.

Never use "using namespace" for any namespace. It is widely considered bad practice due to causing namespace collisions and the fact that the namespace clarifies where a function/class/etc is coming from, making code a bit easier to understand and making it easier to find the proper documentation for a function/class/etc.

Don't say never. You can use "using namespace" in a scoped block which can be advantageous. What you really don't want to do is use a namespace outside of a scoped block, such as in the global space of a header file. You can read here (http://stackoverflow.com/questions/223021/whats-the-scope-of-the-using-declaration-in-c) for more ideas.

8

Graphics / Re: Calling draw(...) on instance of class implementing Drawable

« on: January 04, 2014, 03:25:48 am »

It's protected because it's an internal method. Classes that inherit protected members are guaranteed to have direct internal access to those members, unlike private members which are encapsulated out of reach of inherited classes. You really don't need to access this method outside of the object. sf::RenderTargets (i.e., sf::RenderWindow) are friend classes to sf::Drawable so they can access this internal draw() method. All you have to do is define it, keep it protected, and instead use your window's draw() method with your Status object as a parameter.

9

Network / Re: List of std::pair<sf::TcpSocket, std::mutex>

« on: January 04, 2014, 03:01:14 am »

Makes sense. I don't often work with std::pair or std::unique_ptr, plus I'm still using VS2010, so I don't have std::make_unique. The way I offered works, but obviously not in the way intended. But I will remember this for future reference. +1.

10

Network / Re: List of std::pair<sf::TcpSocket, std::mutex>

« on: January 03, 2014, 03:24:43 am »

I suppose you would know better than me.

Try this...

std::list< std::unique_ptr< std::pair<sf::TcpSocket*, sf::Mutex*> > > list;
list.push_back(std::unique_ptr< std::pair<sf::TcpSocket*, sf::Mutex*> >(new std::pair<sf::TcpSocket*, sf::Mutex*>(new sf::TcpSocket, new sf::Mutex)));
 

11

Network / Re: List of std::pair<sf::TcpSocket, std::mutex>

« on: January 02, 2014, 08:03:37 am »

I understand the need for dynamic sockets, just not paired mutexes. It sounds like a lot of unneeded work. Just have one mutex lock down the resources so the clients accessing them won't corrupt them.

12

Network / Re: List of std::pair<sf::TcpSocket, std::mutex>

« on: January 02, 2014, 02:36:51 am »

Why are you dynamically pairing sockets with mutexes?

13

System / Re: Passing arguments to sf::Thread

« on: December 31, 2013, 09:03:51 pm »

For future reference, I think the solutions here (http://stackoverflow.com/questions/12338695/c11-styled-callbacks) might help you later down the road to making a styled method callback. I haven't tried it yet, but it might give you some ideas.

14

System / Re: Passing arguments to sf::Thread

« on: December 30, 2013, 05:36:07 am »

sf::Thread does not take methods that have parameters. That's what "Called object type 'void (Map::*)(Vector4i)' is not a function or function pointer" means -- it only works with functions or functors with a single argument.

15

Network / Re: problems with sf::TcpSocket

« on: December 29, 2013, 10:39:06 pm »

I'll link you to this one more time: https://github.com/SFML/SFML/wiki/FAQ#i-cant-connect-to-the-other-computer-over-the-internet

Check your firewall settings, router settings, etc., etc. Since you are able to make your server and client connect via localhost, your connection issues are not SFML related.