Author Topic: Mac OS X port to be continued (Read 57431 times)

Ceylo · « **Reply #15 on:** August 31, 2009, 10:33:47 am »

Then see what ? :?

Laurent · « **Reply #16 on:** August 31, 2009, 10:59:30 am »

See the other ports, or me

Terrydil · « **Reply #17 on:** September 19, 2009, 05:57:06 pm »

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.

Ceylo · « **Reply #18 on:** September 20, 2009, 02:42:57 pm »

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.

didito · « **Reply #19 on:** October 12, 2009, 01:32:57 am »

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

Ceylo · « **Reply #20 on:** October 12, 2009, 06:35:49 pm »

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

.

didito · « **Reply #21 on:** October 13, 2009, 03:57:33 pm »

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

Laurent · « **Reply #22 on:** October 13, 2009, 04:05:50 pm »

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.

didito · « **Reply #23 on:** October 13, 2009, 04:21:29 pm »

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.

Laurent · « **Reply #24 on:** October 13, 2009, 07:19:34 pm »

Quote

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.

Quote

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.

Quote

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

Ceylo · « **Reply #25 on:** October 13, 2009, 08:26:02 pm »

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

Quote

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

Quote from: "didito "

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.

Quote from: "Laurent "

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 and AppKit frameworks (the two components of Cocoa) and the changes in the Carbon 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.

NocturnDragon · « **Reply #26 on:** February 24, 2010, 07:59:30 pm »

Hello Ceylo and Laurent, do you have any news on the OS X topic?

Ceylo · « **Reply #27 on:** February 24, 2010, 08:05:05 pm »

About the next Mac OS X developer or the SFML port status ?

NocturnDragon · « **Reply #28 on:** February 24, 2010, 08:10:33 pm »

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.

Ceylo · « **Reply #29 on:** February 24, 2010, 08:32:39 pm »

There is absolutely no news about the next Mac OS X developer, and thus no news about SFML 2.0. Sorry :roll: .