На прошедшей в этом году конференции 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.