Messages

16

General discussions / Joystick fix in SFML 1.6

« on: January 09, 2010, 02:38:28 am »

Reporting live from Ubuntu 9.10 x86 Karmic Koala:
- X Axis works
- Y Axis works
- Z Axis (throttle) works
- R Axis (rudder) works
- U Axis can't test this one
- V Axis can't test this one
- POV, is initially -1 but doesn't receive any updates, so doesn't work.

I checked if my joystick works and it seems so. Then I checked your sourcecode and probably found the error. You're checking hat-X and hat-Y against 1, 0 or -1. The values I received from my test application were 32767, 0, -32767

To the U and V axis, I can't test this ones, because I have no joystick that have U or V axes.

Dravere

17

General discussions / Joystick fix in SFML 1.6

« on: January 06, 2010, 03:00:14 pm »

Ok, did make now further testing with the new code:
1. There is an error in the submitted code

Code: [Select]

Win32/Joystick.cpp - Line 97 : JoystickState State = { 0 };
JoystickState isn't a POD anymore because of the constructor, so change this line to:

Code: [Select]

JoystickState State;
2. POV is initially still on 0. I simply changed Input::ResetStates to (marked the single line nearly at the end):

Code: [Select]

void Input::ResetStates()
{
    for (int i = 0; i < Key::Count; ++i)
        myKeys[i] = false;

    for (int i = 0; i < Mouse::ButtonCount; ++i)
        myMouseButtons[i] = false;

    for (int i = 0; i < Joy::Count; ++i)
    {
        for (int j = 0; j < Joy::ButtonCount; ++j)
            myJoystickButtons[i][j] = false;

        for (int j = 0; j < Joy::AxisCount; ++j)
            myJoystickAxis[i][j] = 0.f;
       
        myJoystickAxis[i][Joy::AxisPOV] = -1.f; // <- I added this
    }
}

After those changes everything worked very well on Win7 x64 with 2 real joysticks. So I moved to WinXP x86 and there also was no problem too.

Well, then I made the fatal error to try this on linux (I hate linux, somehow). After "hours" of setting up sfml, I had my usual problems with linux, I finally achieved it. I think it was worth, because there were several errors. Perhaps I better say first what does work:
- Buttons
- X and Y axes.

That is it
Now to the errors:
- POV is somehow mapped to R. Only upward (0°) and downward (180°) gives any output: 100 and -100, but not degrees.
- Ruder (normaly on R) is mapped to Z. At least there are correct values.
- Throttle (normaly on Z) isn't recognized at all.

Edit: Forgot, I'm using KUbuntu Jaunty Jackalope 9.04.


Feature that I may suggest:
- Add a function to re-identify joysticks while running the app. So you can plug in a joystick while the app is running and after calling this function, the joystick will be recognized. No restart of the app is needed.

Dravere

PS: No linux guys here to test? I don't want to do this :lol:

18

General / Qt + SFML

« on: January 06, 2010, 11:43:05 am »

Qt uses 4.4.x in its latest release, ...

no, its one of latest release of Qt, and in manifest of Mingw said, what it is gcc 4.40....hm

Interesting ...
How is this possible, because MinGW has no stable GCC 4.4 release yet, as far as I know. There seems only to be a beta somewhere, which I never could find :?

Well anyway, sorry I couldn't help. Currently don't have a functioning GCC setup here to test it.

Dravere

19

General discussions / Joystick fix in SFML 1.6

« on: January 06, 2010, 01:07:57 am »

So stupid :lol:
It's fixed.

But not submitted
For futher testing I made my own fix. Not really hard:
- Changing 2 to 4 at two lines in Input.hpp
- Adding 2+2 lines in Input.cpp Constructor.
- Changing 2 to 4 in Input.cpp at IsJoystickButtonDown
- Adding 2 lines in Input.cpp at OnEvent (LostFocus)

I found a software on the internet (PPJoy) that could create virtual joysticks. So I could test joystick 3 and 4. Didn't find any further errors yet. But PPJoy can't simulate Axis U and V, also there is no POV simulation.
Anyway, I don't think there will be an error, because the code is the same as for joystick 1 and 2

Will do some further testing on WinXP later (tomorrow/today).

I have no idea. Do you mean that the returned values are completely random until you move?

No, they are all set to 0. That wouldn't do anything to axis X, Y and R, because normally you start the app without having the joystick full on the left or something like this.
But for example the axis Z (throttle) is also at 0. But this means on most games that you want 50% throttle. As soon as I move the stick the first time, it will get to 100 (0%). A very very very small problem something you don't need to investigate any further, if you don't know something about it. I only wanted to ask, if perhaps somebody already knows something about this

PS: I don't recommend PPJoy. You need to activate testsigning on Vista and Win7 so you can use it.

20

Graphics / Inheriting from Drawable

« on: January 06, 2010, 12:32:30 am »

How is CGameEngine related to your code?

I'm using it to manage/switch between various states (ie. an intro, menu, game proper, etc).

Very well, but the error says, it can't find an empty constructor for CGameEngine. The error has nothing to do with the code you showed us.

Dravere

