Some kind of #pragma support for "cross-platform"

How quickly can we have some #pragmas or similar to allow scripts to work seamlessly in both Unity and Unity iPhone? (Or do such #pragmas exist? I’m flying blind at the moment.)

I haven’t tried this but how viable is it for an entire project to be cross-platform in this manner? Ideally of course (and I assume this is the eventual goal) Unity will be re-unified.

Since the main (only?) restriction is dynamic typing, doesn’t #pragma strict already do exactly what you want?

I would guess that using the same script unmodified on iPhone and on a regular PC is a totally utopic target.
We are talking here of a pretty weak ARM cpu in the iphone where you have to cut calcs whereever possible in any way + cut the physics totally if possible.

compared to a desktop where even a crappy mac mini is a dozen times++ more powerfull than the iphone at its best calc wise.

There are so many factors you either opt for the iphone or which will result in crappy performance that I would guess that nothing but the basic scripts can be shared between projects at all.

He’s referring to how you would use #pragmas in, for instance, C or C++: as a preprocessor instruction to the compiler that if a certain value is defined (for instance, a tag identifying the target build platform), you can put it preprocessor “if” statements that will include certain code for one platform and a different set of code for a different platform. Like in C++ you would do:

#ifdef WIN32

#else
<some xbox, mac, etc code>
#endif

That way the same source file can be used to compile to both platforms.

Actually, in the game I’m working on right now, I would love to port it to PC and Mac, and the only thing I’d probably have to change would be the resolution of my textures, and the input portions of my scripts (which would be taken care of using podperson’s request).

#define UNITY_IPHONE is passed to all scripts when in the Unity iPhone Editor. Unity will obey #ifdef UNITY_IPHONE before compiling the script. I think it should work in Javascript too, but I haven’t tested it.

PERFECT!

In a related vein, preprocessors are used to cull debugging statements from a release build. If we strip a build of debug symbols, does that also cull out Debug.* calls? Or do we need to implement our own #ifdef DEBUG sort of solution?

Now - is there also a way to poll for standard vs. pro version?

I am about to port/rewrite parts of the SFS .net client API to run on the iPhone, and would very very much love to have socket connections on the pro version and WWW on the standard - from the same sourcebase.

Thanks Shawn, hopefully that works.

Nope…strip debug symbols, as the name implies, only strips debug symbols. Logging is a completely different thing.

–Eric

the other way round is naturally possible.
But from Desktop to iPhone in most cases will end with serious performance problems.
especially as physics, collision and ray casting must be used much more carefully. Also forget bone rigged animated objects unless you have specially created models because already 500 polygons on such a character puts considerable strain onto the CPU (no hardware animation like on desktop)

Is there a similar #define that indicates whether we are running in editor mode versus player mode?

And are these #defines documented anywhere?

Hi Brady,

Is this kind of what you’re looking for or are you looking for something in xcode?

if ( Application.platform == RuntimePlatform.OSXEditor ) {
// .... do something here
}

Here’s the RuntimePlatform scripting link:

I’m not sure if there’s one for the iPhone though

Yeah, I think that’s it! Thanks! I just wanted to be able to do things one way while in-editor (like storing game settings/data) and another way on the iPhone.

Anyone managed to get #ifdef UNITY_IPHONE working on javascript? I get compiler errors when I have it there…

Also what do you do with all the other errors Unity gives you when you open a Unity iphone project in Unity pro?

Like invalid texture format, shaders not behaving, etc…

Somehow it double posted, please remove.