Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML 2 for OS X comes true!  (Read 103636 times)

0 Members and 2 Guests are viewing this topic.

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
SFML 2 for OS X comes true!
« Reply #75 on: February 05, 2011, 03:34:46 pm »
Quote
4. The arrow keys produce a text entered event but I suppose they should not.
This one should be OK now. Thanks to your workaround in SFML 1.x  :wink:

Quote from: "Ceylo"
1. When using fullscreen mode, you can only use the desktop video mode. Any other video mode will fail, saying it's invalid.
You should use sf::VideoMode::GetFullscreenModes() modes for fullscreen app – but there is something wrong with my implementation of this function : sf::VideoMode::GetFullscreenModes().size() is 1. I'm working on it.  :wink:
SFML / OS X developer

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
SFML 2 for OS X comes true!
« Reply #76 on: February 05, 2011, 08:38:37 pm »
I have this idea but I don't know if it is consistent with SFML's behaviour on other OSes. I was thinking about multiscreen and I came with a (plausible) method to give the user a way to take advantage of a secondary screen (or more).

The idea is that GetFullscreenModes contains all available modes for all screens.

For example a user has a main screen of resolution 1440x900 and a (better) secondary screen of resolution 1920x1080, the app could choose to create a fullscreen window of 1920x1080 and display it on the best screen.

For each mode in GetFullscreenModes that is available for the main screen the window would be displayed here otherwise it would be displayed on the first secondary screen where the mode is available. In fact, a SFML user wouldn't be able to choose programmatically a specific screen unless we change the public API.

But I don't really know : is it «overkill» or out of scoop ? I don't want to be too different from Linux or Windows about user experience.
SFML / OS X developer

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
SFML 2 for OS X comes true!
« Reply #77 on: February 06, 2011, 01:31:06 am »
This is clearly out of scope at the moment. Until SFML officially handles multiple monitors, you shouldn't try to do anything else than using the primary display and assuming it is the only one that exists, in your implementation.
Laurent Gomila - SFML developer

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
SFML 2 for OS X comes true!
« Reply #78 on: February 06, 2011, 01:33:17 am »
ouki doki  :)
SFML / OS X developer

SkyJedi

  • Full Member
  • ***
  • Posts: 185
    • MSN Messenger - NicolasAllemand2@hotmail.com
    • AOL Instant Messenger - SkyJedi01
    • Yahoo Instant Messenger - fuyayaa
    • View Profile
    • http://www.black-heaven.fr/devblog
SFML 2 for OS X comes true!
« Reply #79 on: February 06, 2011, 11:37:44 am »
Hey :)

I built the lib on OS X 10.6; I did exactly what you said on your post (first page); but there are errors :
http://img695.imageshack.us/img695/1862/capturedcran20110206113.png


And here's my code :
Code: [Select]
#include <stdio.h>
#include <SFML/Window.hpp>

int main (int argc, const char * argv[]) {
    // insert code here...
    printf("Hello, World!\n");
    return 0;
}

(just added the include)

Can you help me please ? =/

EDIT :
Code: [Select]
mac-pro-de-nico:~ nico$ find /usr/ -name climits && find /Developer/ -name climits
/usr//include/c++/4.0.0/climits
/usr//include/c++/4.2.1/climits
/usr//include/c++/4.2.1/tr1/climits
/Developer//SDKs/MacOSX10.5.sdk/usr/include/c++/4.0.0/climits
/Developer//SDKs/MacOSX10.6.sdk/usr/include/c++/4.0.0/climits
/Developer//SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/climits
/Developer//SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/tr1/climits


And there are 102 errors in Release; 34 in debug.

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
SFML 2 for OS X comes true!
« Reply #80 on: February 06, 2011, 12:09:42 pm »
SFML / OS X developer

SkyJedi

  • Full Member
  • ***
  • Posts: 185
    • MSN Messenger - NicolasAllemand2@hotmail.com
    • AOL Instant Messenger - SkyJedi01
    • Yahoo Instant Messenger - fuyayaa
    • View Profile
    • http://www.black-heaven.fr/devblog
SFML 2 for OS X comes true!
« Reply #81 on: February 06, 2011, 12:45:54 pm »
Nope, already tried it :/

EDIT:
weird cause this http://www.mediafire.com/?3dxc2vs0wbd3c3n works fine.

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
SFML 2 for OS X comes true!
« Reply #82 on: February 06, 2011, 02:59:17 pm »
Can you upload your project ?
SFML / OS X developer

SkyJedi

  • Full Member
  • ***
  • Posts: 185
    • MSN Messenger - NicolasAllemand2@hotmail.com
    • AOL Instant Messenger - SkyJedi01
    • Yahoo Instant Messenger - fuyayaa
    • View Profile
    • http://www.black-heaven.fr/devblog
SFML 2 for OS X comes true!
« Reply #83 on: February 06, 2011, 03:32:10 pm »

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
SFML 2 for OS X comes true!
« Reply #84 on: February 06, 2011, 04:25:52 pm »
Well, it was tricky – I've updated my post on first page, thanks for your messages. :)

First, rename your main.c to main.cpp – this way Xcode will search also C++ headers.

Then, open your target info panel and go to the build tab. Here you've add /usr/local/insclude/ to search path only for release configuration. So select All Configuration and add /usr/local/insclude/ to header search path.

