SFML 2 for OS X comes true!

[Ceylo]

If Laurent want to change this behaviour I'll do the same. So you can make Laurent change his mind. ;-)

Well.. I don't really care until the behavior is the same as with Windows and Linux. I thought it was different .

> I cannot make keys combination (like ^ and a produce â) work. Ceylo, Did you succeed in 1.6 ?

Yup. I let NSText interpret these. See GLKit.mm line ~356.

[Laurent]

When I set 1024x768 I expect to have black unused areas on the left and right of my screen because of the different ratio

I've never heard of that before, when you open a fullscreen window it covers the full screen. The OS won't handle the aspect ratio for you (unless there's something very specific built in OS X).

So my question is : Laurent, can I add this to the CMake conf or is it not a good idea ? (I don't know what's good/bad/not recommended about this kind of stuff.)

Add whatever is necessary. I don't know much about this flag and why it makes things work, but if it's a bug on your side you should rather fix it, and if it's a bug in OS X gcc then there's nothing you can do except adding the flag. But if you do so, make sure that you restrict it as much as possible (if the bug happens only on OS X and with a certain version of gcc, you should write this condition in the CMake makefile).

[Groogy]

When I set 1024x768 I expect to have black unused areas on the left and right of my screen because of the different ratio

I've never heard of that before, when you open a fullscreen window it covers the full screen. The OS won't handle the aspect ratio for you (unless there's something very specific built in OS X).

I think it's the screen that does it. It is done on any 16:9 screens when changing to a low res 4:3.

[devlin]

Fullscreen mode is working fine.. except that it fills the whole screen even when it should not.

When I set 1024x768 I expect to have black unused areas on the left and right of my screen because of the different ratio, but the screen is completely used. Thus the rendered image is stretched.

This kind of functionality is not very common apart from some TV settings  where the TV is running at its native resolution and you feed it a lower resolution image.

You can mimic this behaviour by setting the fullscreen window to run at the screens native resolution and then setting up a glPerspective with 1:1 ratio and a centered viewport and/or scissor rectangle with the "desired" resolution. (i.e. a 1024x768 view on a 1920x1200 resolution fullscreen window).

[Hiura]

Add whatever is necessary. I don't know much about this flag and why it makes things work, but if it's a bug on your side you should rather fix it, and if it's a bug in OS X gcc then there's nothing you can do except adding the flag.

I'll try to do some more research on it, but as I'm not writing any code about sf::String nor using special stuff from the STL we can assume this bug has nothing to do with me in particular, right ? I'd like to be sure on that kind of things. =)

[Laurent]

I'll try to do some more research on it, but as I'm not writing any code about sf::String nor using special stuff from the STL we can assume this bug has nothing to do with me in particular, right ? I'd like to be sure on that kind of things. =)

Yep, but this means that there's a bug in gcc on OS X, which is also very unlikely. So you have to check and make sure in any case

[Ceylo]

When I set 1024x768 I expect to have black unused areas on the left and right of my screen because of the different ratio

I've never heard of that before, when you open a fullscreen window it covers the full screen. The OS won't handle the aspect ratio for you (unless there's something very specific built in OS X).

If you open a fullscreen window on Mac OS X, it will indeed fill the whole screen. But the screen frame does not always fills the "real screen" frame, especially when the ratio of the wished resolution is different from the native one. Thus your "fullscreen" window will not fill the real screen. This is handled natively as far as I know (note that when choosing the screen resolution, Mac OS X lets you choose between "normal" and "wide" mode).

Now, with Hiura's solution, the screen resolution does not change, thus the OS doesn't make any change on the "virtual screen" frame. That's why I said it was different from what I had expected.

However, as Hiura said, on Windows and Linux there's no such behavior, and in order for SFML to be the most cross-platform as possible, I agree with keeping this "odd" (to me) behavior. It'll make cross development much easier.

[Hiura]

Yep, but this means that there's a bug in gcc on OS X, which is also very unlikely. So you have to check and make sure in any case

Well, from what I've read it is a bug in gcc. =/ I've sent a bug report to Apple so we'll see what they'll tell me. In the meanwhile I won't change the cmake conf but put an note on the "tutorial" post (first page).

[Hiura]

Yup. I let NSText interpret these. See GLKit.mm line ~356.

I did found NSText yesterday but I was trying to call keyDown on it – silly me. Anyway, thanks for your help. Now it should work properly.

I've also updated the KeyPressed/Released event so that the Z key is really the Z key on the user keyboard. I'm no more relying only on the physical code of the key.

And I added support for 'modifier' keys (System, Alt, Control, Shift). Could anyone confirm that works fine or not. I don't know if it works only for my keyboard. (I know only that key repeat won't work on these keys. Is it the same on Win/Unix ?)

You can use this code to test everything.

Now I still have an unbind key on my keyboard (' on ch-fr layout, ) on fr layout I think). That recalls me a discussion (and the related task). Laurent, still no decision on it ? (Just to know ;-) )

Maybe we have already discussed the following but I've got the memory of a goldfish so I apology if we did.  

What about adding a System field to sf::Event::KeyEvent ? On OS X it would be very logical to have this. And why not on Unix/Win ?

[Ceylo]

As for me with the latest sources from the SVN repository and your sample code :

If I use the resize button and don't go outside and inside of the OpenGL area, mouse moved event do no more work. Note that I first thought that you had forgotten something as for resizing the OpenGL view but it was just because you hadn't handled the Resized event.

As for the keyboard, every text event works fine, but not the key pressed events. Here is what I get in the console:
@ key gives me ~
&é"'(§è!çà gives 1234567890 (for the keys you handle)
) gives nothing
- gives =
^ gives [
$ gives ]
ù gives '
`gives \
= gives /
: gives .
; gives ,
, gives nothing
< gives -

[Hiura]

If I use the resize button and don't go outside and inside of the OpenGL area, mouse moved event do no more work.

I hate that kind of bug! Anyway, thank you for the bug report. It should be ok now. ;-)

As for the keyboard, every text event works fine, but not the key pressed events. Here is what I get in the console:

Ok, that the behaviour I expected. I know that it's not the best key binding ever but at least there is only one unbind key. With the current sf::Key::Code enum I cannot do more because I cannot rely on the printable character given by the key down/up event because if shift is down then I cannot get the native key character (on some keyboard ; is the shifted character of , for example). (Cocoa doesn't allow me to retrieve the 'unshifted' character of the pressed/released key.)

Now about &é"'(§è!çà giving 1234567890 : it's because on the US keyboard layout these keys are 1234567890. In fact I've only found 3-4 layouts that don't have numerical keys there.

Do the ctrl, cmd, alt and shift keys work (KeyPressed/KeyReleased events)?

[Ceylo]

If I use the resize button and don't go outside and inside of the OpenGL area, mouse moved event do no more work.

I hate that kind of bug! Anyway, thank you for the bug report. It should be ok now. ;-)

Yup it's ok now ^^.

(Cocoa doesn't allow me to retrieve the 'unshifted' character of the pressed/released key.)

Actually.. there is both -[NSEvent characters] and -[NSEvent charactersIgnoringModifiers]. So I don't really understand what you mean.

Now about &é"'(§è!çà giving 1234567890 : it's because on the US keyboard layout these keys are 1234567890. In fact I've only found 3-4 layouts that don't have numerical keys there.

That's why your keys should be deduced from the characters rather than the key code whenever you can. It's the only way to get the translated character and not care about each layout.

Do the ctrl, cmd, alt and shift keys work (KeyPressed/KeyReleased events)?

They do .

[Hiura]

Actually.. there is both -[NSEvent characters] and -[NSEvent charactersIgnoringModifiers]. So I don't really understand what you mean.

Unfortunally, as the doc says, shift are not ignored.

charactersIgnoringModifiers
Returns the characters generated by the receiving key event as if no modifier key (except for Shift) applies.

I know : it's stupid!

Do the ctrl, cmd, alt and shift keys work (KeyPressed/KeyReleased events)?

They do .

Great =D

[Ceylo]

Actually.. there is both -[NSEvent characters] and -[NSEvent charactersIgnoringModifiers]. So I don't really understand what you mean.

Unfortunally, as the doc says, shift are not ignored.

charactersIgnoringModifiers
Returns the characters generated by the receiving key event as if no modifier key (except for Shift) applies.

I know : it's stupid!

Aaaah.. I had never noticed this ><. Indeed that's annoying. But even with this issue, don't you think it's still better to rely on the information provided by -characters or -charactersIgnoringModifiers ? Because right now there are a lot of wrong keys... :/

[Hiura]

Aaaah.. I had never noticed this ><. Indeed that's annoying. But even with this issue, don't you think it's still better to rely on the information provided by -characters or -charactersIgnoringModifiers ? Because right now there are a lot of wrong keys... :/

Well, on my kb if I use only -charactersIgnoringModifiers to determine the 'sf::key' I would have about 8-9 unbound keys or key in conflict with some others.

I choose this way to handle keys because it has only one unbound key on most keyboards. It's the best solution I've found so far but if you have some idea I'm very interested, of course.

Maybe we can found another way to give key event to the SFML user... I don't know.