PDA

View Full Version : LightWave Mac v9.6 Hotfix and Cocoa Update - 19 May 2009



Chuck
05-19-2009, 02:06 PM
Hello, Mac 'Wavers! :)

Welcome to this week's progress note on our Mac development activities!

On the Cocoa front, the developers continue to report good progress on the Cocoa conversion. We had mentioned last week that after wrapping up popup menus, development would move on to other areas of the UI; however, they've taken a detour into working on audio support instead and are about halfway through adapting for Mac CoreAudio, which should have some good implications for finally bringing Lightwave's Mac audio capabilities up to snuff. Following that, they will proceed further on the UI, and then to updated Quicktime support, etc. We'd project about four to eight weeks out, subject to change based on the issues encountered.

Work continues on killing bugs for the v9.6 hotfix update, and on the management review of open bugs to identify priorities for this round of fixes. There are already a lot of fixes of multi-platform issues, and the Cocoa work is accounting for many of the Mac-specific bugs; and as the conversion work wraps up, we will be doing a thorough review of bugs to clean up many that the Cocoa work does not cover.

Yep, We're Going to Mention This Every Time, Dept.: It is very important that you get in reports on any bugs that you may have encountered, but not reported yet. Don't forget to include steps and content, as they are needed to insure that we can duplicate your bug properly and get it fixed. For those of you who need a refresher as to how to report bugs, check this link:

Instructions for Bug Report and Feature Request Database (http://www.newtek.com/forums/showthread.php?t=73227)

Kuzey
05-20-2009, 05:48 AM
Now you guys are cooking. :thumbsup:

I love this....it reminds me of the good old Newtek :D

Just thinking.....have you tackled the bug/performance issues in 9.6 when using objects/scenes made in older versions of LW.

Keep up the good work.

Kuzey

Tony3d
05-20-2009, 06:55 AM
Excellent! This is what I'm talking about. This is the way to do business!

4dartist
05-20-2009, 08:45 AM
Great news! I'm glad to hear that using the cocoa code is clearing a lot of issues in it's own right. I'm really excited for this to come out.

Scazzino
05-20-2009, 09:34 AM
Thanks for the update Chuck!

It's great to hear about the progress.

Thanks for keeping us in the loop! :thumbsup:

PaulP
05-20-2009, 06:57 PM
Can anyone confirm if the 64 Bit version of LW 9.6 will run under OS X 10.4.11 and a G4 power Mac ?

thanks

CGI Addict
05-20-2009, 07:21 PM
Thanks Chuck, we appreciate the update!

rsfd
05-21-2009, 03:29 AM
@ PaulP
the PPC G4 does not offer 64-bit capabilities, I'd assume that at least a G5 chip will be needed for LW-64 UB.

PaulP
05-21-2009, 04:02 AM
rsfd,

many thanks for your reply. Well, I will assume for now that a G5 and OS X 10.4.11 are the minimum system requirements, until one of the kind folks from Newtek says otherwise.

Thanks again.

Lightwolf
05-21-2009, 06:02 AM
rsfd,

many thanks for your reply. Well, I will assume for now that a G5 and OS X 10.4.11 are the minimum system requirements, until one of the kind folks from Newtek says otherwise.

Thanks again.
I'd doubt it. You need 10.5 for 64-bit apps with a GUI.
Unless NT release two binaries, one 32-bit UB that can run under 10.4, and another 32/64-bit UB that can requires at least 10.5

Cheers,
Mike

Chuck
05-21-2009, 01:31 PM
rsfd,

many thanks for your reply. Well, I will assume for now that a G5 and OS X 10.4.11 are the minimum system requirements, until one of the kind folks from Newtek says otherwise.

Thanks again.

10.5 is required for the 64-bit version.

Chuck
05-21-2009, 01:33 PM
Now you guys are cooking. :thumbsup:

I love this....it reminds me of the good old Newtek :D

Just thinking.....have you tackled the bug/performance issues in 9.6 when using objects/scenes made in older versions of LW.

Keep up the good work.

Kuzey

If you've got some numbers for bug reports with content on those issues I can make sure they get looked at.

Kuzey
05-21-2009, 02:11 PM
Hi Chuck...sent them via pm.

There are three in all, one is closed but I believe that change caused the sluggish behavior as reported in one of the other cases.


Kuzey

jayroth
05-21-2009, 04:00 PM
Now you guys are cooking. :thumbsup:

I love this....it reminds me of the good old Newtek :D

Just thinking.....have you tackled the bug/performance issues in 9.6 when using objects/scenes made in older versions of LW.

Keep up the good work.

Kuzey

In many cases, those are not bugs, as we have reviewed many times. In particular, anything to do with GI will produce very different results, both in terms of render times and image quality, using the same numbers across different versions.

Why? Several reasons, actually. The first one being that we have made the system significantly more efficient. As a result, you can now get away with much lower values for most of the attributes in the GI panel, and the image quality will be better than the higher numbers in previous versions. Lower numbers render faster. If you have an older scene, and try to render it in v9.6 unchanged, you will likely not be too impressed. However, if you make the adjustments, v9.6 will knock your socks off.

This is an optimization, not a bug. You get more for less here. And no, we cannot change those values on scene read, for a variety of reasons. The biggest reason is intent -- we cannot divine what you wanted to do with the older scenes, so its much better for you to change those values yourselves than if we try to do it for you. Another reason is the type of optimization involved. In many cases, the improvements we put in were actually completely different algorithms that use different values; oftentimes, there is no direct way to map them over. Again, human intervention is the best case scenario here.

Of course, there are many such examples where the above scenarios are true for areas other than GI; I would recommend referring to the release notes of the various builds to get a handle on those.

Lastly, there are cases where v9.6 might be somewhat slower than, say, v8.x. This typically is a load balancing issue: as we advanced the algorithms throughout the v9.x series, we were able to significantly enlarge the capacity of the system. We tweaked it to be much more favorable to heavier datasets with lots of demands placed upon them (physically accurate materials, GI that works, etc.). As a result, simple little ball tests will be slower, and low resolution scenes will be slower overall. Ramp up the detail though, and the v9 series wins in both speed and quality. If that is not your experience, then you need to review the above.

One more thing to consider: the results of the v9 series, whether items such as IK or rendering results, and so on, are all much more accurate than previous. Too many people were correctly complaining about getting good results from the older versions, so we corrected that. Think volume stack, for example, removing the need for "air polys." In some cases, this might be slower than going the older route, but it pays far more dividends in setup time, etc.

Of course, bugs will always be there, but as the whole v9.x series illustrated, we were pretty good at killing some very heinous bugs during that cycle. And, as always, content attached to a bug report stood a much better chance of getting a bug killed than reports without content.

jayroth
05-21-2009, 04:01 PM
rsfd,

many thanks for your reply. Well, I will assume for now that a G5 and OS X 10.4.11 are the minimum system requirements, until one of the kind folks from Newtek says otherwise.

Thanks again.

Actually, at this point, the minimum system is really an intel-based machine running OSX 10.5 or better.

PaulP
05-21-2009, 08:19 PM
Many thanks Lightwolf, Chuck and Jay.

Jay, my LW 9.6 UB seems to be fine on my G4 with 10.4.11, so i assume the minimum system requirements you refer to are for the 64 Bit LW 9.6 ?

Thanks

Kuzey
05-22-2009, 05:41 AM
In many cases, those are not bugs, as we have reviewed many times. In particular, anything to do with GI will produce very different results, both in terms of render times and image quality, using the same numbers across different versions.

Why? Several reasons, actually. The first one being that we have made the system significantly more efficient. As a result, you can now get away with much lower values for most of the attributes in the GI panel, and the image quality will be better than the higher numbers in previous versions. Lower numbers render faster. If you have an older scene, and try to render it in v9.6 unchanged, you will likely not be too impressed. However, if you make the adjustments, v9.6 will knock your socks off.

This is an optimization, not a bug. You get more for less here. And no, we cannot change those values on scene read, for a variety of reasons. The biggest reason is intent -- we cannot divine what you wanted to do with the older scenes, so its much better for you to change those values yourselves than if we try to do it for you. Another reason is the type of optimization involved. In many cases, the improvements we put in were actually completely different algorithms that use different values; oftentimes, there is no direct way to map them over. Again, human intervention is the best case scenario here.

Of course, there are many such examples where the above scenarios are true for areas other than GI; I would recommend referring to the release notes of the various builds to get a handle on those.

Lastly, there are cases where v9.6 might be somewhat slower than, say, v8.x. This typically is a load balancing issue: as we advanced the algorithms throughout the v9.x series, we were able to significantly enlarge the capacity of the system. We tweaked it to be much more favorable to heavier datasets with lots of demands placed upon them (physically accurate materials, GI that works, etc.). As a result, simple little ball tests will be slower, and low resolution scenes will be slower overall. Ramp up the detail though, and the v9 series wins in both speed and quality. If that is not your experience, then you need to review the above.

One more thing to consider: the results of the v9 series, whether items such as IK or rendering results, and so on, are all much more accurate than previous. Too many people were correctly complaining about getting good results from the older versions, so we corrected that. Think volume stack, for example, removing the need for "air polys." In some cases, this might be slower than going the older route, but it pays far more dividends in setup time, etc.

Of course, bugs will always be there, but as the whole v9.x series illustrated, we were pretty good at killing some very heinous bugs during that cycle. And, as always, content attached to a bug report stood a much better chance of getting a bug killed than reports without content.

That is all good...optimizations are always good. :D

I'm not talking about render times etc. I'm talking about changing surface names that take awhile to update because LW has all of a sudden become sluggish when you have an old scene open. Or there is a lag of a few seconds when clicking on a tab or button...that kind of thing and again when an using an old file.

This happens more if there are bones in the scene that was created in an older version of LW, delete the bones and LW acts normal again.

Actually, the sluggish behavior I reported was a direct result of one of the bug fixes (reverting objects causes Modeler to crash) and the response I got from the team was this:


Added some sanity checks to avoid crashing; but, there may be a earlier issue causing the symptoms here. Please test with new build.

--
Area51 Tech Support
[email protected]

Anyway, I sent the bug numbers to Chuck.

And there is this thread as well...that shows related problems of LW acting up with old files:

http://www.newtek.com/forums/showthread.php?t=98463

Kuzey

rsfd
05-23-2009, 06:59 AM
@Jay or Chuck

min. syst. req. for "LW-9.6-cocoa-UB-64 with fixes" = Mac Intel + 10.5

that's ok for my MacPro, but for my G5 with 10.4.11 it is not (ok, I knew it wasn't build for eternity ;-))