21

General / Qt + SFML

« on: January 06, 2010, 12:28:43 am »

Hmmm, I probably know what the problem is, but I'm not so sure...

If I remember right Qt Creator uses the old GCC Compiler from MinGW on Windows. It is the version 3.4.5 or something. And I once read someting about problems between SJLJ and DW2 exception handling. You should have a look at the mingw.org Mailing List.

Or perhaps try this GCC (4.4.1) replacement for MinGW:
http://www.tdragon.net/recentgcc/

Dravere

22

General discussions / Joystick fix in SFML 1.6

« on: January 05, 2010, 08:03:01 pm »

For anyone that wants to test:

Code: [Select]


#include <SFML/Graphics.hpp>

#include <string>
#include <sstream>


std::string CreateJoystickDump(sf::Input const& input);
void PrintJoyState(std::ostream& out, sf::Input const& input, unsigned int joyId);


int main()
{
sf::RenderWindow mainWindow(sf::VideoMode(800, 600), "Joystick Test");

mainWindow.UseVerticalSync(true);

std::string dump;

sf::Event evt;
sf::String text;
sf::Input const& input = mainWindow.GetInput();

while(mainWindow.IsOpened())
{
while(mainWindow.GetEvent(evt))
{
if(sf::Event::Closed == evt.Type)
{
mainWindow.Close();
}
else if(sf::Event::KeyReleased == evt.Type &&
sf::Key::Escape == evt.Key.Code)
{
mainWindow.Close();
}
}

dump = CreateJoystickDump(input);

mainWindow.Clear();

text.SetText(dump);
mainWindow.Draw(text);

mainWindow.Display();
}

return 0;
}

/************************************************************************/

std::string CreateJoystickDump(sf::Input const& input)
{
std::ostringstream oss;

PrintJoyState(oss, input, 0);

oss << "\n---------------\n";

PrintJoyState(oss, input, 1);

oss << "\n---------------\n";

PrintJoyState(oss, input, 2);

oss << "\n---------------\n";

PrintJoyState(oss, input, 3);

return oss.str();
}

/************************************************************************/

void PrintJoyState(std::ostream& out, sf::Input const& input, unsigned int joyId)
{
out << " X: " << input.GetJoystickAxis(joyId, sf::Joy::AxisX);
out << " Y: " << input.GetJoystickAxis(joyId, sf::Joy::AxisY);
out << " Z: " << input.GetJoystickAxis(joyId, sf::Joy::AxisZ);

out << '\n';

out << " R: " << input.GetJoystickAxis(joyId, sf::Joy::AxisR);
out << " U: " << input.GetJoystickAxis(joyId, sf::Joy::AxisU);
out << " V: " << input.GetJoystickAxis(joyId, sf::Joy::AxisV);

out << '\n';

out << " POV: " << input.GetJoystickAxis(joyId, sf::Joy::AxisPOV);

out << '\n';

for(unsigned int button = 0; button < 16; ++button)
{
out << ' ' << input.IsJoystickButtonDown(joyId, button);
}
}


To my results (Win7 x64):
- Joystick 3 and 4 won't work with sf::Input, because you forgot to increase the array size there and the reaction on the events
- Joystick 1 seems to work. I had no time to test a joystick 2 yet. And I have no third or fourth joystick
- POV is initially 0. I checked joyGetPosEx, there it is 65535. Looks like an update is missing. There is also the question, do you want to intercept this middle position? A value of 655.35 as middle position is a bit special
You could perhaps introduce a negative value.

