Перенос редактора Unity на Linux: вещи, которые стоило бы сделать заранее
На прошедшей в этом году конференции Unite Europe мы опубликовали наш план развития. И хотя там много классных вещей, лично мне больше всего нравится редактор для Linux. История портирования редактора под Linux похожа на историю добавления поддержки Linux для среды выполнения в Unity 4.0. По большому счету это делается для души, часть сотрудников Unity периодически работала над этим в течение некоторого времени, во многом этот проект является одним из итогов внутренних хакерских недель (hackweek) среди разработчиков Unity — и я бы сказал, что дело продвигается весьма неплохо. Достаточно скоро мы планируем выпустить экспериментальную сборку, которую вы все сможете попробовать.
Портирование редактора на Linux потребовало немало усилий — намного больше, чем перенос среды выполнения. Частично это обусловлено тем, что именно в редакторе воплощено большинство наших собственных технологий (включая сложную интеграцию со сторонними разработками), частично из-за базы данных ресурсов, частично из-за проблем с чувствительностью к регистру. Наш редактор состоит из:
* Большого количества кода на C++, большая часть которого (но не все) общая с нашей средой выполнения, который, само собой, компилируется под нужную платформу
* Большого количества кода на C#, работающего поверх Mono
* Различных библиотек и связующих программ (middleware) от сторонних производителей, которые должны быть перекомпилированы под Linux
Разобравшись с этим можно вернутся к тем вещам, которые стоило бы сделать заранее:
1. Позаботиться о чувствительности к регистру
Unity неправильно работает на чувствительных к регистру файловых системах (с чем уже могли столкнуться те пользователи, которые пытались установить и запустить редактор на чувствительной к регистру файловой системе HFS+). В основном это связано с тем, как именно база данных ресурсов Unity хранит пути к ним и связывает их со значениями GUID. Само собой мы пытались учесть все в начале разработки, но если вы не проверяете на практике, как система работает на чувствительных к регистру файловых системах, то она никогда не упадет после того как один из программистов не применит где-нибудь с самыми лучшими намерениями toLower() и не испортит всю идею.
Определенно мне бы хотелось, чтобы мы позаботились об этом заранее, так как исправлять такие вещи задним числом сложно и муторно.
2. Не использовать #if WINDOWS #else OSX
Совершенно неожиданный объем работы на раннем этапе переноса редактора под Windows был связан с вещами вроде
или, как вариант
Вывод: если вы хотите писать переносимый код, всегда делайте что-то разумное (читай: с расчетом на будущее) в случае #else.
3. Просто не делайте предположений
Две предыдущие проблемы были очень крупными, следующие помельче
* Предположения о компиляторах. Для примера возьмем нашу систему отслеживания ошибок (bug reporter), которая писалась во многом отдельно от основного редактора и использует некоторые возможности C++11. Во многих местах этот стандарт… э-э… несколько неопределенный и разные компиляторы реализуют его по разному. Это делает перенос кода C++11 на третий компилятор весьма болезненным. Было очень много ошибок компиляции в духе этот-шаблон-С++-с-кучей-угловых-скобок не совпадает с этим-шаблоном-С++-с-кучей-уголовых-скобок-в-котором-есть-константа-где-то-в-середине.
* Предположения по поводу родных приложений, включая тем пункты, которые автоматически включаются в меню приложений. Для примера, на Windows вещи вроде «копировать», «вставить» и тому подобное включаются бесплатно, а вот в GTK нет и нам пришлось добавлять их вручную. Не буду врать, в OS X они доже не добавляются автоматически, но реализация для OS X попала в описанную выше ловушку #if WINDOWS #else OSX.
* Предположения о работе файловых диалогов. На других платформах есть системы обратных вызовов (callback), позволяющие родительскому приложению объяснить диалогу, что некоторые вещи выбирать нельзя. Стандартные виджеты GTK так не работают.
* Предположения в целом
Вывод: предположения — это источник всех бед. 🙂
Несмотря на все вышесказанное, работа определенно была очень интересной, я бы ожидал аналогичных проблем при переносе на новую платформу любого проекта, сравнимого с Unity по размерам и сложности.
Интереса ради опишу решение, от которого нам пришлось отказаться в процессе переноса. Первый вариант использовал чистый X11 для обработки окон и событий, потому что мы не хотели привязываться ни к GTK ни к QT. Из-за этого ранняя система меню была написана на Unity GUI. Мне все еще кажется, что было бы очень круто вернуться к этому когда-нибудь. В Unity 5.1 в качестве встроенного браузера используется CEF, который зависит от GTK, так что мы переключились на GTK для обработки окон и событий для всех систем меню. Но это был единственный случай, когда нам пришлось переделывать что-то заново.
Так как продвигается работа над редактором? Вот что я знаю:
* будет поддерживаться только 64-битный Linux
* Аналогично нашей среде выполнения, чтобы не сойти с ума, мы будем официально поддерживать только Ubuntu. Но скорее всего редактор будет работать и в других дистрибутивах.
* Скорее всего мы будем поддерживать версии Ubuntu начиная с 12.04 (именно на ней мы делаем наши текущие сборки)
* Зависящие от сторонних библиотек возможности (вроде глобального освещения) будут работать
* Установщик скорее всего (мы его пока еще не сделали) будет пакетом .deb
* Некоторые из импортеров моделей, зависящие от стороннего софта (вроде 3ds Max и SketchUp) не будут работать. В качестве обходного пути можно использовать экспорт в FBX
На данный момент все. Небольшой тизер:
Наше сетевое демо двухмерного шутера, экспортируемое на Linux из редактора на Linux.
Linux-редактор в Unity Labs. Шрифты такие маленькие, потому что он запущен на MacBook Pro с Retina.
Источник
PC, Mac & Linux Standalone build settings
The PC, Mac & Linux Standalone build settings contain options you can use to set up and begin the build process for your application on these platforms. It contains settings to create development builds A development build includes debug symbols and enables the Profiler. More info
See in Glossary as well as publishing your final build. To access the Build Settings window, go to File > Build Settings. Once you specify the build settings, select Build The process of compiling your project into a format that is ready to run on a specific platform or platforms. More info
See in Glossary to create your build, or select Build And Run to create and run your build on the platform you specify.
Standalone Build Settings
The following table outlines the settings available for your build. These vary depending on the target operating system you choose.
| Setting | Description | |
|---|---|---|
| Target Platform | ||
| Windows | Build for Windows | |
| macOS X (Not available on Linux) | Build for macOS | |
| Linux (not available on Mac) | Build for Linux | |
| Architecture | Not available on macOS | |
| x86 | 32-bit CPU | |
| x86_64 | 64-bit CPU | |
| x86 + x86_64 (Universal) | All CPU devices for Linux | |
| Server Build | Enable this setting to build the Player for server use and with no visual elements (headless) without the need for any command line options. When you enable this setting, Unity builds managed scripts A piece of code that allows you to create your own Components, trigger game events, modify Component properties over time and respond to user input in any way you like. More info See in Glossary with the UNITY_SERVER define, which means you can write server-specific code for your application. You can also build to the Windows version as a console application to access stdin and stdout . Unity logs go to stdout by default. | |
| Copy PDB files(Windows only) | Enable this setting to include Microsoft program database (.pdb) files in the built Standalone Player. .pdb files contain application debugging information that is you can use to debug your application. Copying .pdb files might increase the size of your Player, so you should disable this setting for builds that are intended for publishing. This setting is disabled by default. | |
| Create Visual Studio Solution(Windows only) | Enable this setting to generate Visual Studio Solution files for your Project, so you can build your final executable in Visual Studio. | |
| Create Xcode Project (Mac Only) | Enable this setting to generate an Xcode project so you can build your final application bundle in Xcode. Xcode has built-in support for code signing and uploading the application to the Mac App Store. | |
| Development Build | Enable this setting to include scripting debug symbols and include the Profiler A window that helps you to optimize your game. It shows how much time is spent in the various areas of your game. For example, it can report the percentage of time spent rendering, animating or in your game logic. More info See in Glossary in your build. When you enable this setting, the DEVELOPMENT_BUILD scripting define is set. You should use this option when you want to test your application. | |
| Autoconnect profiler | Requires Development Build option to be enabled. When you enable this setting, the Unity Profiler automatically connects to your build. | |
| Deep Profiling Support | Requires Development Build option to be enabled. Deep Profiling Support enables the Unity Profiler to record more detailed data by instrumenting every function call. Enabling Deep Profiling might slow down script execution. | |
| Script debugging | Requires Development Build option to be enabled. When you enable this setting, Unity adds debugging symbols to your script code. | |
| Scripts Only Build | Requires Development Build option to be enabled. When you enable this setting, you can rebuild only the scripts for your application while leaving data files intact from a build you have previously executed. Script only builds significantly improves iteration times if you are only changing the code in your application. You need to build the whole Project once before you can use this setting. | |
For information on minimum requirements for build targets see documentation on Player System Requirements.
Источник
Платформенно зависимая компиляция
Unity включает в себя функцию под названием “Платформенно зависимая компиляция”. Она состоит из некоторых директив препроцессора, которые позволяют вам разделить свои скрипты для компиляции и выполнения части кода исключительно для одной из поддерживаемых платформ.
Кроме того, вы можете запустить этот код в редакторе, таким образом, вы можете скомпилировать код специально для вашего мобильного/консоли и проверить его в редакторе!
Определения платформ
Определения платформ для ваших скриптов, которые Unity поддерживает:
| Свойство: | Функция: |
|---|---|
| UNITY_EDITOR | Определение для вызова скриптов редактора Unity из вашего игрового кода. |
| UNITY_EDITOR_WIN | Определение платформы для редактора кода на Windows. |
| UNITY_EDITOR_OSX | Определение платформы для редактора кода на Windows. |
| UNITY_STANDALONE_OSX | Определение платформы для компиляции/выполнения кода специально для Mac OS (это включает в себя Universal, PPC и Intel архитектуры). |
| UNITY_STANDALONE_WIN | Используйте, когда вы хотите скомпилировать/выполнить код для приложения на Windows. |
| UNITY_STANDALONE_LINUX | Используйте, когда вы хотите скомпилировать/выполнить код для приложения на Linux. |
| UNITY_STANDALONE | Используйте, когда вы хотите скомпилировать/выполнить код для любой платформы Mac, Windows или Linux. |
| UNITY_WII | Определение платформы для компиляции/выполнения кода для консоли Wii. |
| UNITY_IOS | Определение платформы для компиляции/выполнения кода для iPhone. |
| UNITY_IPHONE | Эквивалент UNITY_WP8 \ |
| UNITY_ANDROID | Определение платформы для Android. |
| UNITY_PS3 | Определение платформы для запуска кода на PlayStation 3. |
| UNITY_PS4 | Определение платформы для запуска кода на PlayStation 3. |
| UNITY_SAMSUNGTV | Определение платформы для выполнения кода на Xbox 360. |
| UNITY_XBOX360 | Определение платформы для выполнения кода на Xbox 360. |
| UNITY_XBOXONE | Определение платформы для выполнения кода на Xbox 360. |
| UNITY_TIZEN | Определение платформы для Android. |
| UNITY_TVOS | Определение платформы для Android. |
| UNITY_WP_8 | Определение платформы для Windows Phone 8. |
| UNITY_WP_8_1 | Определение платформы для Windows Phone 8. |
| UNITY_WSA | Определение платформы для Windows Store Apps (дополнительно определяется NETFX_CORE при компиляции C#-файлов в отношении ядра .NET). |
| UNITY_WSA_8_0 | Определение платформы для Windows Phone 8. |
| UNITY_WSA_8_1 | Определение платформы для Windows Phone 8. |
| UNITY_WSA_10_0 | Определение платформы для Windows Store Apps (дополнительно определяется NETFX_CORE при компиляции C#-файлов в отношении ядра .NET). |
| UNITY_WINRT | Эквивалент UNITY_WP8 | UNITY_WSA. |
| UNITY_WINRT_8_0 | Эквивалент UNITY_WP8 | UNITY_WSA_8_0. |
| UNITY_WINRT_8_1 | Эквивалент UNITY_WP8 | UNITY_WSA_8_1. This is also defined when compiling against Universal SDK 8.1. |
| UNITY_WINRT_10_0 | Equivalent to UNITY_WSA_10_0 |
| UNITY_WEBGL | Определение платформы для Windows Phone 8. |
| UNITY_ADS | Определение для вызова скриптов редактора Unity из вашего игрового кода. |
| UNITY_ANALYTICS | Определение для вызова скриптов редактора Unity из вашего игрового кода. |
| UNITY_ASSERTIONS | #define directive for assertions control process. |
Также вы можете скомпилировать код избирательно, в зависимости от версии движка. В настоящее время поддерживаются: Given a version number X.Y.Z (for example, 2.6.0), Unity exposes three global #define directives in the following formats: UNITY_X, UNITY_X_Y and UNITY_X_Y_Z.
Here is an example of #define directives exposed in Unity 5.0.1:
| UNITY_5 | Определение платформы для мажор-версии Unity 2.6. |
| UNITY_5_0 | Определение платформы для мажор-версии Unity 3.0. |
| UNITY_5_0_1 | Определение платформы для мажор-версии Unity 3.0. |
You can compile code selectively based on the earliest version of Unity required to compile or execute a given portion of code. Given the same version format as above (X.Y.Z), Unity exposes one global #define directive that can be used for this purpose, in the format UNITY_X_Y_OR_NEWER.
The supported #define directives are:
| UNITY_5_3_OR_NEWER | Определение платформы для мажор-версии Unity 4.0. |
You can also compile code selectively depending on the scripting back-end.
| ENABLE_MONO | Scripting back-end #define directive for Mono. |
| ENABLE_IL2CPP | Scripting back-end #define directive for IL2CPP. |
| ENABLE_DOTNET | Scripting back-end #define directive for .NET. |
You can also use the DEVELOPMENT_BUILD #define directive to identify whether your script is running in a player which was built with the “Development Build” option enabled.
Тестирование прекомпилированного кода.
Мы собираемся показать небольшой пример, как использовать прекомпилированный код. В данном примере просто выводится сообщение в зависимости от платформы, которую вы выбрали в качестве целевой для сборки.
Во-первых, выберите платформу, для которой вы хотите проверить ваш код, кликнув на File -> Build Settings . Откроется окно Build Settings для выбора целевой платформы.
Окно Build Settings с выбором WebPlayer’а в качестве целевой платформы.
Выберите платформу, для который вы хотите проверить ваш прекомпилированный код, и нажмите кнопку Switch Editor , тем самым указывая Unity целевую платформу.
Создайте скрипт и скопируйте этот код:-
To test the code, click Play Mode. Confirm that the code works by checking for the relevant message in the Unity console, depending on which platform you selected — for example, if you choose iOS, the message “Iphone” is set to appear in the console.
Учтите, что в C# вы можете использовать атрибут CONDITIONAL , который более прозрачен в использовании и является менее подверженным ошибкам способом вырезания функций, см. http://msdn.microsoft.com/en-us/library/4xssyw96(v=vs.90).aspx.
В дополнение к основной #if директиве компилятора, вы также можете использовать многооборотную проверку в C# и JavaScript:-
Пользовательские определения платформ
Кроме того, можно добавить определённые вами определения к встроенному набору. На панели Other Settings настроек проигрывателя (Player Settings), вы увидите текстовое поле Scripting Define Symbols.
Здесь вы можете указать имена обозначений, которые хотите определить для конкретной платформы, через точку с запятой. Эти обозначения можно затем использовать в качестве условий для директив #if также как встроенные.
Глобальные пользовательские определения
Вы можете определить свои собственные директивы препроцессора, чтобы контролировать, какой код попадет в результат при компиляции. Для этого необходимо добавить текстовый файл с дополнительными директивами в папку “Assets/”. Имя файла зависит от языка, который вы используете, а расширение rsp.:
| C# | /Assets/smcs.rsp |
| C# — Скрипты редактора | /Assets/gmcs.rsp |
| UnityScript | /Assets/us.rsp |
Например, если вы включите одну строку “ -define:UNITY_DEBUG ” в ваш файл smcs.rsp, то определение UNITY_DEBUG будет существовать как глобальное определение для скриптов на C#, за исключением скриптов редактора.
Каждый раз, когда вы вносите изменения в .rsp файлы вам нужно перекомпилировать, чтобы изменения были задействованы. Вы можете сделать это путем обновления или повторного импорта одного из файлов скриптов (.js, .cs или .boo).
NOTE
Если вы хотите изменить только глобальные определения, следует использовать Scripting Define Symbols в Player Settings, потому что это будет охватывать все компиляторы. Если вы выбираете .rsp файлы вместо этого, вы должны будете предоставить один файл для каждого компилятора используемый Unity, и вы не будете знать, когда используется тот или иной компилятор.
The use of .rsp files is described in the ‘Help’ section of the smcs application which is included in the Editor installation folder. You can get more information by running smcs -help .
Note that the .rsp file needs to match the compiler being invoked. For example:
Источник
