SFML community forums
General => General discussions => Topic started by: Ceylo on July 24, 2009, 01:58:31 pm
-
Hello,
As you may know, I'm taking care of the Mac OS X implementation of SFML. I've been working on it for about one year and a half at this time. When I started this work, the previous developper had left the implementation incomplete. Since then I've switched the implementation from the Carbon API to the Cocoa API, in order to provide SFML integration in Cocoa based applications and ensure SFML's perenniality. I've learnt very much : I already knew Cocoa and Objective-C, but I had never really practiced C++.
However I now want to get rid of SFML development in order to work on other projects. Working 18 months on the same few files is a pain. I don't plan to develop SFML 2. I'll stay in order to fix the existings bugs in SFML 1 in order to ensure there is at least one SFML stable version for Mac OS X. Thus my work will stop when Laurent stops developping this branch.
Therefore the SFML project needs another Mac OS X developer ! Here is what you'll need if you wish to do this work : Objective-C and C++ languages, Cocoa API and OpenGL (you'll not need to know the OpenGL API but at least how OpenGL works with the OS).
Obviously, I stay here to answer to your questions, especially to the developpers that may wish to contribute. I can explain to these persons how all my "mess" works, and I'll always be able to do so even when someone else will have taken my place (so be confident, I won't let you alone in the jungle that is my work ;) ).
Ceylo
P.S.: English is not my native language, so you may find some expressions unconvenient or devalorizing even if it was not my purpose.
-
Hi Ceylo, I would be interested in developing the Mac OS X port of SFML.
Alex
-
Could you explain why you think you are able to develop the Mac OS X port ?
-
Any news ?
-
Nop. Nobody seems ready to go on working on the port.
And about me, I don't know if you followed the issue about sndfile 1.0.20. This is new version needed by SFML 2, and I wasn't able to build it for PPC architecture on my Intel MacBook (not because my computer isn't able to compile for ppc, but because I don't really know how to compile for ppc with the configure tool). But during the holidays I went back to my mother's home and she's using a PPC Mac, so I built sndfile for this architecture. Thus I can know make a universal binary of sndfile 1.0.20.
As for the Shell script supposed to do the full packaging process, I think it's ok (tested), thus the next developer won't have much work to do.
Also, I'm currently running Mac OS X 10.6 (developer preview) and I can say SFML still works fine.
-
Oh god thanks ! :)
As I will get very soon a mac ( with SL in a few weeks ) I'm very happy to see it works !
But as you said the Mac dev need to know the basis of Cocoa API and Objective-C plus a little bit OpenGL. And I know neither of them. And as I'm beginning in September in the EPFL (http://www.epfl.ch/index.en.html) I don't know if I would have enough time to learn all of these.. I'll tell you later if I could.
-
Woot ! Good luck in your school ! :D
And don't worry too much about SFML, first take care of your studies :) .
PS: I dunno if "take care" is the appropriate phrase..
-
Thank you :)
-
Hi folks,
I've been a lurker around here for a while and have been using SFML for various things on Win32 and OsX with an occasional mucking about in various *nix distro's. Anyway, if someone else better doesn't come along, I'd be willing to take on the Os X maintenence.
Some background:
20 years making games: The Sims, The Sims Online, Star Wars Ep3 (xbox/ps2), currently on something you probably know about. :)
Os X user since the switch to Intel chips. Not a "guru" at Objective C but know my way around. Work in Cocoa just enough to get get things working and wrap with C/C++ for my higher usages.
Threading, graphics, sound etc experience at different times.
Anyway, I'd obviously be mostly a weekend warrior with occasional work during the week but that seems like it would be enough.
If this light overview is interresting, we can discuss more details in a PM.
All8Up
-
PM sent.
-
As I got my mac book this afternoon I would be happy to help by testing some things. :wink:
-
Thanks for the next developer :D .
-
Hello,
I am a new user of SFML. However, I do know C++ and Objective-C/Cocoa pretty well. I am a little weak on OpenGL also but I would be interested in trying to work on SFML on the Mac side. I imagine you need to know XCode and GCC 4.0 inside and out. I do know about them but not inside and out. I guess I would like to know more specifically what is involved.
thank you in advance,
Patrick
-
You can have a look at the sources from the Subversion repository. There you'll find what has been done for Mac OS X till now (see sfml/trunk/src/SFML/Window/Cocoa).
What is to be done is to adapt the current implementation for SFML 2 (see sfml/branches/sfml2/src/SFML/Window/Template for new ports), and eventually fixing bugs in the current branch (sfml/trunk/...).
You can obviously take most of the code from the current development branch (trunk/...) to achieve the SFML 2 Mac OS X port (branches/sfml2/...).
If you understand well what has been done till now, and you think you're able to write the sfml2 code, then maybe you could contribute.
If you're still interested, let's talk a bit more through PM.
Ceylo
-
see sfml/branches/sfml2/src/SFML/Window/Template for new ports
Forget about that, it's not up to date.
-
Then see what ? :?
-
See the other ports, or me ;)
-
Hey everyone. I'm new to SFML but for me maintaining the Mac port is an important issue. So I was just wondering if someone had been found to take over. If not, perhaps we can try finding someone at a place like idevgames.
-
There are already several persons that have been asking for working on the port. I'm currently waiting for their answer. If someone else wants to participate, he's still welcome as nothing has been decided though.
I don't really know idevgames, but I think it's easier to find people interested and knowing SFML well on the SFML forum rather than on a general game development forum.
I admit I don't really feel like posting everywhere too.
-
hi all.
any news on the mac front? i guess not yet ... therefore i am making a proposal.
i have started using SFML because i like its simplicity and its cleanliness.
i've worked on a similar codebase a while ago. super (c)lean standards compliant cross platform c++ code. believe it or not, i still admire the code my colleague and i were writing back then. we were using extreme programming (strict test first design, pair programming) back then, btw...
enough with the nostalgia. but i am so fed up with the poor code base i had to use and i have to admit i also have produced in the last years.
because the foundational libs were not clean enough, because there was not enough time, etc ... (the usual reasons)
the good thing is, i would like to to change this fact - to have a solid base for my work (mostly C++ and OpenGL for interactive art installations, interaction and visualization prototypes, performances, ...). and SFML seems to be a real good candidate. i have used i.e. openFrameworks a couple of times but i have been disappointed by the codebase.
it has some neat features and good ideas, but the code quality is not convincing for me at all. it would be awesome to have a contender like SFML with its known strengths.
the other point is - i have developed my own private code base over the years, but always had an excuse (or no time) to not make it into a proper library/toolkit/framework/engine. i think it would be a better investment for me personally and more convenient to use my energies on a shared project.
the bad thing is i am more and more switching away from windows to mac or linux (although i still love windows XP and visual studio), personally and commercially. but this could be good as well considering the current thread topic ;)
to make my long story short - i would like to contribute somehow.
i know c++ and opengl quite well. i don't know xcode very well, but since i switched to mac i got to know gcc and all the commandline utils quite well. right now i prefer codeblocks on mac over xcode.
i do not know cocoa or objective-c yet. but i think this minimal part for wrapping all the other c++ functionality should not be much and i guess i will have to get my way around it anyway (glancing at iphone).
i also have a couple of macs (only intel, but with different graphics chips) where i could test stuff ...
so let me know if you are interested in collaboration!
and could the devs please tell us what needs to be done? what are the plans. just to get a better picture ... because i already have a lot of ideas and wishes :)
cheers,
didi
-
Well I don't have much news from the people that first asked for working on the port (I'm actually still waiting for their answer).
Thus yeah the "job" is still available. What will you have to do ? Update the current port to match the SFML 2 Window interface, implement the new features SFML 2 is to provide (I don't really know the changes, but I saw there is now a separate class for windows and OpenGL contexts for example), provide the most easily usable product you can, answer all the questions on how to use SFML on Mac OS X, and in a general way.. fix all the bugs you can.
My personal note on the most tricky point I found is how to adapt Cocoa to the way Windows and Linux GUI API work. If you try to do a bit of Cocoa, I think you'll find out it's quite different from the Win32 API for instance.
As for the skills, you'll NEED to learn Objective-C and Cocoa, that's the basis for any Mac OS X application with a GUI and a major point for getting the responsability of the port (until you can prove Cocoa is uselss :roll: ).
I don't really know what you mean with "a lot of ideas and wishes", but that's the kind of thing you'd better discussing with Laurent than me :D .
-
i am a bit confused. does someone really has to use cocoa/obj-c on macosx platforms? is there no possibility to just stick to plain c++?
i've been reading david eberly's "3d game engine architecture" book and the code in his wildtangent 3d engine. he made a very clean platform abstraction and i can't find any references to cocoa or obj-c - just carbon (which also is quite unpretty IMHO) and c/c++.
as i've researched now carbon is the old native way to do things, and cocoa the future hot shit to build applications for macosx. but cocoa resides on carbon, so i think we will have the more mature carbon around for a while. at least for the next years and then SFML could still change.
or maybe together with a proper iphone port.
and for me as a c++ and control freak, i'd prefer a lean/faster/lower level solution over using some additional framework in between as long as there are no other reasons. but that is just my opinion...
but well, as long as i don't have learned cocoa/obj-c/obj-c++ yet and no other decisions have been made, i can maybe contribute by checking mac build process, test and maybe fix the c++ and opengl part in general and on mac in particular.
cheers, didi
-
Ceylo will tell you more about that, but I can already tell you that Carbon is deprecated and should no longer be used. It doesn't support 64-bits architectures, as well as some new features (not sure about this).
If you're not convinced have a look at Qt: they recently switched from Carbon to Cocoa (mainly for 64-bits stuff I think), I don't even know if they still support Carbon for 32-bits builds.
I think that the topic "Carbon vs Cocoa" should no longer be debated, SFML must clearly use Cocoa.
-
well, i did not want to proof that cocoa is useless - which it is not.
and i am not saying it is not the future and it's not easier - considering the better, someone still has to convince me ;)
and for sure i did not want to start a discussion on cocoa vs carbon.
you want cocoa - get it. you are the boss.
it was just a suggestion from my very personal and totally subjective perspective on the use of SFML. and in this view your arguments of 64bit and Qt are just lacking. that is not what SFML is for me and what i would like to use it for. but maybe i am wrong...
so in the end, keep up the good work on SFML!
i'll try to watch the progress and contribute with testing and feedback.
-
you want cocoa - get it. you are the boss.
I'm not the boss on the Mac OS X port ;)
If someone comes and convinces me that Carbon is the best option, I won't fight against him. But what I've understood (again, I'm not a Mac OS X expert) is that there's no "Carbon or Cocoa" choice, Cocoa is now the only option, Carbon belongs to the past.
it was just a suggestion from my very personal and totally subjective perspective on the use of SFML. and in this view your arguments of 64bit and Qt are just lacking. that is not what SFML is for me and what i would like to use it for. but maybe i am wrong...
It would be silly not to support 64 bits builds.
I was not comparing SFML and Qt, just talking about it to show a good example of a well known library which had a Carbon based Mac OS X port and chose to switch to Cocoa.
so in the end, keep up the good work on SFML!
i'll try to watch the progress and contribute with testing and feedback.
If you feel like Carbon is a better option for SFML, go ahead and talk with Ceylo :)
-
Cocoa partly resides on Carbon for now but will soon no more. It's currently only used for the event handling (thus not for UI drawing). Carbon is almost no more updated, deprecated and does not support 64 bits UI applications.
Quoted from 64 bits Guide for Carbon Developers (http://developer.apple.com/mac/library/documentation/Carbon/Conceptual/Carbon64BitGuide/PortingTo64Bit/PortingTo64Bit.html)
Because most Carbon UI functions are not available to 64-bit applications, you have two possible development paths. You can continue modernizing and improving your Carbon UI with the expectation that your application will remain a 32-bit application for the foreseeable future. Apple plans to support and maintain the 32-bit Carbon Human Interface Toolbox, although Apple will not be adding any significant new features to these APIs. The other development path is more challenging and also potentially more rewarding in the long term. You can develop a 64-bit version of your application, using Cocoa to implement your UI. As you do so, consider going one step further and implementing other parts of your application using Cocoa.
I'm actually not so surprised your book only uses Carbon (it can be used in C and C++ projects and it's quite more close to the way the Win32 API works, thus easily understandable for common Windows developers).
but well, as long as i don't have learned cocoa/obj-c/obj-c++ yet and no other decisions have been made, i can maybe contribute by checking mac build process, test and maybe fix the c++ and opengl part in general and on mac in particular.
You'll have to discuss about this point with the next Mac OS X developer.
Ceylo will tell you more about that, but I can already tell you that Carbon is deprecated and should no longer be used. It doesn't support 64-bits architectures, as well as some new features (not sure about this).
Indeed the new features come with Cocoa. If you are not convinced, just have a look at the symbol changes in the Foundation (http://developer.apple.com/mac/library/documentation/Cocoa/Reference/FoundationRefUpdate/Articles/Foundation_10.5-10.6_SymbolChanges.html) and AppKit (http://developer.apple.com/mac/library/documentation/Cocoa/Reference/AppKitRefUpdate/Articles/AppKit_10.5-10.6_SymbolChanges.html) frameworks (the two components of Cocoa) and the changes in the Carbon (http://developer.apple.com/mac/library/documentation/Carbon/Reference/CarbonRefUpdate/Articles/Carbon_10.5-10.6_SymbolChanges.html) framework from Mac OS X 10.5 to Mac OS X 10.6. Missing link to the symbol documentation means it is no more supported.
-
Hello Ceylo and Laurent, do you have any news on the OS X topic?
-
About the next Mac OS X developer or the SFML port status ?
-
Yeah, sorry for not making myself clear.
I was mostly interested in the 2.0 Mac OS X status, and i guess that's tightly connected with the next OS X developer.
-
There is absolutely no news about the next Mac OS X developer, and thus no news about SFML 2.0. Sorry :roll: .
-
well i can announce that i've wrestled very much with cocoa and opengl (and quicktime and corevideo ...) in the last 2 months and after this project will have been finished (in 3-4 weeks) i would like to rethink about my proposal to help. i still would love to have a good framework like SFML with proper mac support. so maybe i can help ... we will see. i will come back to you soon!
-
Great !! (well.. at least I hope :D)
-
No news here ? :(
Ok I know it may seem a bit odd (especially coming from me) but.. I'd be so pleased if someone could do the Mac OS X port of SFML 2.0 !
(I actually want to start a little game but the best GUI libraries I found here use SFML 2 so I'm a bit stuck)
-
hey there,
sorry for being quiet for so long but i have some things going on right now.
i am still willing to contribute to the macosx port with my recent cocoa experience.
i just updated my working copy and wanted to ask you to point me into the right direction for starting ...
What will you have to do ? Update the current port to match the SFML 2 Window interface, implement the new features SFML 2 is to provide (I don't really know the changes, but I saw there is now a separate class for windows and OpenGL contexts for example), provide the most easily usable product you can, answer all the questions on how to use SFML on Mac OS X, and in a general way.. fix all the bugs you can.
My personal note on the most tricky point I found is how to adapt Cocoa to the way Windows and Linux GUI API work. If you try to do a bit of Cocoa, I think you'll find out it's quite different from the Win32 API for instance.
could someone please elaborate on that?!? how far is SFML2 on windows and linux? what is missing on macosx?
-
hello again,
so i spent the whole afternoon on trying to compile sfml2 (updating the whole xcode project before) and trying to figure out what needs to be done and what is going on behind the scenes.
for that i compared it to what was going on in sfml1 on the macosx side...
first of all - kudos to the person that wrote the macosx part before!
it is clean (in terms of coding convention/style/formatting, no dead code) and it does some things really well. like providing standard functionality available on other platforms for SFML, i.e. creating opengl views + and windows at runtime. before i thought this was done via Carbon. but then i saw that it already had an Cocoa implementation. hell, i didn't even know this was possible without a NIB.
and it is hiding the implementation from the user!
and IMHO this is also the bad part. it tries so hard to mimic behavior of other platforms (like linux and windows) and for this a lot is going on in the background (create a global context, global appcontroller, a dummy window, etc) and i can only think this thing must be hell to test, debug and maintain ... ok ok, i knew that mixing objective-c(++), cocoa and c++ would be strange and that everything is packed in 3 gigantic obj-c++ files certainly does help to further obfuscate things ...
so my questions would be?
what would you like to change for the new macosx/cocoa backend?
and why? why not stick with the old?
do you want to have a opengl-context wrapper because of multithreading?
it would really help if someone could shed some light on this topici n general ...
gracias!
-
*hides in a hole*
Well.. I did write the Cocoa backend, almost completely from scratch (actually the only thing remaining from the Carbon implementation is the video mode support).
I didn't think someone could even wonder at this.. "thing" (I find it awfully big, but as you said, that is to match the same behavior as on the other OS).
SFML cannot keep this backend because it does not match the new interface Laurent wrote for SFML 2. Besides there are some new features like OpenGL pixel buffer that need OS specific implementation.
I cannot tell you about the exact new features (Laurent told me to tell you but I know nothing about these !! so I told him to tell you :D ). You'll have to wait for him.
A little note about the awful code.. if I were you I wouldn't even have a look at the autogen.sh script. I did it to be able to build the SFML packages typing one single command line but... don't look at how it works :lol: .
-
I can of course explain the new classes that must be written, and how things work now compared to SFML 1 :)
I suggest that you send me an e-mail so that we can start a loooong conversation about this port :D
-
Any news ? :)
-
Funny, I sent a PM to didito a few hours ago to ask the same question ;)
-
sorry guys, i was kind of offline the last weeks (moving + my macbook getting repaired). i'll need a couple of days more to setup but then i think i'm good to go. i've already done some thinking and i think i've got some questions for you, ceylo :) more on that later ...
so please, stay tuned!
-
Glad to hear it didito. Mac users everywhere will appreciate your efforts. :) Hopefully I can be helpful somewhere down the line too.
-
Hi !
Some news here didito ? And you can of course ask me whatever you want (well.. actually not "whatever" but you got the idea :P ) and I'll try to help you as much as I can.
Ceylo
-
finally started working. so stay tuned (and patient), people!
-
Yay ! Good luck, especially as a lot is expected from you :P .
-
pressuuuuure *drums rolling* ;)
no, i got something coming up. coming back to you later ...
-
I'm on holiday right now so if you need help... :wink:
-
I hope this doesn't slow down development (and/or release of SFML2). I'm half tempted to learn Mac programming. I have access to Mac machines in our labs... new ones, not sure what's under the hood but it's there. I can at least test the library on it.
I used to use SDL a while ago, tried using it again and realized it takes a lot of work to make a program. Came across SFML and looks great. Am interested in contributing something but mostly on the Linux (Fedora)/Windows (7) c++ side.
An interesting training exercise would be to port it to BSD (unless it already works on there) although doing that solo would require more time than I have.
-
An interesting training exercise would be to port it to BSD (unless it already works on there) although doing that solo would require more time than I have.
SFML should work on BSD, except for the joystick part which is a little bit different from regular Linux, and undocumented.
-
Has anyone tested it on any of the BSDs yet? Would be interesting to see SFML match desktop support with SDL. The only thing "missing" right now is Mac support (for SFML2). Then SFML2 would support the 3 major OS's.
I mainly use Linux but being able to develop a multiplatform program is a plus ^_^
-
Speaking of mac support, didito have you any news for us ? How are things going ? :)
-
Still no didito in the area ? :(
-
An interesting training exercise would be to port it to BSD (unless it already works on there) although doing that solo would require more time than I have.
SFML should work on BSD, except for the joystick part which is a little bit different from regular Linux, and undocumented.
If it works on osx, it should work on bsd (minus the cocoa code) since osx is derived from bsd. I'd like to offer my assistance in porting 2.0 to osx. I know this has had a lot of postings, and I know I can't do a complete port, since I'm blind, and using the Xcode tools is damned near impossible for me, but I'm an excellent code hacker, and I've ported several packages from other unix-type oses (and dos) to osx in the 5 years I've had my mac, so as long as you don't ask for graphical work, I can do just about anything else, including compiling final releases (I have both intel and ppc machines, laptops, minis and imacs (we're a mac family here) and I have an apple Developer Id, so asking support questions of apple isn't a problem. If someone else can build the gui components of the port, (buttons, menus, views and the like) I can handle the code behind them with only minor difficulty. I'm not sure my skills are up to porting something as complex as sfml, but I sure don't mind giving it a shot, perhaps if someone else who has a mac could do the graphical parts, I could handle the rest (possibly) I know that's not exactly what you were after, but if it will get the port done faster, I'll do what I can to assist.
Only thing is, no snowleopard machines yet (gotta upgrad the memory in my macbook first) but we do have both tiger and leopard machines here.
If someone could point me to the source that needs ported, I can certainly take a crack at it, who knows, maybe I can get some of it working.
hth.
-
Hi, I'm happy to see a new face interested in this port. :)
Right now I'm working on the window module. I understood how it works except for joystick stuff (I haven't looked at it yet).
The things are very dependent so co-working on it will be hard. But there are still Audio and Network modules which are not depending on Window.
Tell me if you're still interested. I will happy to provide any information or file. :wink:
-
But there are still Audio and Network modules which are not depending on Window.
Network and Audio don't need to be ported ;)
-
(http://i297.photobucket.com/albums/mm232/mintkiller/facepalm.jpg)
And with Graphics module there is only RenderImageImplPBuffer to be implemented, right ?
-
And with Graphics module there is only RenderImageImplPBuffer to be implemented, right ?
Absolutely :)
-
But there are still Audio and Network modules which are not depending on Window.
Network and Audio don't need to be ported ;)
Any thought about adding speech generation (text-to-speech) capabilities to sfml? Osx has a rather robust speech synthesizer api, and it could easily be rolled into the sfml libs. Windows has sapi which could be rolled to do the same job, and I haven't used linux in years, but I'm pretty sure they have some speech components that could be used for the process as well. Obviously, the details would vary from os to os, but basic text-to-speech capabilities should be doable on all platforms.
Sorry about the windows code, can't help there, (too graphical in nature for me) but I'd not mind giving the text-to-speech modules a crack.
-
A text-to-speech API is not really on the todo-list.
It would obviously be helpful for blind people, but what other purpose could it have? Moreover, those system-specific APIs probably use the same voice file format.
-
Currently I'm trying unsuccessfully to find out how to convert an image data (width, height, array of Uint8) to a NSImage to set up the application icon.
The only way I found until now is to recreate the image with sf::Image to a temporary location and reload it with NSImage methods. But this is not applicable as sf::Image is in Graphics module and sf::Window::SetIcon is not.
Any idea will be rewarded with a lot of gratitude! :D
-
I'm also asking for help about joysticks handling : there is nothing about them in apple doc. If someone has already worked with them it would really be appreciated! Otherwise I'll search on the web, of course.
-
Currently I'm trying unsuccessfully to find out how to convert an image data (width, height, array of Uint8) to a NSImage to set up the application icon.
The following link should help:
http://stackoverflow.com/questions/2496113/creating-nsimage-from-nsbitmaprep-from-int-using-nsdata
-
(http://craigswinejourney.files.wordpress.com/2009/08/doublefacepalm.jpg)
I read this method in the doc… Arrrgg
Thank you!
-
You should think about whether implementing SetIcon() is useful. The point is the application's icons often appears in the window bar on Windows, but hardly ever on Mac OS X. With the latest, the application icon is only visible in the Dock. The purpose is to keep being consistent with the OS being used.
-
On this point I disagree. Indeed the SetIcon will not behave _exactly_ the same way for end-user experience as it will have on other operating system, that is setting the application icon instead of the window icon which doesn't exist on Mac. But it will (I hope) be appreciate that developers using SFML can modify the application icon to be more into the look-&-feel of Mac, that is having this icon in the dock and when switching from an application to another with cmd-tab.
The only «default» I see will only happen when there are more than one window open AND with different icon : calling SetIcon a second time will erase the first icon.
But it's only my point of view and if some people disagree with me then I will, of course, not implement this feature. :wink:
-
Even if it the icon appears only in the dock, why shouldn't we provide the ability to set it? It's still better than a default system icon, right?
-
And I would have displayed a big huge fancy image above for nothing ? :P
-
The only «default» I see will only happen when there are more than one window open AND with different icon : calling SetIcon a second time will erase the first icon.
That “could” be annoying. I dunno how icons are stored on Windows. Are they set programmatically ?
Because on Mac OS X, you put the icon in the application bundle, add the information to the Info.plist file (in the bundle application too), and the icon is set. Thus I wonder what's the best thing to do.
-
If I'm right it's the same system on Windows : you write something into a .rc file at compilation time. But you certainly can do it programmatically, too.
I understand your point of view. It would be annoying if and only if you have such .plist file with icon.
But how many SFML users will have a .rc, a .plist (and some stuff for Unix) ? I don't know. (nor rhetoric and stylistic effect)
-
Actually, blind folks who need speech already have a screen reader, so it's not really useful in that regard. I was thinking more along the lines of saving the developer time and trouble, in that they wouldn't need to record sound files for characters talking, they could just generate the speech on the fly, saving both disk space, and memory. It would also allow developers to get prototype
A text-to-speech API is not really on the todo-list.
It would obviously be helpful for blind people, but what other purpose could it have? Moreover, those system-specific APIs probably use the same voice file format.
-
By the way, I meant "those system-specific APIs probably don't use the same voice file format".
-
I'm still looking for the bug in my code (OSX port). I may have read the lines more than once... Maybe some fresh eyes could spot the error... If you have some knowledge of OpenGL, Cocoa and Obj-C please look at this code.
Of course, any comments on the code structure and style is welcome. :wink:
You can download the archive containing the last source here : http://www.mediafire.com/?ru7rw3zv3va0bma
(If you need anything else, please ask!)
-
Anyone? :(
-
Hiura:
I downloaded the archive you linked to on mediafire. On OSX 10.6.4 with Xcode project file sfml.xcodeproj, set to configuration "dev_10_6":
I get link errors trying to build the window target.
Ld ../../lib/sfml2-window-64-dev.framework/Versions/10_6-dev/sfml2-window-64-dev normal x86_64
cd /Users/lew/Desktop/sfml2/build/xcode
setenv MACOSX_DEPLOYMENT_TARGET 10.6
/Developer/usr/bin/g++-4.2 -arch x86_64 -dynamiclib -isysroot /Developer/SDKs/MacOSX10.6.sdk -L/Users/lew/Desktop/sfml2/build/xcode/../../lib -L/Users/lew/Desktop/sfml2/build/xcode/../../extlibs/bin/x86_64 -F/Users/lew/Desktop/sfml2/build/xcode/../../lib -F/Users/lew/Desktop/sfml2/build/xcode/../../lib -filelist /Users/lew/Desktop/sfml2/build/xcode/sfml.build/dev_10_6/window.build/Objects-normal/x86_64/sfml2-window-64-dev.LinkFileList -install_name /Users/lew/Library/Frameworks/sfml2-window-64-dev.framework/Versions/10_6-dev/sfml2-window-64-dev -mmacosx-version-min=10.6 -framework Cocoa -framework OpenGL -framework IOKit -prebind -single_module -o /Users/lew/Desktop/sfml2/build/xcode/../../lib/sfml2-window-64-dev.framework/Versions/10_6-dev/sfml2-window-64-dev
Undefined symbols:
"sf::GetDefaultLocale()", referenced from:
sf::priv::WindowImplCocoa::SetTitle(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)in WindowImplCocoa.o
"sf::Clock::GetElapsedTime() const", referenced from:
sf::Window::Display() in Window.o
sf::Window::Display() in Window.o
"sf::Clock::Clock()", referenced from:
sf::Window::Window()in Window.o
sf::Window::Window(void*, sf::ContextSettings const&)in Window.o
sf::Window::Window(sf::VideoMode, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long, sf::ContextSettings const&)in Window.o
"sf::ThreadLocal::~ThreadLocal()", referenced from:
___tcf_0 in GlContext.o
"sf::ThreadLocal::ThreadLocal(void*)", referenced from:
sf::ThreadLocalPtr<sf::priv::GlContext>::ThreadLocalPtr(sf::priv::GlContext*)in GlContext.o
"sf::Clock::Reset()", referenced from:
sf::Window::Display() in Window.o
sf::Window::Initialize() in Window.o
"sf::Err()", referenced from:
sf::Window::SetActive(bool) constin Window.o
sf::Window::Create(sf::VideoMode, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long, sf::ContextSettings const&)in Window.o
sf::Window::Create(sf::VideoMode, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long, sf::ContextSettings const&)in Window.o
sf::priv::VideoModeImpl::GetFullscreenModes() in VideoModeImpl.o
sf::priv::VideoModeImpl::GetFullscreenModes() in VideoModeImpl.o
sf::priv::SFContext::CreateContext(sf::priv::SFContext*, sf::ContextSettings const&, unsigned int)in SFContext.o
sf::priv::SFContext::CreateContext(sf::priv::SFContext*, sf::ContextSettings const&, unsigned int)in SFContext.o
sf::priv::WindowImplCocoa::SetIcon(unsigned int, unsigned int, unsigned char const*)in WindowImplCocoa.o
sf::priv::WindowImplCocoa::ProcessEvents(bool) in WindowImplCocoa.o
sf::priv::WindowImplCocoa::WindowImplCocoa(void*)in WindowImplCocoa.o
sf::priv::WindowImplCocoa::WindowImplCocoa(void*)in WindowImplCocoa.o
sf::priv::WindowImplCocoa::WindowImplCocoa(void*)in WindowImplCocoa.o
"sf::ThreadLocal::SetValue(void*)", referenced from:
sf::ThreadLocalPtr<sf::priv::GlContext>::operator=(sf::priv::GlContext*)in GlContext.o
"sf::Sleep(float)", referenced from:
sf::Window::Display() in Window.o
"sf::ThreadLocal::GetValue() const", referenced from:
sf::ThreadLocalPtr<sf::priv::GlContext>::operator->() constin GlContext.o
sf::ThreadLocalPtr<sf::priv::GlContext>::operator sf::priv::GlContext*() constin GlContext.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
Is the project building for you? If so, is there anything special you are doing to get it to build? Am I using the wrong xcode project file?
-
I'm still looking for the bug in my code (OSX port).
I couldn't figure out what bug you were referring to by reading the thread. I'm not really proficent with ObjC or Mac programming in general, but I'm willing to give a look if I can know what I am looking for.
-
automata,
First I want to thank you for your time! :)
Try to compile the «all» target. Because window module requires system module which seems not to be built yet the compilation fails.
Second, about «the bug» I may as you say forget to speak about it in this thread. So :
The problem is related to rendering and not to event/...
The SFML window module works fine or at least seems to work fine. OpenGL applications work correctly : they draw in 2D/3D their stuff as they should do.
But the graphics module doesn't work accurately. As soon as I use some graphics component I get either nothing (for example trying to display a sf::Image with a sf::Sprite display nothing onto the screen) or some really
funky stuff like http://hiura.tuxfamily.org/online/other/sfml/sfml_opengl_sample_failure_2010_08_17_21_55.tiff .
Please ask for any further information that seems important.
-
That solved some problems; the linker gave me errors relating to OpenAL, but I am pretty sure that is due to the fact that the OpenAL development libraries on my computer have been corrupted (due to my ignorance while messing around a year back). By deleting the Audio framework from the build targets I bypass all of that, but still remain with a cryptic error in XCode's build script:
/bin/sh -c /Users/lew/Desktop/sfml2/build/xcode/sfml.build/dev_10_6/all.build/Script-4C2639F61219B1B70074EB9F.sh
usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-apvX] source_file target_file
cp [-R [-H | -L | -P]] [-f | -i | -n] [-apvX] source_file ... target_directory
Command /bin/sh failed with exit code 64
(The .sh file just contained the command to copy .framework files to a folder.) Very weird, I think it's probably something uniquely messed up about my computer though, not a general problem. Unfortunately this means I probably won't be able to do any experiments with the code until I get a chance to do a clean OS reinstall.
About your problem: That screenshot looks exactly like what I've seen happen in earlier versions of SFML for OSX in minimal graphical test programs with no calls to either Draw() or Clear(), just Display(). What seems to happen is that the SFML program recieves a junk graphical memory recycled from other programs, and displays that if it isn't overwritten by the program. Since using sf::Image and sf::Sprite gets you a blank screen, something involved in their use probably forces a Clear() on the RenderWindow.
Here is my theory: You can render OpenGL with Window, but the RenderWindow class fails. The main difference between these two seems to be that RenderWindow has a Draw() method. There is probably a problem with something used by Draw(), either a function called or some data that isn't getting properly set by some other system.
Since presumably this is a bug specific to the OSX implementation, maybe somewhere down the chain is failing silently. I'd check to see if there is some point at which a call to the system fails, it signals that error by returning a null pointer rather than a pointer to data, and then the SFML code treats that null as if it were optional data rather than an error signal.
Good luck!
-
About the sh script : it has nothing to do with your computer but "simply" a folder is missing in the copy path. Create all the directory, that is ~/Library/Frameworks/.
I'll investigate further your ideas as soon as I have some free time. Thanks.
-
I also forget something. If you try to run a SFML app which uses the graphics module you'll get an error at launch : you have to copy the extlibs to /usr/local/lib/. If you don't have a 64 bits machine you'll have to compile some of these extlibs.
-
Yeah, the directory not existing was what was causing it to fail; SFML2 compiles now!
Unfortunately I can't figure out how to get any of the example projects to build. The first issue I run into is that it looks for the frameworks in the wrong hard-coded location, like:
/Users/marcoantognini/Library/Frameworks/sfml2-graphics-64.framework
That was easy enough for me to change (to my own hard-coded path; there has to be a portable way of doing this), but building the project gives me errors on every function call that exists in SFML2 but not SFML. Obviously the compiler is looking at my old installed SFML library instead of my newly compiled SFML2 library, but I'm not sure how to let it know that I don't want that. Am I missing some obvious way to do this?
-
that's strange, I don't remember using any hard path but only path based on variables... Strange... Anyway, the simplest way I know is to remove the old SFML packages. I also tried to use some non-standard paths for .framework but I couldn't make it works...
-
Ok, good news is I have fixed the drawing bug. I really appreciate all your help! Thanks a lot! :wink:
-
Ok, good news is I have fixed the drawing bug. I really appreciate all your help! Thanks a lot! :wink:
Awesome! :D