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