На прошедшей в этом году конференции 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 был связан с вещами вроде


#ifdef WIN32
        return _isnan(val) != 0;
#elif __APPLE_CC__
        return std::isnan(val) != 0;
#endif

или, как вариант


#if UNITY_WIN
        // Some Windows-specific codepath
#else
        // Some Mac-specific codepath
#endif

Вывод: если вы хотите писать переносимый код, всегда делайте что-то разумное (читай: с расчетом на будущее) в случае #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.