Platform Dependent Compilation

Hi,

I know Unity offers the #if UNITY_IPHONE defines, and thats great, however I am developing a game for iPhone, Android and Web, and depending on the platform, I obviously receive input in different ways (and other things as well). However, if the target platform is set to iOS, but I want to test the game in the editor before transfering it to the device (which takes a lot more time), I cant test it with keyboard and mouse, since the game is expecting touch inputs.

If I add something like:

#if !UNITY_EDITOR (UNITY_IPHONE || UNITY_ANDROID)

it works for the editor, but when I try to build the game for the device it complains of things like “Movie texture is not supported for target platform”… considering the code for movie texture is under a #if WEBPLAYER || EDITOR, I thought it would not include such code when compiling to the actual device… but it does.

Is this intended? Changing target platforms all the time is quite time consuming, and I thought this would remove the need to manually comment the unsupported code for each platform… but it doesnt =/ (Ive just recently learned of this feature)

Is there a way to use one code in the editor, and another when actually exporting the project? Or is there a way to test the touch game with mouse/keyboard without much trouble?

Thx for your time,
Best regards,
Allan

Use the Unity Remote app.

–Eric

Hey Eric,

I’ve tried before… I dont know if this happens only with me but Unity Remote is VERY slow and unresponsive, I cant use it to play the game and know how it really works when deployed to the device… I must touch a thousand times to get things working, while on the final build this doesnt happen… and for the games Im working on, that are fast paced, this makes unity remote basically unusable… unfortunately

You can turn the video off to improve speed.

–Eric

I can’t remember off the top of my head, but there’s a file where you can specify custom #defines for a project, though you do need a bit of manual handling. Also, for stuff that won’t cause compile time errors, there’s always Application.platform to check what you’re currently running on.

In situations like the one you’re describing, what I generally do is attach all of my input components in the editor, and have each of them disable or remove themselves at load time if they don’t apply to the current platform. This of course relies on having your input split up into different components in the first place.

I likewise usually find the remote to be more pain than it’s worth.