Hacker News Reader

Comment by ivanca | Hacker News Reader

Not true, instead of focusing in people that are a bit serious about game development they have done plenty of bad chooses, 64 bit processors on home PCs exist since more than a decade ago, and their engine was created in 2006 for 32 bit platforms, when it was clear 64 bits processors were here to stay. Also the GUI system is one of the worst GUI systems I have ever seen, yeah yeah they say they are going to fix it in Unity 5 but we need to develop games now, not tomorrow. Also calling JavaScript to their "implementation" of what comes down as just a mask for C# was a huge marketing mistake.

View on HN

Disclaimer: I work for Unity. -As for 64 bit support, the biggest problem for that with Unity is all the dependencies to third party technologies we integrate. We've managed to get all those resolved for the Runtime part (Mac/Windows/Linux standalone players) a while ago (we've been adding 64 bit versions of those during the 3.x and 4.x release cycles), which meant getting Mono, PhysX, FMOD, Substance, etc all working on 64 bit. For the editor, however, there are a lot more third party libraries involved (such as a web browser engine for the asset store), not all of which had 64 bit versions to start with. So there were a lot of dependencies to resolve, which is why this took time. Good news is, we have all this working in 5.0, which will be out later this year.

-For the new GUI, we are not going to fix this only in Unity 5, but already in Unity 4.6, which should be out really soon.

-About the "JavaScript" misnomer, I agree that that was a bad decision in retrospect, though it is not trivial to change at this point.

What is the deal with software being hard to release as 64-bit?

I'll fully admit that I don't work in C/C++ on the desktop, at all. This just seems like a button toggle problem (I know it was that way for C#/.NET apps, again, grossly simplify and apples to oranges) though, and it's surprising that you aren't just able to ping someone at these companies and ask for a 64-bit build.

> This just seems like a button toggle problem

Sometimes it is, sometimes it isn't. The problem is knowing when it is or isn't. That needs building with all warnings enabled and vetting through them manually, a run with a static analysis tool searching for possible 64 bit bugs, or at worst, running extensive test suites to try to detect errors at runtime.

Some (older) software might also have some internal structures that are designed on the assumption that pointer size equals 32 bits.

This issue is made worse by the loose conventions in implicit integer type casts in C and C++. Warnings do help here, but there's going to be a huge amount of spurious warnings too.

So, at best, all you need to do is change compiler flags. At worst, you'll need a lot of manual labor in making sure that your applications build cleanly for 64 bit machines.

To the point that Microsoft even introduced 32to64 porting tools in the Windows SDK, because not everyone made proper use of platform agnostic types and helper macros to start with.

> What is the deal with software being hard to release as 64-bit?

(disclaimer: I work at Unity)

It is a button toggle problem, if the code does not do nasty things (like casting between a pointer and a 4-byte-integer -> all works until pointers are not 4 bytes). Or if a code depends on, for example, inline assembly (VisualC++ remove that in 64 bit). Or if the code generates code at runtime, for example JavaScript engines - for 64 bit they need to generate different code.

In Unity's case, the biggest holdup, of all things, was WebKit (used for asset store window & some other things). Turns out, there's no 64 bit webkit for Windows (or there wasn't a while ago). We had to replace Webkit with Gecko, which was quite involved task.

On OS X switching from 32 to 64 bit also means no longer being able to use many Carbon APIs.

I would imagine that cross platform software is more likely to use the Carbon APIs because they are procedural and often a bit more low-level than the “modern” Cocoa equivalents.

From what I've seen, I think Unity draws the UI non-natively, using it's own UI system, but I could be wrong. I'm basing this simply on the fact that it looks exactly the same on OSX/Windows.

I actually like their UI quite a lot (as a programmer), and love the fact that the Editor can be extended while it's working.

Correct - we draw all the UI ourselves. Yet, we did indeed have a lot of dependencies on Carbon APIs for all sorts of different things like handling rendering into windows or fullscreen contexts, getting images from WebCams, input, etc. We had to rewrite quite a bit of that code to move to 64-bit. A problem with that is that often the replacement APIs have only been introduced in more recent OS X versions (which have always been trying to keep long backward compatibility with old systems), which means that in several places we had a choice of maintaining two separate code paths or dropping functionality in 32-bit. Or releasing 64-bit versions later when we could safely drop backwards compatibility with old OS X versions. This was not the biggest reason for us to take long to support 64-bit, but it was one.

Reply on news.ycombinator.com