So, will some bugfixes from the actual cocoa development (as it is possible) find their way into a new/last build of "LW-9.6-carbon-UB-32", or is build 1539 the last release for older machines?

many thanks in advance

toby
05-23-2009, 01:31 PM
I'm also curious, is the cocoa version *only* 64 bit and ppc incompatible

LW_Will
05-25-2009, 03:23 PM
you won't be able to run 64bit Snow Leopard on a PPC chip, so yes. Yes it is.

toby
05-25-2009, 03:37 PM
you won't be able to run 64bit Snow Leopard on a PPC chip, so yes. Yes it is.
Well he said 10.5, not snow leopard - and I'm wondering if there's a 32 bit version, basically same question as rsfd posted.

rsfd
05-26-2009, 04:35 AM
Basically yes.
And I still would like to read an answer if there are any plans for a bugfixed 9.6 carbon or even a 32-bit cocoa version, as these would be the last possible releases for older Macs.

Kuzey
05-26-2009, 05:02 AM
I thought the idea was that there will be one UB app with a switch to turn on 64bit on and off. So...I presume if your system can't handle the 64bit then you wouldn't see the the 64bit switch and it'll run as a 32bit UB version...I guess both in Cocoa.

However, I'm not sure if that idea is still on the cards since the departure of Chilton.

Kuzey

toby
05-26-2009, 11:42 AM
I thought the idea was that there will be one UB app with a switch to turn on 64bit on and off. So...I presume if your system can't handle the 64bit then you wouldn't see the the 64bit switch and it'll run as a 32bit UB version...I guess both in Cocoa.

However, I'm not sure if that idea is still on the cards since the departure of Chilton.

Kuzey
Wow never heard of that, has it been done? Anyway the pc version doesn't so I don't think the mac ver will - esp. as you say, without Chilton.

It sounds like there's no ppc cocoa version planned, I'd just like to know for sure. But a bug-fix 9.6 for ppc is just a simple recompile? Or each compile needs bug fixes...

Scazzino
05-26-2009, 11:59 AM
Wow never heard of that, has it been done? Anyway the pc version doesn't so I don't think the mac ver will - esp. as you say, without Chilton.

On Mac OS X there would normally be one bundled application that had four binaries inside. PPC 32/64 and Intel 32/64. It's called a fat binary and Mac OS X launches the appropriate version based on your hardware and version of the OS. 64 bit would need a G5 or 64-bit Intel and 10.5 or higher.

Developers aren't forced to support all four versions of course, but if they choose too they can bundle them all together into one fat binary which is a compile option in XCode.

rsfd
05-26-2009, 01:42 PM
Exactly, and as it was said the 64-bit cocoa version will need an Intel Mac with Leopard, I don't expect a PPC cocoa build.
But it would be nice to have some info, if some bugfixes (as it is possible with small efforts) will make their way into a last PPC carbon build.
Those like me, with an MacPro and a G5 will have to change their workflows and preparing for that would be easier with some info about that.

toby
05-26-2009, 02:26 PM
Exactly, and as it was said the 64-bit cocoa version will need an Intel Mac with Leopard
Yea, funny that a G5 with Leopard, both 64 bit, won't run a 64 bit UB app.

Chuck
05-26-2009, 02:44 PM
Apologies for some confusion around this issue. The Cocoa UB 64-bit build will be able to run native PPC code on a G5 system with OSX 10.5. It is the case that Apple is dropping PPC support with Snow Leopard, but Leopard supports both PPC and Intel and will be the mimimum OS for 64-bit Cocoa LightWave 3D and LightWave CORE. 32-bit Cocoa will run on earlier OSX versions on PPC and Intel systems. Cocoa has been an available API for a long time now, so there is really not a need for maintaining a Carbon version beyond the release version of v9.6.

Lightwolf
05-26-2009, 03:51 PM
Apologies for some confusion around this issue. The Cocoa UB 64-bit build will be able to run native PPC code on a G5 system with OSX 10.5.
...
32-bit Cocoa will run on earlier OSX versions on PPC and Intel systems.
Will there be a separate 64-bit and 32-bit UB binary, or will it be a single 64-/32-bit PPC/Intel binary?
I'm just wondering because afaik 10.5 is the minimum requirement for the later (the big fat all in one option) - unless 10.4 can ignore the 64-bit branch of the UB.

Cheers,
Mike

Scazzino
05-26-2009, 05:07 PM
Tiger was the first to support fat binaries I believe. (though not for the GUI libraries)

