End of the official Mac OS X port

[fredgiblet]

I really don't see why the openttd devs can't just compile a binary for mac, simply say it's unsupported (with bright, bold neon letters) and leave it at that while looking for a dedicated mac developer.

Because, as they stated several times, it makes maintaining the supported builds take a lot longer too, which means it still requires lots of work but produces a steadily poorer product. I believe that earlier in the thread one of the devs said that their compiling time went from 4-6 hours to 45 minutes after cutting the OSX version (but I freely admit I'm too lazy to re-read the thread to provide a more specific citation).

[Rubidium]

You're mixing time needed to release and time needed to compile.

The time needed for a release where the 'maintainer' of the port would compile OpenTTD and upload it to the download location went from 4-6 hours to 45-60 minutes by doing everything on the compile farm.

The time needed to compile is reduced by about 30% by ditching the Mac OS X port; it takes 45-50 minutes on our compile farm, whereas making all 3 Windows binaries takes 30-35 minutes and building the rest (4 linux binaries, packaging source and source documentation) also takes about 30-35 minutes. In this case each is using a single core of a quad core CPU and the remaining 1 core is used for the website and the other processes. The compile time can't be easily reduced by giving the Mac OS X compiler more cores because the virtual machine the compilation runs in doesn't support that (with the version that is running on the compile farm).

You might think that a compile run can now take only 20-25 minutes, but that would mean we need to make a duplicate of the Windows virtual machine which makes maintaince difficult. As such a compile farm run now, without Mac OS X, takes longer than it technically can.

[wiinf]

Quick question though: Do you compile that often that the 45 minutes of the OS X port really carry weight?

[Terkhen]

Nightly builds are compiled on a daily basis.

[wiinf]

Ok, but on a daily basis i wouldn't see 45 minutes as a show stopper! Even if it were plenty times optimized and running on special hardware and whatsoever it would take at least 10-15 minutes. So are these 30 minutes daily really that critical?
I also still don't get why it takes 45 minutes at all. If i compile myself it's not even 5 minutes. Could someone explain to me please?

[Rubidium]

Get some things straight first: the 45 minute compile time is NOT an issue at ALL.

Those 45 minutes include acquiring the source, starting the virtual machine with the cross-compiler, shutting down the virtual machine, uploading the binaries and mirroring those binaries to the mirrors. The actually compilation takes 38-39 minutes.

That being said it is likely that you are running on a dual core computer and the compilation uses both cores, on OpenTTD's compile farm it only uses one core, as such a factor of 2 difference can be expected. Furthermore you are likely to be building for only one architecture and not an universal binary for three architectures, as such a factor 3 of difference can be expected. Finally OpenTTD's compile farm uses a compiler built without release optimisations.

Now the math: 39 minutes divided by 2 (dual core) divided by 3 (universal binary) gives 6.5 minutes given your likely setup. That is only 30% slower than you can build it, but you're not using a virtualised environment (thus slow I/O) nor are you using a compiler without release optimisations. So all in all the compile farm isn't as slow as it seems when you're starting to make a fair comparison.

[wiinf]

Sorry Rubidium if it looked like i was trying to make an unfair comparison. That was definately not my intent! I just wanted to understand the time difference and that's what your explanation did. Thanks very much!
So, as i understand the discussion up to now, time on the compile farm, hardware, etc. are all minor problems that wouldn't stop you from providing an official Mac OS X port. The real reason you want to take this step is because you're lacking a Mac OS X developer.
With that said i guess we can kinda stop the discussion about the "why?" and rather focus on "How to get a Mac OS X developer for OpenTTD?". Right?

[Yexo]

With that said i guess we can kinda stop the discussion about the "why?" and rather focus on "How to get a Mac OS X developer for OpenTTD?". Right?

Yes. That was also the conclusion in the second post (emphasis mine):

Above we have given you a description of the current situation of the Mac OS X port. The bottom line is that, unless we find a new active developer with Mac OS knowledge who wants to keep the port alive, we see no other solution than to drop Mac OS X support. What is support if the soon-to-be most used version of an operating system is not supported?

[fredgiblet]

@wiinf

Don't forget, it's not just about time. If they could maintain a high level of quality the time likely wouldn't be an issue, the root problem is that without a developer that time is being spent on a product that will degrade as time goes on. If they add the new features to the Mac version then they will add bugs that won't be fixed, eventually either the number of bugs will render the program unusable or else there will be a showstopper bug (like say crashes every time you load a savegame) at which point they would have to either roll back to a previous version and abandon development then or else put more resources (which they don't have) into fixing it. Without a dedicated Mac developer the users will actually be worse off if the devs try to maintain the Mac version than if they just abandon it now.

[mrheuss]

I've been playing this for years, and I am a Mac Developer - so let me head on over to the source and see what I'd be getting in to.

Can anyone tell me approximately how big of a commitment we are talking about here, timewise?

[Bjarni]

Additionally you can test basic functionality of the PPC port on an Intel machine by forcing Mac OS X to run the PPC portion of a universal binary.

One of the reasons why I was happy that I managed to make an Intel port quickly is because it turned out that Rosetta causes OpenTTD to crash. It's possible that Rosetta has been improved but I haven't tested it. Oddly enough the first intel binary didn't have any of the issues we suffer from now. They are all due to Apple changing stuff when moving to 10.5/10.6 and/or new hardware.

Koda, thanks for your efforts and more over, a 64 bit build? whoa!

Trunk already could build, or at least once had the ability to build, 64 bits Mac binaries. Some testing has shown that these binaries are slower than their 32 bits equivalent and as such we haven't looked into building them with the compile farm. Furthermore doing so would make the Mac universal binary roughly 16 MB and take another 30 minutes to compile; it already takes 45 minutes on the compile farm. Those 45 minutes are already 10 minutes more than we need to compile *all* nine other binaries on the remaining two cores.

Actually I did the test for PPC only. Apple states (or stated at least at that time) that PPC64 should only be used for special purposes (such as accessing more than 4 GB from the app) because it would likely make the application slower. My test confirmed this. I never tested 32 vs 64 bit on Intel due to lack of hardware and reading about this issue indicates that the slowdown is for PPC only. Intel binaries should gain speed when moving to 64 bit.

I've been playing this for years, and I am a Mac Developer - so let me head on over to the source and see what I'd be getting in to.

Can anyone tell me approximately how big of a commitment we are talking about here, timewise?

This sounds really great. Timewise.... well good question. The honest answer is that I simply don't know. My guess is that it can be done within reasonable time provided whoever codes/plans the coding knows Apple APIs well. OpenTTD have split the code into shared code and OS specific code. This means locating the few OSX specific source files shouldn't be tricky and OS specific issues are usually located in the OS specific files. Also while coding it could be advisable to tune in to the IRC channel as there are people there who can answer questions about the code right away (provided they are online, that is)

[hoserama99]

I've been playing this for years, and I am a Mac Developer - so let me head on over to the source and see what I'd be getting in to.

Can anyone tell me approximately how big of a commitment we are talking about here, timewise?

If mrheuss opts to pass, I'd be happy to do the job if no one else steps up. I do Mac ports for my "day job" and this seems fairly straightforward.

[wiinf]

Hey Brad,

just go ahead! That's the nice thing about an open source project. Anybody that wants to help can help. Even if we got two Mac OS developers it wouldn't hurt in any way...

[Bjarni]

I've been playing this for years, and I am a Mac Developer - so let me head on over to the source and see what I'd be getting in to.

Can anyone tell me approximately how big of a commitment we are talking about here, timewise?

If mrheuss opts to pass, I'd be happy to do the job if no one else steps up. I do Mac ports for my "day job" and this seems fairly straightforward.

Thanks,
Brad Oliver

I don't think it would hurt if more than one person took a look. Not only would it be interesting to see if planned solutions are similar (in a way I hope they aren't because then people would start to consider what would be the best solution) and it would also make people able to assist each other if they are stuck on some problem. Another reason why taking a look would be a good idea is experience. I have seen plenty of times that people show up stating that they will code something. They may get started and reports a progress but before you see the result they disappears. This means that while I like to believe that both of you are up to the task I don't want to be the one to assign this to one person and kick out everybody else, only to discover that the first person disappears, leaving us with nothing. At the same time it would be pointless for several people to write identical code at the same time. Basically this means people should try to speak together, specially when they have an idea of what to code, which means distributing workload could be an option.

[hoserama99]

Basically this means people should try to speak together, specially when they have an idea of what to code, which means distributing workload could be an option.

So I took a quick browse of the open Mac bugs in Flyswatter. It looks like there are only 2 or 3 left in the meta-bug.

The one that jumped out at me most was the fullscreen palette bug, and I added a comment to it with a brief explanation of what's going horribly wrong. The short version: you can't rely on 8-bit mode support in 10.5 and 10.6 to work at the OS level; they're being deprecated and removed.

So a question for those in the know: is sticking with a 32-bit blitter acceptable? This is probably the easiest solution.

If not, the next-best solution that jumps out to me is using OpenGL to do 8-bit palettized blits (using a 1D 256-texel-wide texture as the palette lookup in an ARB fragment program).

Assuming for the moment the code quality is acceptable, would that be an OK approach for the dev team to accept?

[muhtadi]

Just wanted to say I'm glad people are finally stepping up to volunteer as mac devs. Good luck guys and I hope we can finally have progress on this front.

[andythenorth]

Anyone who can keep the Mac port alive would have my thanks.

cheers,

Andy

[Bjarni]

The one that jumped out at me most was the fullscreen palette bug, and I added a comment to it with a brief explanation of what's going horribly wrong. The short version: you can't rely on 8-bit mode support in 10.5 and 10.6 to work at the OS level; they're being deprecated and removed.

So a question for those in the know: is sticking with a 32-bit blitter acceptable? This is probably the easiest solution.

Err... isn't it hardcoded to use 32 bit as it right now unless specifically told otherwise? I remember writing some code to select 32 bit blitter on OSX 10.5+ unless the user selected 8 bit by manually editing openttd.cfg. It would be interesting if you still think this is the problem.

If not, the next-best solution that jumps out to me is using OpenGL to do 8-bit palettized blits (using a 1D 256-texel-wide texture as the palette lookup in an ARB fragment program).

This sounds interesting. It would provide 8 bit palette animation at presumably reasonable speed. However OpenGL would introduce it's own issues. It's an open question if it's worth it.

Assuming for the moment the code quality is acceptable, would that be an OK approach for the dev team to accept?

Speaking for myself I say I want "the best" solution. This means it should be bugfree and fast enough for decent gameplay. If somebody comes up with an idea on how to get rid of the bugs and make it really fast, then I would like to hear about it, even if it means rewriting a great deal of OSX specific code. I suspect the current code leaves room for improvement since we are in shortage of OSX GUI gurus
Having said this I also state that changing for the sake of changing isn't the way to go. Naturally the change would need to be reasonable compared to the gain.

A little note about the speed issue. One might think that it's not a major concern these days but fast forward works by ignoring the wait between ticks. It turns out that the graphics are actually reducing speed quite a deal when fast forwarding. If you try to fast forward in 10.4 and 10.5 then you will see what I mean. 10.4 is using code, which aren't working in 10.5 and fast forward is a lot faster. It would be nice if it weren't graphics which reduce the speed of fast forwarding. It's not the major issue here, but it's worth considering if something is changed anyway and if a new design is needed.

[peter1138]

With SDL in X11, 8bpp has always been emulated on non-8bpp displays, and performance is acceptable. Using OpenGL to do it could well be faster, so if you do go this route it should be as generic as possible to work in X11 and Windows. IMHO.

[hoserama99]

The one that jumped out at me most was the fullscreen palette bug, and I added a comment to it with a brief explanation of what's going horribly wrong. The short version: you can't rely on 8-bit mode support in 10.5 and 10.6 to work at the OS level; they're being deprecated and removed.

So a question for those in the know: is sticking with a 32-bit blitter acceptable? This is probably the easiest solution.

Err... isn't it hardcoded to use 32 bit as it right now unless specifically told otherwise? I remember writing some code to select 32 bit blitter on OSX 10.5+ unless the user selected 8 bit by manually editing openttd.cfg. It would be interesting if you still think this is the problem.

The bug comments suggest that it only happens for the 8-bit fullscreen case, but I haven't done due diligence or tried to repro it myself yet. This also answers my next question about how one goes about enabling 8-bit fullscreen modes.

Is there any objection to putting some of these config options in a Mac UI where they are more discoverable?

This sounds interesting. It would provide 8 bit palette animation at presumably reasonable speed. However OpenGL would introduce it's own issues. It's an open question if it's worth it.

OK, let's talk hypotheticals. What issues are you envisioning with GL? My view is that a GL path would only be enabled for the subset of users on 10.5 who have an SM 2.0-compliant renderer (e.g. ARB fragment program). Users on 10.4 would have working 8-bit modes in CoreGraphics, and those on 10.5 with SM 1.0 renderers (Radeon 9200 and lower, GeForce 4 and lower) will also have working 8-bit modes as the video drivers were deprecated and frozen. (Disclaimer: I used to work at Apple on the OpenGL team.) For the rest, GL should introduce a nice boost.

Speaking for myself I say I want "the best" solution. This means it should be bugfree and fast enough for decent gameplay. If somebody comes up with an idea on how to get rid of the bugs and make it really fast, then I would like to hear about it, even if it means rewriting a great deal of OSX specific code. I suspect the current code leaves room for improvement since we are in shortage of OSX GUI gurus
Having said this I also state that changing for the sake of changing isn't the way to go. Naturally the change would need to be reasonable compared to the gain.

Agreed.

A little note about the speed issue. One might think that it's not a major concern these days but fast forward works by ignoring the wait between ticks. It turns out that the graphics are actually reducing speed quite a deal when fast forwarding. If you try to fast forward in 10.4 and 10.5 then you will see what I mean. 10.4 is using code, which aren't working in 10.5 and fast forward is a lot faster. It would be nice if it weren't graphics which reduce the speed of fast forwarding. It's not the major issue here, but it's worth considering if something is changed anyway and if a new design is needed.

Nice to know. I haven't gotten so far as to start profiling other than to note it was taking up a relatively small % of the CPU on my 1.83 Core Duo iMac. I'll keep this in mind as a hotspot.

I got it building and created a native Xcode project (based on the makefile) yesterday to get up to speed. I noticed there's a set of Visual Studio projects in SVN, so it seems there's no general resistance to project files.

Can someone give me some guidelines on end-user expected requirements for the Mac? Were it up to me, I'd make the OS minimum 10.4.x for example.