Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Unreal Decision

martiancraft.com

Post reply on HN
Print view View original

81–90 of 105 posts

Re: An Unreal Decision

#81

Post by aras_p »

tobz wrote: post #65
jonasechterhoff wrote: post #62

Earlier quoted context omitted.

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 workin…

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.

> 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.

Re: An Unreal Decision

#82

Post by sorbits »

aras_p wrote: post #81
tobz wrote: post #65

Earlier quoted context omitted.

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.

> 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 eng…

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.

Re: An Unreal Decision

#83

Post by georgeecollins »

I have been Producing a very large game project with Unity. We have a large team, at times 50+. Our graphics aren't as state of the art as they could be but the performance of the Unity engine does not seem bad. The cross platform compatibillity is very strong. The third party tools are very strong. It's worked out well.

Unity seems like it was built with ease of of entry as a first consideration. As people do larger and more ambitious projects with it they are hitting some of the tradeoffs and limitations. I am sure UE4 is a good choice as well.

Re: An Unreal Decision

#84

Post by increment_i »

Tepix wrote: post #3

I recently started getting to know Unity3d and it was extremely easy and quick to learn. One annoying discovery was that their variant of JavaScript is not real JavaScript, it's "UnityScript". It took me quite some time to convert a simple script that I had written for node.js to UnityScript. I need the pro version of Unity3d to generate iOS, Android or VR games for the Oculus Rift. For someone who is just doing a bi…

Indie devs -- particularly one man shops -- should also take note that the hardware requirements to run UE4 are magnitudes higher than what is required to run Unity. I was basically ready to jump ship to UE before I realized this.

Re: An Unreal Decision

#85

Post by Coincoin »

midnightclubbed wrote: post #57
Coincoin wrote: post #9

As someone who tried to develop a Unity game on a big team, it was hell. The collaboration is horrible, there are conflicts all the time for no reason. Simply getting the source, running the game and updating would produce conflicts. We also had to buy the cache licenses to make it somewhat workable. But the worst was the support. It was worthless. Anytime we would open a ticket, they would simply google and return u…

I'm not sure what you would classify as being a big team but you can definitely pay for dedicated support (and source code) should your organisation want to. Of course that comes at a cost significantly more than a couple of pro licenses.

Don't worry we had the whole package. They just simply didn't care.

Re: An Unreal Decision

#86

Post by malkia »

sorbits wrote: post #82
aras_p wrote: post #81

Earlier quoted context omitted.

> 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 eng…

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.

Re: An Unreal Decision

#87

Post by Cacti »

jimmaswell wrote: post #8
Tepix wrote: post #3

I recently started getting to know Unity3d and it was extremely easy and quick to learn. One annoying discovery was that their variant of JavaScript is not real JavaScript, it's "UnityScript". It took me quite some time to convert a simple script that I had written for node.js to UnityScript. I need the pro version of Unity3d to generate iOS, Android or VR games for the Oculus Rift. For someone who is just doing a bi…

Why would you choose to develop for a game in JavaScript anyway? The language devs use for Unity tends to be C#. The design of the language fits the framework much more. I've been using C# with Unity and using JavaScript on webpages for years and JavaScript has always been much more cumbersome and error-prone to write nontrivial logic in. So many errors all the time that would've been found at compile-time in C#. May…

It's not JavaScript, it's UnityScript. Basically since everything that's not compiled to native code is run through Mono.

By default Unity provides support for UnityScript, C#, and Boo. However, since it's just IL all the way down, you can easily use IronPython, IronScheme, ClojureCLR, F#, etc., etc. just as easily.

Re: An Unreal Decision

#88

Post by vyrotek »

increment_i wrote: post #84
Tepix wrote: post #3

I recently started getting to know Unity3d and it was extremely easy and quick to learn. One annoying discovery was that their variant of JavaScript is not real JavaScript, it's "UnityScript". It took me quite some time to convert a simple script that I had written for node.js to UnityScript. I need the pro version of Unity3d to generate iOS, Android or VR games for the Oculus Rift. For someone who is just doing a bi…

Indie devs -- particularly one man shops -- should also take note that the hardware requirements to run UE4 are magnitudes higher than what is required to run Unity. I was basically ready to jump ship to UE before I realized this.

I just discovered this for myself this past week. I've been playing with Unity for a while now and just recently decided to give UE4 a try. I couldn't even do a serious evaluation of it on my PC with my current graphics card. I didn't have any problems with Unity at all but with UE4 I could barely open or run the sample projects. Even the blueprint editors were terribly laggy. I purchased a new graphics card and it runs beautifully now. I'm not sure how I feel about this. UE4 is definitely a lot "prettier".

Re: An Unreal Decision

#89

Post by vyrotek »

LeicaLatte wrote: post #56

Recently moved to UE4 too. Used to do Unity. I moved because I was originally a C++ developer. Had code lying around I could use easily.

How was the move from C++ to C#? The last time I seriously touched C++ was 10+ years ago. I've been doing almost all C# (and a bit of Java) since. The only reason I feel like I'm sticking with Unity is because of how familiar I am with C#.

Re: An Unreal Decision

#90

Post by Titanbase »

mrfusion wrote: post #71
Titanbase wrote: post #53

Earlier quoted context omitted.

I use Turbosquid for free 3D models, and then customize them in Lightwave or Blender. I work on my own textures. For audio I rely on Looperman for free music and sound fx.

Wow. Thanks to the link. Would this be a good way to go for beginner (hobbiest) oculus rift development? Are there any tutorials out there that explain your process a bit?

I use Cocos3D for iOS and Android 3D apps and games. It's also free. :)

Best bet is to load up the project "Cocos3D Mashup". Then you can adjust things, try loading new models and taking programmatic control of the scene.

Post reply on HN