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

Kolja · « **Reply #90 on:** February 08, 2011, 10:57:24 am »

Quote from: "Hiura"

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

Yeah, OK, but I doubt you will find a solution that pleases everyone. I presented my point of view and, as I said, it's a solution that is used by commercial applications as well. Maybe I'll take a look at Source engine games today, see what they do.

Quote from: "Hiura"

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).

Of course, but you don't have to reload anything. So it can be done in a fast way, but there might be situations where it could take more time, depending on ones application.

Quote from: "Hiura"

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).

Huh, okay. I always blamed OS X's poor gaming performance on the non-exclusivity, guess I'll have to shift my blame to the drivers then ;-)

Quote from: "Hiura"

@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.

I guess Ceylo means capturing Cmd+Tab yourself, switching to desktop mode, release the screen, and resend a Cmd+Tab-Event to the system.

And to clarify my rooting for solution A, I always have something open while playing a game. Under normal circumstances I never have to resize a window, because the window manager remembers all my preferences, but when a fullscreen application screws it up it's really a hassle to get all windows back to their optimum sizes.

Hiura · « **Reply #91 on:** February 08, 2011, 12:26:04 pm »

Quote from: "Kolja"

I guess Ceylo means capturing Cmd+Tab yourself, switching to desktop mode, release the screen, and resend a Cmd+Tab-Event to the system.

Could be a solution, I'll try that. (But it won't enable trackpad gesture to switch app. So I'm still looking for something better if it exists)

Quote from: "Kolja"

And to clarify my rooting for solution A, I always have something open while playing a game. Under normal circumstances I never have to resize a window, because the window manager remembers all my preferences, but when a fullscreen application screws it up it's really a hassle to get all windows back to their optimum sizes.

Yes, that's my main concern too.

Ceylo · « **Reply #92 on:** February 08, 2011, 12:58:40 pm »

Quote from: "Hiura"

@Ceylo,

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

Oh... ok. It doesn't want to switch to another app or is it only the display that's locked for the current app? You get no "deactivated" notification?

Ceylo · « **Reply #93 on:** February 08, 2011, 01:03:57 pm »

Quote from: "Kolja"

I guess Ceylo means capturing Cmd+Tab yourself, switching to desktop mode, release the screen, and resend a Cmd+Tab-Event to the system.

Uh... well, no. I wasn't thinking of such a thing. It becomes too heavy to handle and you may forget some ways of switching between apps. The best way is still catching the notification telling that the app lost focus, if possible.

Hiura · « **Reply #94 on:** February 08, 2011, 01:18:53 pm »

Quote from: "Ceylo"

Oh... ok. It doesn't want to switch to another app or is it only the display that's locked for the current app? You get no "deactivated" notification?

Well, I don't know exactly but it seems like application switch is completely deactivated from the OS. And the documentation doesn't specify any notification. So I guess it really authorizes only one app on the screen.

Ceylo · « **Reply #95 on:** February 08, 2011, 01:54:03 pm »

Hum ok. I've looked at the GLFullscreen sample provided by Apple and there is the same issue.

So... from what I understand, the issue is that icons and windows will be resized if you change the screen resolution while not capturing the screen.

