946
General discussions / SFML 1.4
« on: January 07, 2009, 11:59:32 pm »
Indeed... and all the symbolic links are broken/missing...
I'm going to tell this to Laurent.
I'm going to tell this to Laurent.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
947
General discussions / SFML 1.3 and OS X
« on: January 07, 2009, 04:36:56 pm »
Uh.. where have you found a 15.3 MB file ?
948
General / [C++/OSX] "sssssssssssssssssssssssssssssssssssss"
« on: January 05, 2009, 11:30:08 am »
Looks like a GDB bug :
You could tell the GDB developers about it.
Quote
/SourceCache/gdb/gdb-962/src/gdb/objfiles.c:2218: internal-error: objfile_data: Assertion `data->index < objfile->num_data' failed.
You could tell the GDB developers about it.
949
General / [C++/OSX] libraries don't link properly
« on: January 04, 2009, 01:16:22 am »
There is no crash described in this log.
PS: you can come and talk through MSN.
PS: you can come and talk through MSN.
950
General / [C++/OSX] libraries don't link properly
« on: January 04, 2009, 12:29:41 am »
What's written in the Xcode's console ?
951
General / [C++/OSX] libraries don't link properly
« on: January 03, 2009, 07:13:09 pm »
Not with the latest versions of the templates, because I consider this is rather an advanced step, and therefore is not required for SFML development.
But if you use the old templates... I do not understand why you can't find the frameworks in the <name>.app/Contents/Frameworks directory :? .
Whatever the debugger tells you, if you copy the right frameworks in /Library/Frameworks, you application or executable will work fine.
But if you use the old templates... I do not understand why you can't find the frameworks in the <name>.app/Contents/Frameworks directory :? .
Whatever the debugger tells you, if you copy the right frameworks in /Library/Frameworks, you application or executable will work fine.
952
General / [C++/OSX] libraries don't link properly
« on: January 03, 2009, 04:53:53 pm »Quote from: "zhinchliffe"
right, but usually the frameworks are automatically put in that folder, and now, for some reason, they are not.
Never has this been done automatically.
If you wish Xcode to do this for you, use a build phase (Xcode Build System Guide).
953
General / [C++/OSX] libraries don't link properly
« on: January 03, 2009, 12:47:30 am »
The debugger asks for the frameworks to be copied in appname.app/Contents/Frameworks. Make sure this is where you put them.
Otherwise, for general development with SFML, the frameworks must be copied in /Library/Frameworks.
Otherwise, for general development with SFML, the frameworks must be copied in /Library/Frameworks.
954
General discussions / SFML 1.3 and OS X
« on: January 02, 2009, 11:11:55 pm »
I did not provide any way to build a static version of the libraries.
First because you would have to add all the missing libraries yourself (Cocoa, OpenGL, OpenAL, libsndfile, libfreetype). This is because Apple only provides dynamic libraries (unlike Microsoft), and static libraries cannot link against those (whereas they can contain other static libraries). On the other side, this also means that with the dynamic version, you don't need to worry about any depedency, which makes the things quite simpler.
Second because you can put the SFML frameworks in the application bundle if your purpose is to redistribute your product.
If you really wish to use static libraries, I suppose this would be because of a VERY specific issue and therefore I consider you'd know well Mac OS X development, and you could and would have to build them yourself.
First because you would have to add all the missing libraries yourself (Cocoa, OpenGL, OpenAL, libsndfile, libfreetype). This is because Apple only provides dynamic libraries (unlike Microsoft), and static libraries cannot link against those (whereas they can contain other static libraries). On the other side, this also means that with the dynamic version, you don't need to worry about any depedency, which makes the things quite simpler.
Second because you can put the SFML frameworks in the application bundle if your purpose is to redistribute your product.
If you really wish to use static libraries, I suppose this would be because of a VERY specific issue and therefore I consider you'd know well Mac OS X development, and you could and would have to build them yourself.
955
General discussions / SFML 1.3 and OS X
« on: December 30, 2008, 03:27:32 pm »
Mac OS X 10.4 and newer versions already provide OpenAL, so you don't need your personal framework.
956
General discussions / SFML 1.3 and OS X
« on: December 28, 2008, 03:07:33 pm »Quote from: "zhinchliffe"
Help! Can anyone please give me a straightforward way to get the current SVN version of SFML working in Xcode? I'm really, really confused. Much thanks in advance.
The easiest way for now is...
Download the files from the SVN repository.
Open the project sfml/build/xcode/SFML.xcodeproj with Xcode 2.4 (or any other newer version).
Click the build button in the toolbar.
Copy all the framework from sfml/libs/xcode to /Library/Frameworks (if building worked well).
That is not a comprehensive solution, but the best if you wish to use SFML right now for your personal use.
Otherwise you can wait for the 1.4 release (that should come in the next few days if I'm not mistaken).
957
General discussions / SFML 1.3 and OS X
« on: December 28, 2008, 03:00:26 pm »Quote from: "lzr"
I wanted to try out the SVN, but I had some trouble getting the library to compile. All the packages were fine except for sfml-audio and sfml-graphics.
Here are the errors I get for sfml-audio:
[...]
Looks odd... did you compile the OpenAL framework yourself ? (make sure you're using the one from your system or from the 10.4 SDK)
Check there is no OpenAL framework in /Library/Frameworks (which would be one you built), and have a look at the al.h file in the OpenAL framework and check you have these two lines :
Code: [Select]
#define AL_VERSION_1_0
#define AL_VERSION_1_1Because I'm wondering whether you'd be using OpenAL 1.0... (SFML demands OpenAL 1.1)
Quote from: "lzr"
And here are the sfml-graphics errors:
[...]
I'm using a PowerPC G5 mac with OS X version 10.4.11 and Xcode version 2.2, if that helps.
I dunno if this could change anything, but the Xcode project is supposed to be used with Xcode 2.4 and later. Try to update.
If this does not work, try what's advised by Xcode : launch Terminal.app (from the Utilities folder) and type this :
Code: [Select]
cd path/to/your/sfml/directory
ranlib extlibs/libs-xcode/libfreetype.a
ranlib extlibs/libs-xcode/libsndfile.a
958
General discussions / SFML 1.3 and OS X
« on: December 27, 2008, 08:56:55 pm »
When using telnet localhost 4567 after launching your application, I get this :
Try to keep only the network feature in order to know if the issue comes from my port.
Quote
DEBUG: Entering thread: "handleConn()".
Listening to port 4567. Waiting for TCP connections...
...waiting!
...waiting!
Client connected ! (127.0.0.1)
Unable to connect to client! (127.0.0.1)
...waiting!
Client connected ! (127.0.0.1)
Unable to connect to client! (127.0.0.1)
...waiting!
[repeated about one hundred times]
Client connected ! (255.255.255.255)
...waiting!
[last two lines repeated infinitely]
Try to keep only the network feature in order to know if the issue comes from my port.
959
General discussions / SFML 1.3 and OS X
« on: December 18, 2008, 04:13:53 pm »
I gave the French version to Laurent one week ago, I don't know if he translated it, and I don't know whether he will allow you to see it before the 1.4 release 
.
.
960
Feature requests / "Huge Sprites"
« on: December 13, 2008, 02:42:29 pm »Quote from: "Imbue"
I'm not 100% sure, but I don't think you can trust the graphics card to store images for very long (like hitting alt-tab may wipe the memory).
If this was to happen, how would SFML notice this ? To my mind, there would be no way.
But anyway, the images are stored in the graphic card memory through an OpenGL context, so until you destroy this context, your images are kept in the graphic card memory. Therefore, as SFML never destroy the main shared OpenGL context, alt-tab can't destroy your images until you explicitely choose to do so.