Here's a quote from Apple's Developing 64-bit Applications (http://developer.apple.com/macosx/64bit.html) page.


Fat Binaries
The updated Mach-O format in Tiger supports the concept of Fat Binaries. These allow both 32-bit and 64-bit executables to be shipped as part of the same file. This means that developers and network system administrators can distribute a single version of an application to all users regardless of whether their system contains a G3, G4, or G5 processor. When the application is executed, the system automatically selects the appropriate code for the system without user intervention. Using Fat Binaries greatly simplifies distribution, installation, and administration of applications.

There's much more info about it in Apple's 64-Bit Transition Guide (http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/64bitPorting.pdf).

:thumbsup:

toby
05-26-2009, 05:25 PM
Thanks Chuck! It's clear now, and sounds great. I haven't been able to upgrade to intel yet so it's great that it'll work on ppc.

Sorry for the impatience, forgot you guys were fishing yesterday.

Lightwolf
05-26-2009, 05:28 PM
Tiger was the first to support fat binaries I believe. (though not for the GUI libraries)

Precisely. And the question is if 10.4 will stumble over a 64-bit branch in a fat UB if that is designed for 10.5 only (as it must be in the case of LW due to the GUI).

*shrugs* I suppose we'll see.

Edit: Hm, Page 35 of the second document:

To prevent new 64-bit executables from running as 64-bit on version 10.4, Apple changed the CPU subtype
for 64-bit executables that depend on high-level frameworks.
It also mentions that otherwise 64-bit apps with a GUI running under 10.4 would crash.

Cheers,
Mike

Scazzino
05-26-2009, 05:36 PM
I'd be surprised if they didn't have a way to set the minimum OS version needed for the 64-bit GUI builds so that the 32-bit runs when necessary. After all it would be a common issue since Tiger only had partial 64-bit support where Leopard has full support...

Chuck
05-26-2009, 06:32 PM
BTW - I will post a new update on Mac development status tomorrow. Sorry we couldn't get that in today, very busy with catching up after the long weekend.

rsfd
05-27-2009, 02:57 AM
Thanks Chuck! It's clear now, and sounds great.

Many thanks Chuck!
Great news for me, too.

Kuzey
05-27-2009, 05:45 AM
Wow never heard of that, has it been done? Anyway the pc version doesn't so I don't think the mac ver will - esp. as you say, without Chilton.


Haha...I remember all sorts of things but I can't tell you when they were talked about, those little details get lost in my memory :D

I believe that kind of thing is unique to Mac OS X...not sure about Win7 though :hey:

Kuzey

allabulle
05-27-2009, 06:06 AM
I thought the idea was that there will be one UB app with a switch to turn on 64bit on and off. So...I presume if your system can't handle the 64bit then you wouldn't see the the 64bit switch and it'll run as a 32bit UB version...I guess both in Cocoa.

However, I'm not sure if that idea is still on the cards since the departure of Chilton.

Kuzey

Actually the Win installer does exactly that: if your system is 64bit you can choose whether you want to install 32bit or 64bit LightWave.

Kuzey
05-27-2009, 06:33 AM
Actually the Win installer does exactly that: if your system is 64bit you can choose whether you want to install 32bit or 64bit LightWave.

It's not really the same though, as you can change which version (32bit or 64bit) you run from within the app (at any time) instead having a choice of which version to install...I believe :D

Kuzey

allabulle
05-27-2009, 06:41 AM
It's not really the same though, as you can change which version (32bit or 64bit) you run from within the app (at any time) instead having a choice of which version to install...I believe :D

Kuzey

Ups!, I didn't know that. How fancy! Thanks for the tip.

Although I'm not using a mac, I'm interested in the subject: a partner of mine is using a mac but he's doing mostly 2D for now, so it really helps me knowing what's all about the mac version in case one of this days he can help me out in the 3D side of things. :--)

Kuzey
05-27-2009, 06:55 AM
It all depends which way Newtek wants to go...they can still make them available as a combined app or have them separate like on the PC. :D

Some people may want the combined app (with the large file size) for ease of use, while others might just want the version specific to their system setup...it can get messy :hey:

Kuzey

Lightwolf
05-27-2009, 07:29 AM
Some people may want the combined app (with the large file size) for ease of use, while others might just want the version specific to their system setup...it can get messy :hey:

On the other hand it allows you to run both at the same time (for example to use plugins that haven't been ported yet).

Cheers,
Mike

allabulle
05-27-2009, 07:39 AM
On the other hand it allows you to run both at the same time (for example to use plugins that haven't been ported yet).

Cheers,
Mike

That's what interested me the most. In Win X64 sometimes it's a pity when you need a plug-in that's only 32bit. You can save your scene or object, start a previously installed 32bit LightWave, do your thing and then save... well, you get the point. It's doable, but sometimes it's just distracting or quite difficult to actually do it properly (even if it's doable, it easily could end in a quite cumbersome process). Switching the app "live" could be a must in some of those occasions.

Lightwolf
05-27-2009, 07:43 AM
Switching the app "live" could be a must in some of those occasions.
A fat UB doesn't allow you to switch live. The only difference is that all versions are stored in a single file (as far as the user is concerned) and the OS picks the right one to start.
So to switch on the Mac:
Close LW
Open the info dialogue for the app
Check/Uncheck a "run as 32-bit" checkbox.
Start LW again.
... or just create a copy of the LW app and set the switch there, allowing you to launch it directly without having to manually toggle all the time (which would be like running two versions on the PC).

Cheers,
Mike

allabulle
05-27-2009, 07:51 AM
A fat UB doesn't allow you to switch live. The only difference is that all versions are stored in a single file (as far as the user is concerned) and the OS picks the right one to start.
So to switch on the Mac:
Close LW
Open the info dialogue for the app
Check/Uncheck a "run as 32-bit" checkbox.
Start LW again.
... or just create a copy of the LW app and set the switch there, allowing you to launch it directly without having to manually toggle all the time (which would be like running two versions on the PC).

Cheers,
Mike

Oh, so I misunderstood it. I thought that you could, like you switch from modeler to layout, somehow tell the app to re-open itself in the other architecture (from 32bit to 64bit and vice versa). So once it's already installed it's not that different from win. Thank you so much for your time, explaining and correcting me. :--)

Scazzino
05-27-2009, 09:14 AM
On the other hand it allows you to run both at the same time (for example to use plugins that haven't been ported yet).

Cheers,
Mike

Which you'll be able to do just as easily with the combined UB. You'd just make a copy and set the copy to run in 32-bit mode.

:D

Lightwolf
05-27-2009, 09:32 AM
Which you'll be able to do just as easily with the combined UB. You'd just make a copy and set the copy to run in 32-bit mode.

Oh yes, of course. And if you strip both of unwanted binaries then it won't even waste any space on the HD... unless you actually want to run multiple instances of the app... but that's a general limitation of OSX.

Cheers,
Mike

Scazzino
05-27-2009, 11:19 AM
Sure, but as a long time Mac user I'm more concerned with ease of use than a little extra space on the HD... So a combined fat UB is preferable from my MacUser point of view...

Especially since that favors the typical Mac user that will generally only have one copy installed and wants Mac OS X to simply run what it needs, like all other Mac UB's. It's mostly the power users that would want more than one version at the same time and they can easily manage either approach... :hey:

Lightwolf
05-27-2009, 11:33 AM
Sure, but as a long time Mac user I'm more concerned with ease of use than a little extra space on the HD...
I know a few Mac users that are very keen on trimming all UBs to get rid of the fat - and that includes stripping plugins. *shrugs* That might make more sense on a laptop I suppose.

It's mostly the power users that would want more than one version at the same time and they can easily manage either approach... :hey:
Oh, absolutely. There's bigger fish to fry (like how to distinguish between multiple LW versions placed in the dock... *grrrr*).

It'll be interesting to see how it copes with plugins, especially ones that aren't 32-bit yet (and might never be for a reason). I surely hope that there is an easy way to keep the 32-bit version compatible to 10.4 as well.

Cheers,
Mike

jwiede
05-27-2009, 11:53 AM
Plus, a Mac Fat UB only duplicates the parts that are actually different between the 32-bit and 64-bit applications. Installing both 32-bit and 64-bit installs under Windows duplicates the entire installation.

Compared to having two complete installs, the Mac Fat UB approach is a more efficient use of HD space.

Lightwolf
05-27-2009, 12:14 PM
Plus, a Mac Fat UB only duplicates the parts that are actually different between the 32-bit and 64-bit applications. Installing both 32-bit and 64-bit installs under Windows duplicates the entire installation.

Compared to having two complete installs, the Mac Fat UB approach is a more efficient use of HD space.
Oh, absolutely... unless you need to dupe the app to run multiple instances (imho a massive blunder by Apple when they designed OS X, I suppose in an attempt to mimic the older Apple OS).

A -1 from me either way... both approaches suck :)

