Author Topic: SFML 1.3 and OS X (Read 48280 times)

crawshaw · « **Reply #60 on:** September 20, 2008, 02:12:18 pm »

Try calling App.Clear() before you call App.Draw().

d.

coral · « **Reply #61 on:** September 20, 2008, 02:12:40 pm »

Yeah, these are only for testing purposes. I can throw both release and build.

Anyhow, the problem you saw in my post over this is done with the Release configuration!

coral · « **Reply #62 on:** September 20, 2008, 02:14:47 pm »

Ah, App.Clear(); solved the problem!

Ceylo · « **Reply #63 on:** September 20, 2008, 02:27:19 pm »

Quote from: "http://www.sfml-dev.org/tutorials/1.4/graphics-window.php"

The only difference here is that we've added a call to Clear, so that the screen gets filled with black instead of remaining with random pixels.

Refer to the tutorials for the SVN version !

Ceylo · « **Reply #64 on:** September 25, 2008, 07:41:27 pm »

Hey all !

I have some (and good) news for you.
I've worked for the few past days on reorganizing the code and... the full screen mode !

So, yeah, that's it, the first version supporting full screen mode

. It's been sent on the SVN repository.

There are certainly a few missing things but it should be usable. So... have fun !

Note : I also added a Development build style in the Xcode project. This is for my personal use. You may still use the Debug and Release build styles.
The main point between the Development and Debug build style is that the Debug one builds UB.

coral · « **Reply #65 on:** September 25, 2008, 08:36:14 pm »

OH, NICE!!!
You are doing a great work on this port!

Will try it out right now!

coral · « **Reply #66 on:** September 25, 2008, 08:40:24 pm »

Hey, if malloc.h isn't used at all, won't you consider removing it from the includes?!

EDIT: i uploaded one of my builds.

Ceylo · « **Reply #67 on:** September 25, 2008, 08:40:35 pm »

Hehe, thanks !

I'm just a bit afraid... I think i forgot something in my work, but I can't find out what :mrgreen: . I hope it's not too important...

Ceylo · « **Reply #68 on:** September 25, 2008, 08:47:59 pm »

Quote from: "coral"

Hey, if malloc.h isn't used at all, won't you consider removing it from the includes?!

Laurent told me he would tell the author about this problem (not me

), so that he fixes this.

dorkfish · « **Reply #69 on:** September 26, 2008, 05:09:09 am »

Ceylo, you are doing amazing work on the Mac port, and I'm extremely grateful for it.

I had been considering using Clanlib for a while, due to its maturity, but I think I'm going to stick with SFML since the Mac port is so far along.

What do you have left to do on your to-do list? I should be able to help with some small stuff, like implementing missing keys.

Ceylo · « **Reply #70 on:** September 26, 2008, 08:36:33 pm »

Quote from: "dorkfish"

Ceylo, you are doing amazing work on the Mac port, and I'm extremely grateful for it. I had been considering using Clanlib for a while, due to its maturity, but I think I'm going to stick with SFML since the Mac port is so far along.

Hey thanks

! It's also quite interesting for me because I never worked on a bigger project (remember I'm an eighteen-year-old teen !) and to make my own games with it.

Quote from: "dorkfish"

What do you have left to do on your to-do list? I should be able to help with some small stuff, like implementing missing keys.

My up to date to-do list :

Quote

TO DO:
- mouse position setting function > done
- joysticks handling
- handle MouseEntered and MousedExited events > done
- handle full screen mode > done