Enjoy  :wink:
SFML / OS X developer

SkyJedi

  • Full Member
  • ***
  • Posts: 185
    • MSN Messenger - NicolasAllemand2@hotmail.com
    • AOL Instant Messenger - SkyJedi01
    • Yahoo Instant Messenger - fuyayaa
    • View Profile
    • http://www.black-heaven.fr/devblog
SFML 2 for OS X comes true!
« Reply #85 on: February 06, 2011, 04:59:51 pm »
Thank you very much, works fine now =D

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
fullscreen mode
« Reply #86 on: February 07, 2011, 06:42:50 pm »
I've got a dilemma so I need your help to choose between the two solutions I've found so far about how implement fullscreen for non-desktop video mode. (A 'desktop-mode' window in fullscreen produces no issue.)

The first solution is to «capture» the screen (which allow only one app to use it, the user cannot switch to another app). The only way to use another app is to close the window which will «release» the screen.

To use this technique and have the window displayed I must set its level to CGShieldingWindowLevel, which is not recommended. [2]

I didn't see any issue with this and I think it's because I don't use fullscreen context strictly speaking (I use one big window that has the size of the screen [1] ). So this should work.

But as said before, it doesn't allow the user to switch to another application – which is very bad, I think.

The second solution doesn't use display capture thus the user can use cmd+tab to switch to his mail app for example. But it has also a bad behaviour : when an app change the screen size without capturing the display some other app's windows may be resized (Finder, Mail, iTunes, .... almost every app in fact). Which is very bad for user experience (who wants to use an app that resize every window or rearrange your desktop files ? ).

Until now I haven't found a way to prevent windows to resize when changing screen size. (Maybe someone else knows ?)

So I ask you, which one should I use ?
A) no window resized but cannot switch from app.
B) can switch to another app but the windows might be resized.


–––––––––––––––––––

Further reading – not required to follow the discussion :


[1] the doc says here (at the bottom) the following about fullscreen window vs fullscreen context :

Quote from: "The doc"
Note: It’s not necessary to capture a display to do full-screen drawing. Another approach is to create and draw into a borderless window the size of the display. This approach allows you to use all the features of the windowing system. It also plays well with the rest of the operating system, and it reduces the complexity of display handling (for example, you don’t have to worry about mirrored displays). With this approach, you can receive error alerts that might be missed with a captured display. You can also use Command-Tab to change applications with this approach. On systems with modern graphics hardware, drawing performance in a full-screen window is almost as fast as a full-screen drawing context


[2] here

Quote from: "The doc"
This function returns a value that is sometimes used to position a window over the shield window for a captured display. Attempting to position a window over a captured display may be unsuccessful—or it may present undesirable results such as illegible or invisible content—because of interactions between full-screen graphics (such as OpenGL full-screen drawing contexts) and the graphics hardware. Because of these limitations, this technique is not recommended.


PS : two days on it – I'm getting crazy ...

EDIT : typo
SFML / OS X developer

Kolja

  • Newbie
  • *
  • Posts: 22
    • View Profile
SFML 2 for OS X comes true!
« Reply #87 on: February 07, 2011, 07:21:15 pm »
Having played a bit of StarCraft 2 over the last days, I would suggest option A, the one used by SC2.
It's a bit weird when Cmd+Tab doesn't work, but we're mostly making games or game-like applications so most people are used to such behavior.
Switching to a windowed mode can be implemented via a shortcut, so that can be used if you want to access your IM while playing. And AFAIK (please correct me if I'm wrong), such a switch can be done without having to reload all resources (e.g. textures), so it's still relatively fast.

On a slightly unrelated note: OS X still does not offer exclusive access to the video hardware, right? Because the window manager never shuts off hardware acceleration, like Win7 does for example.

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
SFML 2 for OS X comes true!
« Reply #88 on: February 07, 2011, 07:48:34 pm »
I don't really understand why you don't use this way:

1.
- capture the screen
- save the desktop video mode
- switch to the wished video mode

2. when the user uses Cmd+Tab or wants to exit the app:
- switch back to the desktop mode
- release the screen

when the user comes back again to your app, do again the first step.
Isn't it possible? And doesn't it fix both issues?
Want to play movies in your SFML application? Check out sfeMovie!

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
SFML 2 for OS X comes true!
« Reply #89 on: February 08, 2011, 10:10:35 am »
Quote from: "Kolja"
Switching to a windowed mode can be implemented via a shortcut, so that can be used if you want to access your IM while playing.
Yes, but not all applications want to do that (it might be a very bad user experience in some cases). So

Quote from: "Kolja"
And AFAIK (please correct me if I'm wrong), such a switch can be done without having to reload all resources (e.g. textures), so it's still relatively fast.
Not always : sometime, depending on the screen size, you might want to load different image files (higher/lower resolution).

Quote from: "Kolja"
On a slightly unrelated note: OS X still does not offer exclusive access to the video hardware, right?
I think it do offer such access but I don't know how (with Quartz framework maybe).

@Ceylo,

The problem is that when you capture the screen cmd+tab won't work at all.

Currently I implement the option B) kind of like you do in 1.6 except I use NSWindow's delegate methods (windowDidBecomeKey/ResignKey) instead of NSApplication notifications.
SFML / OS X developer