Cheers,
Mike

Scazzino
05-27-2009, 01:10 PM
I know a few Mac users that are very keen on trimming all UBs to get rid of the fat - and that includes stripping plugins. *shrugs* That might make more sense on a laptop I suppose.

Wow, they must have very small HD's indeed... The entire LW UB for Layout and Modeler is only about 10MB... not much to save there when the smallest currently shipping MacBook HD is 160 GB...

I'd expect that the vast majority of Mac users (not talking about PC users that occasionally use Macs) would rather have a simple fat UB that just works, rather than messing around with multiple different versions to install and configure.

Lightwolf
05-27-2009, 01:38 PM
I'd expect that the vast majority of Mac users (not talking about PC users that occasionally use Macs) would rather have a simple fat UB that just works, rather than messing around with multiple different versions to install and configure.
So would I :D Having said that, simple is relative... Simplistic is unfortunately quite close to it at times...

It'll be interesting to see how well the 64bit approach will work on OS X, as there's plenty of unclear areas ahead. And, at last as a developer, OS X is unfortunately not simple and doesn't just work - if you have a certain number of platforms and OS versions to support as customers demand it...

Cheers,
Mike

Kuzey
05-27-2009, 01:49 PM
A fat UB doesn't allow you to switch live. The only difference is that all versions are stored in a single file (as far as the user is concerned) and the OS picks the right one to start.
So to switch on the Mac:
Close LW
Open the info dialogue for the app
Check/Uncheck a "run as 32-bit" checkbox.
Start LW again.
... or just create a copy of the LW app and set the switch there, allowing you to launch it directly without having to manually toggle all the time (which would be like running two versions on the PC).

Cheers,
Mike

I was under impression that you could switch while the app is running...maybe with a preference somewhere like the general options etc. as optional to the info dialogue...I must have missed something along the line :D

I guess if they go with the combined app then there should be a slight change to the plugins folder, maybe have two folders...plugins32 & plugins64 side by side. So you can keep them all organized and such.

Kuzey

Scazzino
05-27-2009, 03:00 PM
So would I :D Having said that, simple is relative... Simplistic is unfortunately quite close to it at times...

It'll be interesting to see how well the 64bit approach will work on OS X, as there's plenty of unclear areas ahead. And, at last as a developer, OS X is unfortunately not simple and doesn't just work - if you have a certain number of platforms and OS versions to support as customers demand it...

Cheers,
Mike

Primarily from a user's perspective, Apple always makes such transitions painless, and almost invisible. Their fat binaries originally bridged the gap between 68000 and PPC, then Classic and OS X, now PPC & Intel and 32/64 bit.

If supporting other platforms is a problem, since I only use Mac, you could always drop Windows... JK ;) :D

Lightwolf
05-27-2009, 03:17 PM
Primarily from a user's perspective, Apple always makes such transitions painless, and almost invisible. Their fat binaries originally bridged the gap between 68000 and PPC, then Classic and OS X, now PPC & Intel and 32/64 bit.
Yeah, I remember the switch back then. For a short time I had the fastest Mac around... an Amiga with a 68060 running an emulator (which was faster than a 601 PPC in most cases)... fun times.

If supporting other platforms is a problem, since I only use Mac, you could always drop Windows... JK ;) :D
Hehe... Windows is a piece of cake, and roughly a quarter of the effort - the 64-bit compiles don't take any effort (now, if Apple sales were more than 75% then we might be talking, so far they're at around 10% though...).

Cheers,
Mike