TO FIX:
- closing all the SFML windows may leave your app blocked (no more event handling)
- SFML windows cannot be used properly in Cocoa applications (just messing up everything in the run loop)
- there are missing keys (as an Apple keyboard does not have the same keys as an PC's one)
- not all the keys (text events are not concerned) are language independant
- using the '^' key and 'e' key produces an 'e' instead of 'ê' (same for other characters that need two keys)
- correct WindowImplCocoa::SetIcon() > done
- fix everything else I may have forgotten

As far as the missing keys are concerned, the point is the 'Key::Code's are based on a PC keyboard. This means that if I add the Mac keys, these will (mostly) never be used on a PC keyboard. Same with PC keys on a Mac keyboard. So I have to talk about this to Laurent, but for now there is no way.

Now about the '^' key and such... I didn't find any way till now. I saw the Camino browser did it, but I can't find out how they did (the source code is available). The thing is I get the virtual code but not the characters, and as the virtual code is not independant from the keyboard layout, I can't use it.

No way for now too in order not to leave the application blocked when you close all the windows.

And there may be ways to use SFML windows in Cocoa applications but this is not possible right now.

dorkfish · « **Reply #71 on:** September 27, 2008, 01:12:38 am »

Quote

As far as the missing keys are concerned, the point is the 'Key::Code's are based on a PC keyboard. This means that if I add the Mac keys, these will (mostly) never be used on a PC keyboard. Same with PC keys on a Mac keyboard. So I have to talk about this to Laurent, but for now there is no way.

I haven't looked at the SFML source in a while, so my memory of it is a little fuzzy, but maybe what could be done is to create a KeyboardLayout abstract base class, and then create PCKeyboardLayout and MacKeyboardLayout subclasses, and a final KeyboardManager class for instantiating the proper KeyboardLayout subclass for a given system, allowing us to implement keyboard handling in the optimal manner for each OS. This would give us the advantage that creating new keyboard layouts for other operating systems/devices, like the Pandora (or the GP2X, with USB keyboard), should be easier later on.

Quote

Now about the '^' key and such... I didn't find any way till now. I saw the Camino browser did it, but I can't find out how they did (the source code is available). The thing is I get the virtual code but not the characters, and as the virtual code is not independant from the keyboard layout, I can't use it.

If I'm understanding this blog entry correctly, what we should be using is UCKeyTranslate() (if you're not adverse to using Carbon, that is). It seems like the easiest way to get a character from a keycode, to me.

Ceylo · « **Reply #72 on:** September 27, 2008, 12:55:01 pm »

Quote from: "dorkfish"

I haven't looked at the SFML source in a while, so my memory of it is a little fuzzy, but maybe what could be done is to create a KeyboardLayout abstract base class, and then create PCKeyboardLayout and MacKeyboardLayout subclasses, and a final KeyboardManager class for instantiating the proper KeyboardLayout subclass for a given system, allowing us to implement keyboard handling in the optimal manner for each OS. This would give us the advantage that creating new keyboard layouts for other operating systems/devices, like the Pandora (or the GP2X, with USB keyboard), should be easier later on.

Uh... I've to talk about this with Laurent

.

Quote from: "dorkfish"

If I'm understanding this blog entry correctly, what we should be using is UCKeyTranslate() (if you're not adverse to using Carbon, that is). It seems like the easiest way to get a character from a keycode, to me.

I'm adverse to using Carbon. First because it cannot be used for 64 bits applications, and second because Carbon will probably soon be removed (understand Mac OS X 10.6 or Mac OS X 10.7). I'm not positive about this last point, but what I know is that the Cocoa framework will progressively support what was only possible with Carbon.

dorkfish · « **Reply #73 on:** September 30, 2008, 07:50:43 pm »

Okay, I think I might have found the solution for Cocoa key event handling: Cocoa Event Handling Guide. You might have seen this already, Ceylo, but it's new to me so I thought I'd share it here. I've only given it a cursory glance so far, so I'll comment on it when I have a chance to read it more closely.

Ceylo · « **Reply #74 on:** September 30, 2008, 09:28:31 pm »

Yep, I've already looked at this, but it didn't help me.

I tried to implement the NSTextInput protocol using a custom view (-interpretKeyEvents: and all that), but I got nothing more than what I now get with my way of handling events.