SFML community forums
Help => General => Topic started by: __fastcall on April 02, 2009, 09:32:15 am
-
#include <sfml/System.hpp>
#include <sfml/Graphics.hpp>
#include <sfml/Window.hpp>
#include <iostream>
// #define STATIC
#ifdef STATIC
# ifdef DEBUG
# pragma comment( lib, "sfml-graphics-s-d.lib")
# pragma comment( lib, "sfml-window-s-d.lib")
# pragma comment( lib, "sfml-system-s-d.lib")
# else
# pragma comment( lib, "sfml-graphics-s.lib")
# pragma comment( lib, "sfml-window-s.lib")
# pragma comment( lib, "sfml-system-s.lib")
# endif
#else
# ifdef DEBUG
# pragma comment( lib, "sfml-graphics-d.lib")
# pragma comment( lib, "sfml-window-d.lib")
# pragma comment( lib, "sfml-system-d.lib")
# else
# pragma comment( lib, "sfml-graphics.lib")
# pragma comment( lib, "sfml-window.lib")
# pragma comment( lib, "sfml-system.lib")
# endif
#endif
int main( int, char*[] )
{
sf::RenderWindow rw(sf::VideoMode(800, 600), "SFML window");
std::cout << "Hello world.\n";
return 0;
}
The code above compiles and links without any errors or warnings with the dynamic libraries. However, it does not run; when I break the execution, the program seems to be stuck in an infinate loop inside ntdll.dll.
I tried linking with the static libraries, with only this warning:
1>LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
The program runs and the window displays, unfortunately, on its way out I get this message:
"Run-Time Check Failure #2 - Stack around the variable 'rw' was corrupted."
Adding this code after rw is declared ...:
rw.Clear( sf::Color( 255, 0, 0 ) );
... Resulted in this message on exit:
"A buffer overrun has occurred in sfml-arg-d.exe which has corrupted the program's internal state."
Ignoring the MSVCRT library breaks all the other libraries with Unresolved External Symbols. I tried the same thing with the tutorial code, with the same results. I get the same results trying to mix my code linking with the "Multithreaded Deubg DLL" and "Multithreaded Debug" versions of the runtime library. I've also tried rebuilding the SFML 1.4 libraries, but unfortunately it didn't change anything. Viewed the static-built exe and the dynamic-linked exe under dependency walker, with nothing appearing out of the ordinary...
So...
I can't use SFML 1.4 dynamic libraries, since it locks up before the program loads, and I can't use SFML 1.4 static libraries, because it's buggy and unpredictable.
What's the heck is going on?! :evil:
-
You should not use pragmas to setup your linker. Do it in your project's settings. The DEBUG macro might not be defined, actually the only "standard" macro you should expect to be defined is NDEBUG for non-debug builds.
But anyway, use your project settings ;)
-
You should not use pragmas to setup your linker. Do it in your project's settings. ... Use your project settings ;)
Thanks!
It works with the static libraries, however, I get the same problem linking to the dynamic libraries -- the program freezes somewhere in ntdll.dll before the program runs.
Any idea why?
-
Yep, you probably have a USB joystick ;)
Unplug it and try again.
-
Yep, you probably have a USB joystick ;)
Unplug it and try again.
:shock:
Thanks again! It works completely now! :D
But seriously ... WTF?!
-
I know, it's pretty weird. This is a well known bug in SFML 1.4, caused by the internal initialization of joysticks at startup, which causes the program to freeze for some reason. This has been fixed in the latest sources, that you can get with SVN.
-
The DEBUG macro might not be defined, actually the only "standard" macro you should expect to be defined is NDEBUG for non-debug builds.
In debug configuration, MSVC++ normally defines the _DEBUG macro (with underscore).
Yep, you probably have a USB joystick ;)
Unplug it and try again.
You've got a nice crystal ball. ;)
-
Yep, you probably have a USB joystick ;)
Unplug it and try again.
You've got a nice crystal ball. ;)
Not really.. It's a know bug of sfml 1.4 and he's easy to identify.
-
Is there a clean way to disable joystick support without hacking the source code, until this bug is fixed?
Edit: Oops! I guess this is fixed in SVN.
-
Oops! I guess this is fixed in SVN.
Indeed it is.
-
Oops! I guess this is fixed in SVN.
Indeed it is.
Sorry for the necro but, it is? I just compiled from SVN and now I'm getting no joystick input at all. I guess it's better than a deadlock, but we're in desperate need of joystick input for our project. Any specific revision we should turn to, or do we have to look for another lib for input?
-
Joystick input is supposed to work fine.
What joystick are you using? What OS?
-
I'm using 32-bit XP with a PS2 adapter to connect a PS2 controller to the system. It's working fine in the control panel, and it's working fine everywhere I've tried it. I do not get a single joystick event under SFML however.
Edit: The PS2 controller is just for testing purposes and are not the controllers we will use as final controllers. We do not have access to the joysticks we will be using yet, however.
-
Can you show the relevant pieces of code?
-
The only really relevant code is from the event loop:
if (_window)
{
sf::Event event;
while (_window->GetEvent(event))
{
std::cout << event.Type << std::endl;
for (std::vector<EventHandler*>::iterator iter = _handlers.begin(); iter != _handlers.end(); iter++)
{
if ((*iter)->handleEvent(event))
break;
}
}
}
I redirected stdout to a file and searched for joystick events, not a single one of the events raised are joystick events, no matter how much I keep moving the axises or pressing the buttons.
-
Some experimenting with modifying the Joystick::Initialize function and I found some weird output. The modified method is at the end of the post. This is the output it gives me:
Entered Joystick::Initialize(0)
ERROR: JOYERR_PARMS on index '0'.
Entered Joystick::Initialize(1)
For Joystick::Initialize(0)
Not the requested index: '0'. '1' requested.
ERROR: JOYERR_PARMS on index '1'.
So basically, when the method is run with 0 as parameter, joyGetPosEx instantly returns JOYERR_PARMS. When Initialize is run with 1 as index however, it finds one joystick with index 0, but since the requested index was 1 it chooses to ignore this. Quite odd. :?
void Joystick::Initialize(unsigned int Index)
{
// Reset state
myIndex = JOYSTICKID1;
myNbAxes = 0;
myNbButtons = 0;
std::cout << "Entered Joystick::Initialize(" << Index << ")" << std::endl;
// Get the Index-th connected joystick
MMRESULT Error;
JOYINFOEX JoyInfo;
unsigned int NbFound = 0;
for (NbFound = 0; (Error = joyGetPosEx(myIndex, &JoyInfo)) != JOYERR_PARMS; myIndex++)
{
std::cout << "For Joystick::Initialize(" << NbFound << ")" << std::endl;
// Check if the current joystick is connected
if (Error == JOYERR_NOERROR)
{
// Check if it's the required index
if (NbFound == Index)
{
// Ok : store its parameters and return
JOYCAPS Caps;
joyGetDevCaps(myIndex, &Caps, sizeof(Caps));
myNbAxes = Caps.wNumAxes;
myNbButtons = Caps.wNumButtons;
if (myNbButtons > JoystickState::MaxButtons)
myNbButtons = JoystickState::MaxButtons;
return;
}
else
{
std::cout << "Not the requested index: '" << NbFound << "'. '" << Index << "' requested." << std::endl;
}
// Go to the next valid joystick
++NbFound;
}
}
std::cout << "ERROR: " << (Error == JOYERR_PARMS ? "JOYERR_PARMS" : "NONE") << " on index '" << NbFound << "'. " << std::endl << std::endl;
}
-
UPDATE: MSDN says this (http://msdn.microsoft.com/en-us/library/ms709354%28VS.85%29.aspx) about the JOYINFOEX pointer:
Pointer to a JOYINFOEX structure that contains extended position information and button status of the joystick. You must set the dwSize and dwFlags members or joyGetPosEx will fail. The information returned from joyGetPosEx depends on the flags you specify in dwFlags.
I added them to the JoyInfo structure (sizeof(JoyInfo) and JOY_RETURNALL, respectively) and my gamepad works now. Might be a good idea to update the SVN version to do that as well.
-
Great job :)
Thanks a lot, I'll update the code as soon as possible.
-
I've updated the SVN, can you confirm that it's ok?
-
Having downloaded and compiled the new SVN version with newest MinGW again gives me the bug that used to be issued where the entire app freezes on launch, before even entering the main function. Seeing as there's been no change between r1089 and r1890 other than those two lines though, which are the exact same I added yesterday, and it didn't freeze when I ran it then, the issue might be something else. I'll keep investigating and report back if I find something.
EDIT: My mistake, it works fine now. I had the joystick threshold set to 0, so my event loop was endless. Thanks for the help.