If we already are at it:
On my computer with my joystick (couldn't test this on another computer yet) the joyGetPosEx function returns valid axis values only after the joystick was moved once a bit after app startup. Do you know any solution to this? Is this windows related? Driver related? At least it isn't SFML related

Will do further tests, perhaps also on Linux, as soon as I have some spare time.

Dravere

23

Window / AxisPOV always zero, others fine?

« on: January 03, 2010, 04:54:02 am »

Everything else seems to work.
And for some ridiculous reason I didn't sleep and searched the bug.
In "void Joystick::Initialize(unsigned int Index)" in "Joystick.cpp" you get the number of axes and assume that POV is also an axis. But POV isn't counted as axis. If you want to see if the joystick supports POV you need to check the dwCaps attribute for JOYCAPS_HASPOV.
http://msdn.microsoft.com/en-us/library/dd757103.aspx

Hmmm, looking at that code ...
There could be another error. You assume if dwNumAxes is for example 4, that those are X, Y, Z and R. But this isn't guaranteed. Also in that situation you need to check the dwCaps attribute or the system axis could be mapped to the wrong sfml axis.

**
Edit:
... When I turned off the computer I realised I wrote something wrong. Couldn't get asleep without correcting it first ... dude, I need professional help :lol:

It isn't a problem, that it is mapped the wrong way, it will be simply ignored. We take again the example with dwNumAxes == 4.
Let us say it is X, Y, Z and U. In WindowImpl you assume that the axes are in order. So you check sf::Joy::AxisX (0), sf::Joy::AxisY (1), sf::Joy::AxisZ (2) and sf::Joy::AxisR (3). But in our example there is no R. So you won't send any event about sf::Joy::AxisU (4). The same way you ignore sf::Joy::AxisPOV and don't send any event for this axis, but the POV also isn't counted as axis.
Sorry, but it seems you will need some bigger rework todo

Ok, but now I'm going to bed... 5:20 AM ...

Dravere

24

Window / AxisPOV always zero, others fine?

« on: January 02, 2010, 11:08:29 pm »

Asked a friend to test my code too. His OS:
Vista x64 SP2

Joystick:
Saitek ST290 Pro

Result:
POV is always 0.

Dravere

25

Window / AxisPOV always zero, others fine?

« on: January 02, 2010, 09:54:14 pm »

Just tested it too:
Win7 x64 POV hat always 0
WinXP x86 POV hat always 0

Code:

Code: [Select]

#include <SFML/Graphics.hpp>

#include <string>
#include <sstream>
#include <iostream>


std::string toString(float val)
{
std::ostringstream oss;
oss << val;
return oss.str();
}


int main()
{
sf::RenderWindow app(sf::VideoMode(800, 600, 32), "Test Window");

sf::String text;
sf::Event evt;

while(app.IsOpened())
{
while(app.GetEvent(evt))
{
if (evt.Type == sf::Event::Closed)
{
app.Close();
}
}

float pov = app.GetInput().GetJoystickAxis(0, sf::Joy::AxisPOV);
float x = app.GetInput().GetJoystickAxis(0, sf::Joy::AxisX);

text.SetText("POV: " +  toString(pov) + "   X: " + toString(x));

app.Clear();
app.Draw(text);

app.Display();
}

return 0;
}


Joystick:
Thrustmaster 16.000M

If I look at the game controller settings in the control panel, the POV hat is mapped and does function.

Dravere

26

Graphics / setting a transparent color

« on: January 02, 2010, 01:51:28 am »

Do you mean, how to create a transparent color mask for an image?
-> http://www.sfml-dev.org/documentation/1.5/classsf_1_1Image.htm#e9a15fe9a4750295845b5ae081c2ec50

Dravere

27

Graphics / How do I do backgrounds? [Not Relevant anymore]

« on: January 01, 2010, 03:58:21 am »

I use 32 bit binaries of SFML on x64 Win7 with Nvidia card. I don't have the problem mentioned.

Dravere

28

General discussions / .exe not working on Windows 7

« on: January 01, 2010, 03:11:06 am »

32-bits binaries don't work on 64-bits architectures.

I run a lot of 32 bit programs on my 64 bit machine and they work with no problem
As long as you have an AMD64 architecture (note, even if there is AMD in the name, Intel uses it too, but names it Intel 64) you won't have problems running 32 bit binaries. Everything changes when you have an IA64 architecture, because there is no backward compability. But more or less all 64 bit desktops uses AMD64.

And there is also another problem, 64 bit binaries won't work with 32 bit binaries and vice versa.

Dravere

29

General discussions / Design and documentation

« on: December 31, 2009, 05:16:35 pm »

Constructors and operator=() aren't part of the language?

I didn't say anything against copy-constructor or operator=(), so I didn't understand your argument there. That's why I thought you meant pimpl.

I only said that there is an additional possibility of failures, that was my point and nothing more.

No it's not.  It's a different design.

Ok, it is a hack design or a bad design

Come back with some profiler results and I'll consider your argument.

This response is simply ... I don't know the best word for it in english ... perhaps it is better that way :|

You can also think a bit about performance without using a profiler. It is a fact that the windows heap that is used through new in C++ is optimized for bigger and slow for small objects.
That is also why Andrei Alexandrescu implements a small object allocator in his book Modern C++ Design. There are also other books pointing out, that the heap in C++ is very slow for small objects and you should better consider copying them.

But well ... if you simply want to ignore facts ... go on ...

C++ const objects are bitwise const, not logical const.  Security of what is lost?  We're talking about mutable members.

No we aren't or not only. When Laurent said he thought about using pimpl we changed to the use of pimpl for the whole class. Because only that way, you can have all those things that he listed

Dravere

30

General discussions / Design and documentation

« on: December 31, 2009, 04:08:13 pm »

Yes.  I don't understand how that is an issue?  Don't avoid features of the language for no reason.

It is not a feature of the language, it is a workaround to reduce dependencies and/or hide private details, which the language can't do by itself.

If you use it to avoid mutable or const_cast it is even more a hack than a solution. Don't forget that pimpl also adds several overhead. You need additional indirection, lose inlining and have additional heap allocation. Especially with small objects this can be a problem, because the heap often isn't optimized for small object but for big ones.

What do you mean?  The pointer itself is const, as in that it cannot change.  However, it is not a const pointer to a const instance, which means you can modify whatever it points to.

Exaclty and this is what he meant. You can change data even the object should be const. So you lose the security at compile time.

What's a pimpl_ptr?  A shared_ptr works fine...?

A pimpl_ptr probably is a class, that automaticly creates a new instance when it is copied. So you don't need to implement your own copy-constructor or operator=.

Dravere