Porting the Unity Editor to Linux: Things to Do in Advance

Original author: Na'Tosha Bard
  • Transfer
At Unite Europe this year, we published our development plan. And although there are a lot of cool things, I personally like the editor for Linux the most. The history of porting the editor for Linux is similar to the history of adding Linux support for the runtime in Unity 4.0. By and large, this is done for the soul, some Unity employees have periodically worked on this for some time, in many ways this project is one of the outcomes of internal hackweeks among Unity developers - and I would say that things are progressing quite well. Soon enough, we plan to release an experimental assembly that you can all try.

Porting the editor to Linux took a lot of effort - much more than porting the runtime. This is partly due to the fact that it is in the editor that most of our own technologies are embodied (including complex integration with third-party developments), partly due to the resource database, partly due to problems with case sensitivity. Our editor consists of: * A lot of C ++ code, most of which (but not all) is common with our runtime, which, of course, compiles to the right platform * A lot of C # code, working on top of Mono * Various libraries and binders third-party software (middleware) that must be recompiled under Linux

Having dealt with this, we can return to those things that should be done in advance:

1. To take care of case sensitivity

Unity does not work correctly on case-sensitive file systems (which those users who tried to install and run the editor on case-sensitive could already encounter HFS + file system). This is mainly due to how the Unity resource database stores paths to them and associates them with GUID values. Of course, we tried to take everything into account at the beginning of development, but if you do not test in practice how the system works on case-sensitive file systems, then it will never crash after one of the programmers doesn’t apply toLower somewhere with the best intentions ( ) and will not spoil the whole idea.

I definitely would like us to take care of this in advance, since it is difficult and dreary to fix such things retroactively.

2. Do not use #if WINDOWS #else OSX

A completely unexpected amount of work in the early stages of porting the editor for Windows was related to things like

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

or, as an option

        // Some Windows-specific codepath
        // Some Mac-specific codepath

Conclusion: if you want to write portable code, always do something reasonable (read: with a view to the future) in the case of #else.

3. Just do not make assumptions.

Two previous problems were very large, the following are smaller

* Assumptions about compilers. For example, take our bug reporter system, which was written largely separately from the main editor and uses some of the features of C ++ 11. In many places, this standard ... uh ... is somewhat vague and different compilers implement it differently. This makes porting C ++ 11 code to the third compiler very painful. There were a lot of compilation errors in the spirit of this-pattern-C ++ - with-a bunch of angle-brackets does not match this-pattern-C ++ - with-a bunch of angle-brackets in which is constant-where in the middle.

* Assumptions about native applications, including those items that are automatically included in the application menu. For example, on Windows things like “copy”, “paste” and the like are included for free, but not in GTK and we had to add them manually. I will not lie, in OS X they are not added automatically even, but the implementation for OS X fell into the #if WINDOWS #else OSX trap described above.

* Assumptions about the operation of file dialogs. Other platforms have callback systems that allow the parent application to explain to the dialog that certain things cannot be selected. Standard GTK widgets don't work that way.

* Assumptions in general

Conclusion: assumptions are the source of all ills. :-)

Despite all of the above, the work was definitely very interesting, I would expect similar problems when porting any project comparable to Unity in size and complexity to the new platform.

For the sake of interest I will describe a solution that we had to abandon in the transfer process. The first option used pure X11 to handle windows and events, because we did not want to bind to either GTK or QT. Because of this, the early menu system was written in the Unity GUI. It still seems to me that it would be really cool to come back to this someday. In Unity 5.1, CEF, which depends on GTK, is used as the built-in browser, so we switched to GTK to handle windows and events for all menu systems. But this was the only time when we had to redo something again.

So how is work going on with the editor? Here is what I know:

* only 64-bit Linux will be supported

* Like our runtime, in order not to go crazy, we will officially support only Ubuntu. But most likely the editor will work in other distributions.

* Most likely we will support versions of Ubuntu starting from 12.04 (it is on it that we make our current builds)

* Opportunities dependent on third-party libraries (such as global lighting) will work

* The installer most likely (we have not done it yet) will be a .deb package

* Some of the importers of models that depend on third-party software (such as 3ds Max and SketchUp) will not work. As a workaround, you can use export to FBX

That's all for now. A small teaser:

Our network demo of a two-dimensional shooter exported to Linux from a Linux editor.

Linux editor at Unity Labs. Fonts are so small because it runs on a MacBook Pro with Retina.

Also popular now: