Messages

1

General discussions / SFML 2.0 Mac OSX in App Bundle

« on: March 06, 2011, 03:57:45 pm »

It depends : is it a high or low library ?

SFML's competing library SDL checks for the Application Bundle.  So does that mean that SDL is a higher level than SFML?   I still feel that being a cross platform library you should hide the fact that it's cross platform to the user of the library.  I should have a single code base that can compile various platforms.

I was in fact saying that you also need a function to get the resources path on Unix.
So you would have [...]

I still have to agree with Ceylo.  I, as a user of SFML, would not want to see that.  

There's two aspect here : compilable and runnable. The first one is always true with SFML but no the second. Now these two are so close that we have to define with Laurent where SFML stops.

I think I'm starting to understand what you mean.  The resources path is kind of like a configuration issue.  I think other people like Laurent should chime in.

All in all, it's up to you guys as the developers of SFML to decide.  :-)

2

General discussions / SFML 2.0 Mac OSX in App Bundle

« on: March 06, 2011, 03:12:48 am »

I agree : it would be shorter for the user. Notice I said 'shorter' and not 'easier' as it is not very complicated at all (just copy/past the code above). But the problem persists with Unix : a "good" application will be installed in /usr subdirectories (bin/share/... I don't know exactly), won't it ?

I see what you mean.  True, it's not complicated.  I guess it just means that the user of SFML would need to be conscious of which platform they are using.  But doesn't that defeat the purpose of a cross platform library?  I would think that you would want the same code base working for all platforms. For example, if I wrote some sample code for you and my system was Windows.  You, say having an OS X system, couldn't just take the code and compile it.  You would need to modify the code in order to make it run.

I also think you're thinking in terms of UNIX.  For most OS X applications, users do not install anything in /usr/share, etc.  I usually am wary of applications that come with an installer rather than a bundle.

3

General discussions / SFML 2.0 Mac OSX in App Bundle

« on: March 06, 2011, 03:03:40 am »

Darn, I wasn't thinking... I thought the working directory wasn't supposed to change when I mentioned that compromise.  I can see how it really isn't.

Ah well, I guess it's up to Hiura.  :-)  For the time being, I'll just check for the resources directory.

4

General discussions / SFML 2.0 Mac OSX in App Bundle

« on: March 05, 2011, 08:21:22 pm »

Here I am adding fuel to the flame war.  Haha :-)

Anyways, I just wanted to add one more thing.  I checked the SDL library to see how they handle Mac OS X bundles, they essentially check to see if the application is a bundle, if not then fall back on the working directory.

Let me copy and paste the code here:

Code: [Select]


#ifdef __APPLE__
#import <Foundation/Foundation.h>

#include "SDL_rwopsbundlesupport.h"

/* For proper OS X applications, the resources are contained inside the application bundle.
 So the strategy is to first check the application bundle for the file, then fallback to the current working directory.
 Note: One additional corner-case is if the resource is in a framework's resource bundle instead of the app.
 We might want to use bundle identifiers, e.g. org.libsdl.sdl to get the bundle for the framework,
 but we would somehow need to know what the bundle identifiers we need to search are.
 Also, note the bundle layouts are different for iPhone and Mac.
*/
FILE* SDL_OpenFPFromBundleOrFallback(const char *file, const char *mode)
{
    FILE* fp = NULL;

// If the file mode is writable, skip all the bundle stuff because generally the bundle is read-only.
if(strcmp("r", mode) && strcmp("rb", mode))
{
return fopen(file, mode);
}

NSAutoreleasePool* autorelease_pool = [[NSAutoreleasePool alloc] init];


NSFileManager* file_manager = [NSFileManager defaultManager];
NSString* resource_path = [[NSBundle mainBundle] resourcePath];

NSString* ns_string_file_component = [file_manager stringWithFileSystemRepresentation:file length:strlen(file)];

NSString* full_path_with_file_to_try = [resource_path stringByAppendingPathComponent:ns_string_file_component];
if([file_manager fileExistsAtPath:full_path_with_file_to_try])
{
fp = fopen([full_path_with_file_to_try fileSystemRepresentation], mode);
}
else
{
fp = fopen(file, mode);
}

[autorelease_pool drain];

return fp;
}
#endif


5

General discussions / SFML 2.0 Mac OSX in App Bundle

« on: March 05, 2011, 08:13:48 pm »

What about a compromise where we instead of changing the working directory, we append the "application.app/Contents/Resources" to the path when loading assets if the application is a Mac OS X bundle?

6

General discussions / SFML 2.0 Mac OSX in App Bundle

« on: March 05, 2011, 08:05:40 pm »

Oh sorry!  I didn't mean to start a war here! :-)

I just looked at the 1.6 code and I found where it checks for the resources directory.  

Now, let me add a few thoughts.  Application bundles are the standard way of building apps in OS X.  In a Mac OS X bundle, the resources directory is where all the assets exist.  Now, I don't think it is bad/good design, but a different design; it's just different from your typical Windows, Linux, etc application.

Now my opinion...  I would have to agree with Ceylo here and let me tell you why.  SFML is supposed to be a cross platform library.  The library itself should handle all the idiosyncrasies of the various platforms.  For instance, as a user of SFML and if I were to write code for say Windows and Mac OS X, I would have to do this now:

#IF WIN32
Image.LoadFromFile("image.png");
#ELSE IF OSX
Image.LoadFromFile(GetResourcesDirectory() + "image.png");
#ENDIF

Basically you get the idea.  The user of the cross platform library would need to differentiate which system he/she is using.  Using the 1.6 method, Image.LoadFromFile("image.png") would work across any system and it wouldn't matter as the same C++ code would work.

7

General discussions / SFML 2.0 Mac OSX in App Bundle

« on: March 04, 2011, 10:43:41 pm »

Hiura:

Thanks for your reply!!  Haha, so it's all around good news?


I will give that a try.  Thanks for the code to get the path of the resources directory.  

So, do we have to include this function to get the resource path from SFML 2.0+?  The project template from 1.6 did not require this.  Did 1.6 change the working directory to the resources folder on a OS X build?

8

General discussions / SFML 2.0 Mac OSX in App Bundle

« on: March 02, 2011, 07:24:14 am »

Hello,

I realize that the instructions say to create a new C++ command line project and include the dynamic/static libraries from cmake.  I got everything to work doing it that way.  However, is it possible to build a bundle with 2.0?  

I tried to create a new Cocoa project, modify it to include all the SFML libraries.  So far so good.  Everything works except for my working directory...  I have to reference:  "TestSFML.app/Contents/Resources/testimage.png" instead of just "testimage.png".  It seems that the working directory is where the bundle is located.  Anyways, I could be doing it all wrong....

I'm really just wondering if it is possible to build a bundle with 2.0 or do I just need to do a chdir() system call.  

Thanks!

9

General discussions / [SFML 2] I need your help for the ATI fix

« on: March 02, 2011, 02:28:51 am »

Just out of curiosity Laurent, what were the custom Drawable changes?  I, for one, can wait until these changes are complete!  

Do we need to cheer you on? :lol:

10

General discussions / Xcode and SFML2

« on: February 15, 2011, 05:48:02 am »

@Hiura

I didn't know that you had to use the Unix make files instead of the Xcode project in CMake.  Let me give that a try.  

Thanks!

11

General discussions / SFML2.0 on OSX wrong OpenAL version

« on: February 15, 2011, 05:46:17 am »

Your post is right here:

http://www.sfml-dev.org/forum/viewtopic.php?t=4173&sid=506f058db438e3040e85255a74c6cd9f

12

General discussions / Xcode and SFML2

« on: February 13, 2011, 10:12:59 pm »

@ceylo @Hiura

Thank you guys!  Anyways, I finally got it working.  Though the only way I was able to was to copy the dylib's into the project itself and added a build phase to copy it to the products directory.  

Hiura, darn I should have read the forums more thoroughly.  Those were the instructions I was looking for.  

Per your instructions, how do you do a sudo make install?  I tried to do that but I couldn't find the make files anywhere.  Do I do a sudo cmake install?  What I ended up doing was running Xcode as root (I know, bad bad) but I was able to build the dylibs and put them into /usr/local.

13

General discussions / Xcode and SFML2

« on: February 13, 2011, 05:02:20 pm »

It appears to be the same error...

I just downloaded a fresh copy of SFML from SVN.  Did the whole cmake deal.  Compiled just fine and put the new libraries into /usr/local/lib, etc...
This time with the standard 32/64 bit.  Though I agree with you, it would be easier just to do my native architecture.  I didn't create a new project though, I just took my test project and remove/added the new libraries.  (Just to be safe)  And did a clean rebuild.  Ah well...

So, not sure what else to try now.  I could recompile with 64 bit and create a new project again...  I'll probably do that later.  Any other ideas?

14

General discussions / Xcode and SFML2

« on: February 13, 2011, 04:15:05 pm »

Thanks guys for your replies!

@devlin

I agree.  I added the references to the search paths out of desperation, but it didn't make any difference.  So I removed them.

@Ceylo

You bring up a good point.  Apparently I compiled the libraries on my native architecture (x86_64).  When I switch my configuration to compile at x86_64, I still get the same undefined symbols error.  Obviously, when I switch it to a different architecture, I get the "file was built for unsupported file format..." error.  


Let me try and rebuild the libraries in the standard 32/64 bit format and see if that helps.  I will repost with the results.

15

General discussions / Xcode and SFML2

« on: February 13, 2011, 06:03:27 am »

Perhaps I wasn't descriptive enough :-)

I recreated a new project.  Since the headers and libraries have already been copied to /usr/local/lib and the headers are in /usr/local/include/SFML, Xcode seems to recognize it.  I added the dylib's (add existing framework) into my project: libsfml-audio.dylib, libsfml-graphics.dylib, libsfml-network.dylib, libsfml-system.dylib, and libsfml-window.dylib.

Then I created a RenderWindow as a test.  And this is what I get when I try the compile:

Code: [Select]


Undefined symbols:
  "sf::RenderWindow::RenderWindow(sf::VideoMode, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long, sf::WindowSettings const&)", referenced from:
      _main in main.o
ld: symbol(s) not found


I even added /usr/local/lib to my library and framework search paths and /usr/local/include/SFML to my header search paths.  Same problem...


It just errors out at this line:

Code: [Select]


sf::RenderWindow app(sf::VideoMode(800, 600), "SFML");



Thanks for anyone who can help...