What about Cider, Lindens?

Why not do what a lot of other game companies have done (as with Prey, etc) and screw attempting to force a direct port to work on OS X nicely, and run it under the Cider API? All you need to do is make a nice deal with Transgaming and I'm sure they'll let you in on shipping a pretty Cider blob along with Second Life for OS X. Then you guys can stop wondering how to fix it and just stick with the straight port.

I promise I won't come after you for any sort of fee if you decide to do it, too. Aren't I nice?

If they do that, it kills off any PPC macs out there - and there are a bunch that still work fine w/ SL.

Excuse me, but can you enlighten me as to what is so wrong with the Mac SL client? Did you read my previous post in this forum about GPU RAM?

Second Life runs great on both of my Macs and I've had no problems lately. Apple fixed their graphics drivers with 10.5.2 and it's been smooth sailing.

Native ports are the way to go with OpenGL applications. That's the beauty of OpenGL; it's CROSS-PLATFORM.

Stop giving Linden Labs bad ideas, they have enough without your help*.

* - No offense to any Lindens reading this, but seriously, allowing unverified accounts? What were you on?

I set my video ram usage down and I stil lget freeze ups. Some so bad it freezes the mac completely till its done doing whatever it was doing.

I have a new macbook pro with a 2.4 ghz processor and 512 mb of video ram. I set the vid ram down to 256 in the hardware options under graphics. I also have the quality set to mid even though it can go high.

Any other thoughts?

Cider?

lets se... probably because Cider wont even run SL? Cider is for DirectX... which SL doesn't use. Cider is also very crappy compared to a native port. We don't need to be running the windows version being translated on the fly... when we already have a really good native version. yes i said really good....

Cider would be a very bad idea. But thanks for playing.

Yeah I saw your previous post, but guess what---IT DID NOT WORK. I halved it, I quartered it, I doubled it, all with precisely the same results:

marbles of death for at least 60 seconds every few minutes, and creeping slowness to ONE frame per second after about a half an hour.

As ive repeatedly said (and now im quite sure about), this is not a GPU problem, at least not in my case. It's that LL has ONE guy doing a STRAIGHT port from the windows client to OS X, and no one will hire him any help in the form of at least one person who understands that OS X has its own very good way of thread and memory management, and that straight ports to OS X NEVER WORK WELL.

You dont know what youre talking about. We do NOT have a native version, we ARE running the windows version translated---thats what a straight port is. And Cider doesnt translate "windows versions on the fly", it only supplies the API that SL WANTS to talk to.

Do you even understand the architecture of the software that you're using?

Not only do I understand that, but I know how not to be rude to people on forums. It's a neat trick. You should try it sometimes.

We certainly _are_ running a native version, in that it was compiled on a Mac, using Xcode and the appropriate native libraries. It is as native on this as on any other platform; I'm sure there are certainly things which could be better optimised but it isn't as if this is some horrible DirectX port or anything.

Ahem, if it's a native port, then why doesn't it understand anything at all about how OS X manages its memory, threads, or perhaps most importantly, paging?

This is a straight port---which means that it was indeed COMPILED ON A MAC (actually that doesnt matter, you could compile it on a goats nuts if you had the right compiler), and yes it MUST use some native libraries, since licensing prohibits importing windows DLLs directly.

But it really has no idea what OS X is or does, or how to run efficiently on it. This is clearly a BETA port, and not at all ready for prime time. It will be ready for prime time when the sole OS X programmer they have at LL has the time to figure out how to get (among a vast array of other things) its ancient rendering engine to thread properly and not page to disk before its RAM is full.

It would probably be worth examining the tweaks they did for the Linux version (which by the way, runs perfectly on FreeBSD with linux binary emulation) and import a few of those.

But again, its a big job, and the root of this problem is that LL just doesn't take it seriously. If they did, they would have hired at least two more people to help that poor schlep get something out the door that works properly. One person cannot do this by themselves.

The Mac client isn't so bad, but what it really needs is someone going through all the most intensive parts, using OS X libraries to optimise them. So long as it's done properly the OS X enhanced code can exist within the same source-code with Windows and Linux. So long as new features/fixes etc. that affect code with OS X enhancements are referred to the person that did the enhancements, then it shouldn't be an issue keeping things running smoothly.

For example, a lot of the vector-maths stuff could be enhanced by using OS X vector libraries and/or the accelerate API (though accelerate.h's best features are only available on OS X.4 and above).

You're right, it doesn't make good use of OS X features. It also doesn't make good use of Windows or Linux features. All three compile from the same code, and that code contains as few platform-specific exceptions as is possible. This is the only way a small team can create a complex GUI program for all three platforms. There otherwise probably wouldn't even be a Mac version.

It's surprising that in 2008 there isn't a good, cross-platform GUI builder, but there you have it. SL was conceived 1999-ish, when the Mac market share was in the toilet. If they were to start from scratch in 2008 I'd hope they'd make native versions for both Windows and Mac, but a 1999 team did about as well as they could have to create a cross-platform viewer just the way they did.

Calliope, you seem to have some pretty deep insider information on how Linden has their Mac development system set up. Who is this "one person" to whom you keep referring? Did Linden let you know specifically that they have one person to handle all the Macintosh coding/porting? Have you spoken to this person? Enlighten us, please.

No. The code is actually mostly windows specific.

It's been common knowledge since the position was created that it would be one position for one person. To my knowledge, this person has never publicly commented on any of this stuff, but the position (and the person) have come up occasionally over the last couple of years in both public Linden discussions and these very message boards.

It's not deep insider information---there's actually much, much less there than meets the eye. It's only a matter of listening, that's all.

wow I should look through old threads i commented on more often... heck we need an old post back up top anyways, its getting boring.

I don't know what I'm talking about? give me a break... yes its native, you don't know what that even means... and yes Cider is a version of WINE and it does just translate things on the fly and runs the actual Windows compiled code. It doesn't just supply the API, it takes the Windows calls and translates them into something usable on OSX... its a LOT more overhead than just adding APIs to the machine, even if thats the effective end result of functionality.

You really need to learn what your talking about, and not just think you know, before you go off telling other people they don't know what they are talking about.