As CGDisplaySiwtchToMode() is deprecated since Mac OS X 10.6, I had been looking for another way of setting a different screen resolution. And I had found one (I've just been noticing there's CGDisplaySetDisplayMode() now, but that's another point...). This solution is to keep the native screen resolution, but change the OpenGL buffer size.

Here is it, section "Controlling the Back Buffer Size".

This lets you choose ANY resolution (even non common ones) but as a drawback, I think you also have to properly handle how the rendering is supposed to fit your screen (keep unused areas or not). I haven't done any deep researches toward this solution, but it could fit your needs.

It allows any "screen" resolution and you don't need to capture the screen.

Kolja · « **Reply #96 on:** February 08, 2011, 03:09:23 pm »

Wouldn't such a solution imply that every frame would have to be scaled accordingly? Are the performance impacts of that small enough?

Otherwise, nice find!

Hiura · « **Reply #97 on:** February 08, 2011, 03:50:29 pm »

Good news first :
That's work pretty well! I can switch app without any window resized!

I didn't have any performance issue with an heavy benchmark (posted here with little modifications)

Bad news :
The mouse position given by sf::Event are not good – I have to modify this part to recompute the mouse coordinate.

So be patient a little bit more.

zenkimoto · « **Reply #98 on:** February 09, 2011, 07:25:57 am »

Hi All! I downloaded the latest copy of SFML 2.0 from the SVN repository and loaded it up with CMake. Then I opened it up with XCode just fine. However, when I try to compile I get the following errors:

Code: [Select]


ignoring file /Users/username/Desktop/sfml2/extlibs/libs-osx/Frameworks/sndfile.framework/sndfile, file was built for unsupported file format which is not the architecture being linked (i386)
Undefined symbols for architecture i386:
  "_sf_seek", referenced from:
      sf::priv::SoundFile::Seek(float)in SoundFile.o
  "_sf_write_short", referenced from:
      sf::priv::SoundFile::Write(short const*, unsigned long)in SoundFile.o
  "_sf_read_short", referenced from:
      sf::priv::SoundFile::Read(short*, unsigned long)in SoundFile.o
  "_sf_close", referenced from:
      sf::priv::SoundFile::~SoundFile()in SoundFile.o
      sf::priv::SoundFile::~SoundFile()in SoundFile.o
      sf::priv::SoundFile::OpenWrite(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int, unsigned int)in SoundFile.o
      sf::priv::SoundFile::OpenRead(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)in SoundFile.o
      sf::priv::SoundFile::OpenRead(void const*, unsigned long)in SoundFile.o
  "_sf_open", referenced from:
      sf::priv::SoundFile::OpenWrite(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int, unsigned int)in SoundFile.o
      sf::priv::SoundFile::OpenRead(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)in SoundFile.o
  "_sf_strerror", referenced from:
      sf::priv::SoundFile::OpenWrite(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int, unsigned int)in SoundFile.o
      sf::priv::SoundFile::OpenRead(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)in SoundFile.o
      sf::priv::SoundFile::OpenRead(void const*, unsigned long)in SoundFile.o
  "_sf_open_virtual", referenced from:
      sf::priv::SoundFile::OpenRead(void const*, unsigned long)in SoundFile.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status

Nothing seemed to work and then I found out that the main culprit was sndfile.framework. From reading from earlier posts, I decided to try this command:

Code: [Select]


file /Users/username/Desktop/sfml2/extlibs/libs-osx/Frameworks/sndfile.framework/sndfile

And this is what I get: ASCII text, with no line terminators

I decided to open up the sndfile.framework and noticed that links/aliases didn't show up. They were just plain text files. So I recreated them to no avail. Atleast the "file" command recognizes it as data now, but it does not see a framework. Anyone fix this problem or have any ideas? I'm at a loss....

Thanks!

Kolja · « **Reply #99 on:** February 09, 2011, 10:17:34 am »

Hi!

Yeah, the symlinks are broken and not yet fixed for some reason. You need to link sndfile.framework/sndfile to, or replace it with, sndfile.framework/Versions/A/sndfile (paths from my memory, but you should be able to correct them if I'm wrong).

sndfile.framework should point to sndfile.framework/Versions/Current, which in turn should point to sndfile.framework/Versions/A/sndfile, but replacing directly works just as well. Doing this by hand should only be a temporarily necessary solution anyhow.

Hiura · « **Reply #100 on:** February 09, 2011, 12:52:00 pm »

I just committed a bunch of modifications, fullscreen should work now.

You might need to delete the cache of CMake and rebuild the Makefile.

Ceylo · « **Reply #101 on:** February 09, 2011, 01:31:42 pm »

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.

PS: if you want a piece of code giving the right position and size for the rendering area according to another area it's supposed to fit in, you can (if you wish) have a look at Movie::ResizeToFrame() in Movie.cpp of the sfeMovie project.

Hiura · « **Reply #102 on:** February 09, 2011, 01:55:03 pm »

Quote from: "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 don't know. I had such behaviour since ever (with Windows and Linux).

For example, most games will stretch the image to fit the screen if the aspect ratio of the video mode is not screen ration.

If SFML on Windows and Linux preserve the ratio then I'll do that for OSX too. Otherwise I won't – I rather prefer let the user choose a correct video mode or do something about the stretching in his own code than have a different behaviour from SFML on other OSes.

Ceylo · « **Reply #103 on:** February 09, 2011, 08:17:31 pm »

Uh.. ok. I thought Windows and Linux were not filling the whole screen too (if the ratio was different). Sooo... ok, it's up to you.

Hiura · « **Reply #104 on:** February 09, 2011, 08:55:53 pm »

I tested this afternoon how a SFML window in fullscreen is rendered on Linux. Currently, it fill the whole screen too.

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

On another topic, I realise two things while testing event (again).

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

> I used sf::Text to display some stuff and I encounter the same problem I had some times ago : http://www.sfml-dev.org/forum-fr/viewtopic.php?p=30752#30752

The solution is still the same, if I had '-D_GLIBCXX_FULLY_DYNAMIC_STRING=1' to CMAKE_CXX_FLAGS it works fine.

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.)