Messages

1

General / Mac OS X 10.6 x86_64 build

« on: October 02, 2009, 11:39:29 pm »

Well, maybe I'll get it to work

2

General / Mac OS X 10.6 x86_64 build

« on: October 02, 2009, 12:01:17 pm »

Celyo, did you manage to build sfml2 branch on the SVN repository? When I looked at it, a couple months ago, I gave up after I saw the GL back-end wasn't coded. It seems the directory structure is gone. If you had any success, just tell. I'm looking forward to being able to build a nice, multi-arch, up-to-date, package

3

General / Mac OS X 10.6 x86_64 build

« on: October 01, 2009, 06:17:12 pm »

Quoted from libflac's README:

--disable-asm-optimizations : Disables the compilation of the
assembly routines.  Many routines have assembly versions for
speed and `configure' is pretty good about knowing what is
supported, but you can use this option to build only from the
C sources.  May be necessary for building on OS X (Intel)

It built successfully. I rebuilt libsndfile also, and vorbis and flac files work.

Code: [Select]


sh-3.2# ./sndfile-play queen\ -\ another\ one\ bites\ the\ dust\ \(9\ sec.\).flac
Playing queen - another one bites the dust (9 sec.).flac
sh-3.2# ./sndfile-play Livin\'_On_Borrowed_Time_zero.ogg
Playing Livin'_On_Borrowed_Time_zero.ogg
^C


I thought I had removed the framework from the system, but I actually did not

4

General / Mac OS X 10.6 x86_64 build

« on: September 29, 2009, 11:49:52 pm »

SVN Creative Labs

MBP:temp frozen$ svn checkout svn://connect.creativelabs.com/OpenAL  truc
A    truc/trunk

MBP:temp frozen$ svn --version
svn, version 1.6.3 (r38063)
    compilé Jul 15 2009, 14:24:06

I have to say that I thought Xcode would always link against frameworks that lie in the proper system directories. So I (maybe wrongly, can't tell, file deleted) assumed that the version supplied with 10.6 didn't have 64 bit code (that puzzled me a bit). If you want me to test, provide me with the original 10.6 framework

sndfile
I learnt about libtool today too, thank you Google if you read this. Beware by the way, there is an Apple tool called libtool. GNU libtool is named glibtool (Logical, heh >_>).

External libraries support was disabled. The configuration script activates it when flac, ogg, vorbis, and vorbisenc are installed. I ran into problems while building the flac library, namely this kind of things:

Code: [Select]

ranlib: archive member: .libs/libFLAC.a(lpc_asm.o) cputype (7) does not match previous archive members cputype (16777223) (all members must match)

I might give it a look one of those days, but school will resume soon, and I'm going to be quite busy. Curiously, it seems that the flac cvs hasn't been upgraded in months. Stupéfiant =)

5

General / Mac OS X 10.6 x86_64 build

« on: September 29, 2009, 11:14:05 pm »

To answer your questions in good orded:

OpenAL
Trunk lies here: svn://connect.creativelabs.com/OpenAL

in file oalAtomicStack.h, I added

Code: [Select]

#include <libkern/OSAtomic.h> and changed:

Code: [Select]

bool compare_and_swap(T *oldvalue, T *newvalue, T **pvalue)
{
return OSAtomicCompareAndSwap64((int64_t) oldvalue, (int64_t) newvalue, (int64_t*) pvalue); // HACK
//return CompareAndSwap64(UInt32(oldvalue), UInt32(newvalue), (UInt32 *)pvalue);

}
I then replaced every occurrence of "ALvoid" and "ALCvoid"by void (those are opaque types typedef'd to void, yet gcc was complaining)

Ah last but not least, as Apple says, CoreAudio directory structure changed in SL, which implies modifying the .xcodeproj and/or some header files.

(IMO there isn't a full time OS X maintainer for OpenAL at the moment =) )

sndfile
Version: libsndfile-1.0.20

./configure && make
sudo glibtool --mode=install libsndfile.la ~

then replace the library that lies in the existing framework by the .dylib it just buit. Vorbis support is here, I didn't check with flac.

freetype
Version: freetype-2.3.9
It's built the same way as sndfile

The goal was to get the SFML running on x86_64 heh, that's all.
If you're doing it the same way I did, and Xcode generates code for other archs, it will fail

CompareAndSwap?
openal's CompareAndSwap as it's written on the SVN HEAD revision calls corefondation's CompareAndSwap, which takes uint32's as arguments. Thus, as memory addresses are 64 bit integers, it just won't work.

I'm not sure if this fix is safe. Semantically, it seems like it is, yet I did not read calling code, so I won't bet anything

6

General / Mac OS X 10.6 x86_64 build

« on: September 29, 2009, 05:49:15 pm »

Hello,

I complied a 64 bit build based on SVN trunk from july the 12th,
OpenAL trunk from today (with a slight modification - replaced a call to CompareAndSwap with one to CompareAndSwap64).

As 64 bit executables cannot depend on 32bit libraries, I had issues building project after updating to SL.

As it was quite boring, and a couple fixes had to be made to dependences, I can provide you with extlibs, and/or information.

Just ask

SFML-1.5_osx_i86_64.tar.gz.bz2

PS: Tell me if I forgot to include anything

7

Graphics / [MacOS X | SFML 1.5] Failed to create image.

« on: July 13, 2009, 01:11:21 am »

Fine, I hope you'll spot the issue without pain.
Don't hesitate to ask if you were to need anything related to the issue.

Happy downtime

8

Graphics / [MacOS X | SFML 1.5] Failed to create image.

« on: July 12, 2009, 06:27:02 pm »

Laurent, do you have information/pointer concerning this bug?

(The machine is fitted with an NVIDIA GeForce 9600M GT, I think the images ain't too large for it.)

9

Graphics / [MacOS X | SFML 1.5] Failed to create image.

« on: July 12, 2009, 03:37:02 pm »

Hey, I think they may be a bug with sf::Image.

Code: [Select]


#include "SFML/Graphics.hpp"

int main(int argc, char *argv[])
{
puts("Loading items.jpg");
sf::Image img;
img.LoadFromFile("data/images/items.jpg")? puts("Okay"): puts("Oops");
}


Output:

Code: [Select]


Loading items.jpg
Failed to create image, its internal size is too high (256x128)
Oops


I'm on 10.5.7, linking with SFML-1.5 release.

Where it happens:

Original image (PNG + Alpha, 192x96 px),
Alpha-stripped PNG file,
JPG conversion of the file,
BMP conversion of the file,
JPG conversion of a resized version of the latter JPG file (forming a 192*192 image).

Where it doesn't happen:

data/images/icon.bmp: PC bitmap data, Windows 3.x format, 32 x 32 x 32


Edit:
I've posted the C++ source files and sample images in a tar.bz2 archive here:
http://dl.free.fr/pMt4Ojceo

Edit2:
Everything works well on win32-mingw or gnu/linux-gcc...