1
Feature requests / Avoid allocations at global startup?
« on: November 03, 2010, 10:48:45 pm »
That's great! Thanks!
I'll look into it.
I'll look into it.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
Feature requests / Joystick names and other information
« on: November 01, 2010, 11:40:06 pm »
I may add that it would be nice to know if a joystick is an xbox 360 controller or not.
On windows people could use xinput for such cotrollers, in parallel with sfml for the other normal joysticks. So there should be a way to avoid allocating the same device to two different players.
Now I use xinput and directinput at once and there's an official (bad looking) piece of code for directinput joysticks to tell if they are 360 controllers. If so I skip those and open them through xinput.
I suppose this could usually work by searching 360 in the name of the driver/joystick, if nothing better is available.
I think other libraries/drivers are available officially or not for wii and sony controllers. And with the new magic wands and other crazy stuff, it would be cool to have some extra support for such joysticks, or at least a way to support them in parallel through other libs.
On windows people could use xinput for such cotrollers, in parallel with sfml for the other normal joysticks. So there should be a way to avoid allocating the same device to two different players.
Now I use xinput and directinput at once and there's an official (bad looking) piece of code for directinput joysticks to tell if they are 360 controllers. If so I skip those and open them through xinput.
I suppose this could usually work by searching 360 in the name of the driver/joystick, if nothing better is available.
I think other libraries/drivers are available officially or not for wii and sony controllers. And with the new magic wands and other crazy stuff, it would be cool to have some extra support for such joysticks, or at least a way to support them in parallel through other libs.
3
Feature requests / Avoid allocations at global startup?
« on: November 01, 2010, 11:26:58 pm »
Hi there,
First of all, good job with the library! The design looks great!
I was wondering if you could avoid having memory allocations at "global startup" - before the main function is executed.
I'm talking about the
sf::Context& Dummy = sf::Context::GetGlobal();
in context.cpp
It shows as leaks on my memory leaks report - it reports before exiting the main function. I suppose the memory is set free when the destructor is called, but I prefer to be aware of the order in which objects are allocated. It's good practice, especially with memory allocators or allocations debug tracking.
Maybe a simple global function like InitSFML would be ok, even with the fully C++ design.
--------
Another suggestion is to add project configurations with runtime library linked as Multi-Thread/Multi-Thread Debug, not only Multi-Thread DLL/Multi-Thread Debug DLL. And add these as precompiled libs too.
Now, if the sfml dll is used within a project with such settings, it crushes - for me it does when the window pointer is deleted and the window title is messed up. Probably other things as well.
Thanks!
Alex
First of all, good job with the library! The design looks great!
I was wondering if you could avoid having memory allocations at "global startup" - before the main function is executed.
I'm talking about the
sf::Context& Dummy = sf::Context::GetGlobal();
in context.cpp
It shows as leaks on my memory leaks report - it reports before exiting the main function. I suppose the memory is set free when the destructor is called, but I prefer to be aware of the order in which objects are allocated. It's good practice, especially with memory allocators or allocations debug tracking.
Maybe a simple global function like InitSFML would be ok, even with the fully C++ design.
--------
Another suggestion is to add project configurations with runtime library linked as Multi-Thread/Multi-Thread Debug, not only Multi-Thread DLL/Multi-Thread Debug DLL. And add these as precompiled libs too.
Now, if the sfml dll is used within a project with such settings, it crushes - for me it does when the window pointer is deleted and the window title is messed up. Probably other things as well.
Thanks!
Alex
Pages: [1]