PDA

View Full Version : Core: Extensibility Question



BlueApple
02-09-2009, 12:17 PM
By default, the plug-ins are multi-platform (mach-o bundle), enabling vendors to ship a single file to support Windows, Linux and Mac, in both 32 and 64 bit versions.

Does this mean that "by default" plugins will run more slowly than if they were written for a specific platform?

As a Mac user I am interested in having more plugins available to me, but wonder if they won't work as efficiently as they could "by default."

Myagi
02-09-2009, 02:51 PM
I haven't dealt with fat binaries and whatever other names they have, but you could view it as stuffing one binary for each platform in a single archive, so there's no performance hit as you're running native code.

And I think one detail to look for more info on is "enabling vendors", to me that sounds like it's completely up to the plugin maker to decide what platforms will be supported. Maybe NT is making it easier by including gcc, with support for all 6 architectures involved, in the SDK. That's pure speculation, and sounds like it would be a big complicated package, so I wouldn't get my hopes up that we'll be in a magic wonderland where all (non-scripted) plugins work everywhere.

RebelHill
02-09-2009, 03:06 PM
No... it means that plugins are multi platform... meaning no more mac version, pc version, etc... just a universal plugin filetype...

BlueApple
02-09-2009, 03:21 PM
Well, it says "by defult," and to me that implies that there will be more than one option for developers.

-Option A-
Create a single tool for Core that can run on all platforms (64bit/32bit/Mac/Win/Linux,) without having to specifically develop for those mulitple platforms.

-Option B-
Create a tool for a specific platform. If the tool is to be available on all platforms, it needs to be developed for each. The exception to this would be the ability to run 32Bit plugins on both 32 and 64Bit machines.

Am I correct in my understanding that Option B is always going to out-perform option A?

Silkrooster
02-09-2009, 03:32 PM
Well, I definately do not know much about how multi-platforms work. But I am assuming that python is the multi-platform engine in that it executes the code at runtime like the basic or even lscript did.
Where as C++ I do not know how that could be multi-platform. I would assume the coder would have to compile the code for each platform and place them all into a single folder that lightwave would pick the correct version depending on what platform lightwave is running on.
The above is only a guess but going with what I wrote, you would be correct If I am wrong well...

BlueApple
02-09-2009, 03:46 PM
Yeah, as Mac user I'm excited to get my hands on more 3rd party tools that hadn't previously been developed for the Mac. However, that excitement is tempered with the prospect of some of these tools being less effecient than they could be, all in the interest of broad accesibility.

lots
02-09-2009, 10:05 PM
Fat binaries are binaries that have executable code for several platforms. As a Mac user, you should be familiar with fat binaries as they were fairly common during Apple's transition from the PPC to Intel CPUs. And similarly for Apple's transition from the 68k to the PPC...

You can see more about fat binaries here: http://en.wikipedia.org/wiki/Fat_binary

I would expect the binary to run as fast as any other binary compiled for your platform. The one draw back that I see is perhaps file size of the plugins will increase. Not that file size is really anyone's concern these days with 2TB drives on the market...

NT probably gave the ability to only develop for one platform in the case that there is some sort of platform specific control that the developer absolutly needs to create his/her tool, and that Core doesn't provide a platform agnostic function for.

For the most part I think it will be great for developers. They wont have to worry much about specifics of their platform, leaving them with more time to put effort into creating or improving their tool.

ncr100
02-10-2009, 06:38 PM
Yes, to repeat, their marketing makes it look like extensions will have ALL architecture (64/32/mac/windows/linux) versions packed into ONE file. The app would read this "mach-o bundle" extension, fast-forward to the chunk that's appropriate for it's host's architecture, and run just that chunk; 100% compatible with the host.