No More "Cool" Features Please Until Crippling Stuff Is Addressed

I was playing with cursors some time ago and remembered this from docs.

Quote from DX9 MSDN docs:

 

Aleksey's solution works on both PC and Mac and supports multiple sized cursors under DX9. So it's perfectly possible. But I still want to use Unity's integrated solution as it is meant to add support for Linux too and reduces a third-party dependency.

I will also point out that when importing cursor textures, there is a max size field which gives a lot of POT options way above 32, suggesting that different sized cursors should be supported.

 

OK so we should postpone all the new "cool" features until some bugs are fixed... but we should still keep getting all the absolutely awesome features in the meantime!! YAaaay!

 

New features and bug fixes are both important. Unity do their Ninja Camp weeks where new features are tried. Perhaps they should have a bug hunt week where they only work on fixing existing features.

 

But... every day is bug hunt day!

I'm a very bad bug hunter though, cuz I only stick with the basics! But people who want to gamble and try new thimgs (aka do a voxel engine) usually find lots of bugs, which are reported, right? And I bet Unity works hard every day to address all those bug report issues!

 

Actually too much half implemented and buggy features leads to demise. This fact has led to the total failure of other engines in the past, and led the companies to go defunct. You dont have to look far to see it elsewhere.

From a customer's perspective, if you were to go to a engine's forum and all you see are developers complaining why the features arent working, buggy, or just half-assed implemented ... you'll walk away, because you wont want to waste your time trying to fix things yourself.

On the other hand, if a customer goes to a forum and sees that developers are complaining about not have new shiny bells and whistles, but little to no complaints about the features and how they work, you'll choose it because you know you arent going to encounter headaches in your project.

It's like seeing two cars for sale. One has all the luxury items, but they only work part of the time, sometimes you'll have to use duct tape to make it work, and sometimes with a little luck and effort it will work when you want it to. The second car, doesnt have most of the luxury features, but the ones it does have they all work when you want it and need it. Which car would you choose?

 

How many titles produced in Unity look more like Zombieville and Angry Birds than John Madden football? The hype around Mechanim as the flagship feature in 4.0 is of nil value to many, particularly indie 2D-2.5D developers. So... if you take that 'groundbreaking' tech away, what is left? Basically a competent incremental release.

The long promise 2D system? The 'upcoming' replacement GUI system (that for a 4.x release is just sad...and embarrassing), the aging monoDevelop version? The sad...sad state of Unity's 'available' learning tools. Thank God for the 3rd party support of quality training materials, cause Unity has produced squat all the way back through when Tom H. was promising them in 2009-2010.

Yeah, they're making progress, but clearly to attract bigger players. But how does a big player look at Unity when in v4.0 we're still implementing the crappy GUI system? Promises of a better GUI future not withstanding. Did all the dev money go to the purchase of Mechanim? How very Autodesk of David.

 

My opinions on the matter can only be expressed by ironic image macros:

 

Games Foundry,

First off, l have to say I completely agree with where you're coming from. Sure, the thread title is a little hyperbolic, but the fact is way too many tools attempt to focus on half implemented headline grabbing features at the expense of having a stable, robust core product. That would be the primary reason I left Lightwave 3D behind years ago. And gee, go figure, they're now dying a slow and withering death because most other 3D guys got tired of Newtek's shenanigans too. I'm hoping Unity doesn't go that direction, and shows better discretion in hitting the right balance between advancing the feature set and making the core functions robust and reliable.

All the above not withstanding, I don't think upgrading to Mono 2.8 or even 2.10 is really going to address the specific problems you have adequately. Though I'm sure to get some hate for this, I think there is only one reasonable solution for Unity to truly move into position to become a AAA engine: Unity must implement support for C++. In fact, I'll go one further, to streamline things, they need to drop support for Unity Script and Boo entirely (which will really annoy the three people who actually use Boo), and support C# as their "lighter" language and C++ as their "serious" language. Given the open sandbox nature of your game, I'm not sure anything short of coding it in C++ where you have direct control over all GC functionality is really going to make the problem go away. Managed languages like C# and Java just aren't well suited to this task.

Simpler games that don't need low level access could still be coded in C#, taking advantage of that languages greater speed and ease of use. Meanwhile, the bigger, more complex projects that do need that low level access will have it. I think lack of C++ support may be one of the key factors that keeps major game studios from seriously considering Unity. Of course, this may also not fix your problem as it would mean you would have to re-code your entire game in C++, no mean feat. However, it would provide a clear path forward for next time and for anyone else tackling these larger projects.

My $0.02 worth. Let the flaming begin.

 

you can get a source code lisc...its just really expensive ($50,000?), but you can get it to get that C++ access you speak of. I wish that was included in a pro version, but what can you do.

 

I have a bug where if I shoot at a disabled collider on my gun, my health still takes a hit and collision is still active.

 

Very true kablammyman, but $50k is well beyond the reach of most indie developers. I personally just think C++ should be supported by default regardless of licence. It would go a long way to making Unity a world class tool. Let's be honest, what is Boo support buying Unity at this point? Heck, how much is Unity script really buying Unity? Anyone who can learn US can learn C# and be better off for it. Refocus the resources into that which will give maximum benefit both to the community of developers as well as the company itself.

 

World class tools with source license generally cost quite a bit more than $50K. We can argue over what constitutes a "world class tool" but if you're an indie developer you probably don't need a source license (even if you believe you do) and if you're a pro developer, $50K is pocket change; most mid-size studios will spend more annually on their beverage food than the price of a source license but what it buys them is a perceived security net.

I would say that UT is not in the habit of giving away their source code or putting a low price on it due to a number of factors. One of which is the support cost of someone paying a few hundred bucks for a source license, modifying the C++ engine and then wanting support from Unity for whatever they broke. In addition, putting together a multi-platform, cross-compiled build environment is non-trivial. I am sure that Unity has at least one build engineer whose sole job is to make sure a build can take place. Another factor is that Unity as a company has a number of licensing agreements with various middleware providers where they have no doubt signed NDAs that prohibit them from revealing certain information about an API or SDK unless you as a developer also sign a heavy weight NDA. Signing that NDA allows you to see inside the guts of not just the Unity source code but the other middleware solutions too. If you are a studio, signing a middleware NDA isn't a problem and breaking it will have real consequences for your business. If you are a Joe Schmoe looking to make a simple web game but think you need the source license, you probably don't want to sign a multi-page NDA that requires legal counsel and you might break the NDA without thinking twice about it.

I believe that including UnityScript adheres to the "democratization of game development" that Unity Technologies follows. By including a more approachable and less rigorous language Unity appeals to a larger demographic than just hardcore programmers. C# has a slightly steeper learning curve than UnityScript and if you have never done anything deeper than "Hello World" and banged out a couple of HTML pages UnityScript is an ideal starting point. I prefer C# over US, but lets face it, C# contains a lot of legacy grammatical conventions that are not truly necessary. It is well known that different grammatical structures in languages cause you to think about problems and solutions differently.

Boo obviously has some legacy implications for why it is sticking around. This is mere conjecture on my part but I suspect when the first iterations of Unity were being created there was at least one Python hacker on staff who hates C# because nobody programs in it, thinks JavaScript is a toy language, but really, really, really loved Python and pushed very hard for the inclusion of his favourite language. There may even be several systems within Unity that rely on Python and rewriting them in a different language would cost too much at this point.

There's nothing inherently wrong with Boo or Python but the inclusion of it from the perspective of we as outside developers is irrelevant and causes a head scratching moment. From within Unity, as a company, it is a check mark feature, appeals to people who might be considering Unity but feel comfortable with Python, and doesn't take much in the way of support at this time for the very few developers who are using it. I don't know if Unity Technologies keeps track of which projects use which language, but I'd wager that less than 1% of developers are actively using Boo. When Boo becomes too costly to support or update, i.e. the move to a new Mono framework, it will quietly be killed off.

90% of the functionality that a game player experiences is not written in C++ these days. Lua, Python, or some other scripting language drives the user interface, most of the game object interaction, creation of objects and many other pieces of the game. I would say that C# is actually at a lower-level than what most game studios use for their games. Show C# to many technical game designers and they'll not have a clue where to start. These days, if you are writing all of your game in C++, you are doing it wrong. Beyond core functionality, e.g. collision detection, physics, audio, channel mixing, many features are scripted and only moved in to C++ if there is a performance problem.

In "professional game development" the core game engine is written in C++, usually as a monolithic application with middleware libraries statically linked. Unless the studio has a technology division very few in-house encapsulated libraries are created because it takes too long to generalize functionality under deadline pressure. Unity doesn't prevent a hardcore C++ guy from getting dirty (been there, done that) if they want to and partially encourages some good practices in that regard because the only way to interface to the engine if you don't have source access is through the provided API and a dynamically loaded library.

 

Hey Justin,

Though your points are largely valid here, nothing you said does anything to solve Game Foundry's performance issues with the GC spike. That being the case I'm not going to address them directly as I don't want to derail the thread. It would however be an interesting discussion for another thread "Should Unity implement C++ support for a broader spectrum of licences or not?". Back on topic, I'm not sure if you read the rest of the thread, and the whole reason the OP created it, but if you have ideas how he can solve his performance issues without getting C++ level access, I'm sure he'd like to hear them. Actually, so would I, as the issue is liable to rear its head for myself before too long.

 

It's a double whammy unfortunately. Updating to Mono 2.8+ and the faster gc should alleviate the problem by reducing the thread freeze time to hopefully be within acceptable limits, or it might allow us to perform regular concurrent gc that goes unnoticed, but it doesn't fix the heart of the problem. That problem is that not enough work has been done in the UnityEngine API to eradicate unnecessary allocations, or to make it open enough to allow us to override functions with our own super-class non-allocation based solutions ( sealed classes everywhere ). What's feeding the gc in Folk Tale at the moment are TerrainCulling related functions in the API that get called per frame. After a huge amount of rework most allocations have been removed from the code we control.

Having C++ access wouldn't solve our problem, which is that we have to use the API calls. I'd also have to learn C++, but that's not an issue and is something I'd enjoy. If more knowledgeable programmers have a solution to opening up the API, we'd love to hear your ideas.

Can a community manager please elevate this thread so it gets some attention from a senior tech decision maker. What many of us would benefit from are two very simple questions answered:

1. Has coding work started on a migration to Mono 2.8 ( not just talking about it ), or is it a case of it not being a priority right now, and 2.6 is considered good enough for the majority of users. If coding has started, what is the planned version number for release?

2. Can the API be improved by 4.1 to eradicate allocations AND/OR open it up to allow the community to fix it?

 

C++ dll isn't the answer? I noticed alot of people don't use this feature but Its actually really easy.

Indie is quickly losing its meaning. I personally know the directors of several AAA companies that actively promote their companies as 'Indie'.

 

Unity4 still crashes to desktop if you allocate too many objects at once ("Too many heap sections" error). This is a bug unique to versions of mono so old they're paleolithic.

I don't really feel good about selling a game with this 'feature' in it. Like: "Oh, it sometimes tries to do too much at once and falls over. Nothing I can do about it, the engine just does that."

Not a good feeling.

 

C# is actually easier then US , due to autocomplete.
As someone who started with US , you have a great point . I think i even missed out on a job since I flaunted about coding in US and the interviewer was a big C# user .

C++ support would help, for all you hardcore programmers who like to use coding languages older then half of us .
Although in an alternate reality where C++ was the only coding language supported by Unity I would not be using it today .

 

Out of curiosity. How many are "too many objects at once"?

 

That has been part of Unity since 1.0.
Stop creating and trashing data and instead properly pool data (a basic development technique since 3D hardware and enough RAM became the norm) and you have this problem solved actually. Unity can not solve OS and hardware limitations and Unity can not solve suboptimally developed games that run on top of it.
Keep in mind that the engine is native code, the only place you can actively generate trash is your very own script code as anything extending from UnityEngine.Object is just a wrapper around a C++ object that is not even maintained by System.GC and will not kick up the GC

Any engine suffers from the problem that suboptimal game code that creates and destroys data all the time will inevitably cause the OS to kick in and punish you for it.

The only 2 things Unity Technologies can and should do on this end is expose the GC control and make the plugin interface stronger (learning from Shiva on this end or oldschool AAA engines like Gamebryo and Trinigy Vision)
In 2.0 days the GC was not remotely as agressive as its nowadays but the stronger their mobile support became the more the global GC behavior was tuned toward agressive cleanup and I'm not sure it really takes the basic GC logic into account any longer (clean stuff when memory is tight, don't dare to dealloc it if the OS has 8GB of RAM free)

Also a mono upgrade is planned (see the bleeding edge framework in your installation). Its just no small thing as UT has to port their 2.6 fork to 2.10 or even 3.


As for C++: Yeah a C++ through Mono compiler would change that much, though for sure not to the better. There is already a not usable language with zero documentation, we don't need a UnityScript with pointers on top of UnityScript
You will not get native code as a wide variety of the platforms could not be supported reasonably. Users with that desire might potentially prefer to look at OGRE3D, might suite their liking more than trying to get a proper game engine 'trashed' just to please their inner masochist.
Out of my view a proper plugin layer would be a significantly better approach

 

I think you need to read this entire thread again Dreamora.

 

900MB, according to the people at Arcen Games. (Found by googling the error name.)

I've been hitting the limit working on a minecraftoid adventure game.

 

Just wanted to mention that calling GC.Collect() does not guarantee garbage collection. It merely strongly suggests that the garbage collector run. How often you "get lucky" and have it work is a throw of the dice. But yes it's considered bad practice and is generally only done with COM objects and other such antiquated things that don't automatically release their memory normally.

Also, C# has passed C++ in professional usage quantities earlier this year. C++ was great in it's day but its time is over. Java of course is even more popular than C# by a long shot.

 

Would it be possible for Unity to decouple the game engine from the version of Mono and allow developers with appropriate skill levels to use newer versions?

For instance if the Unity game engine is at heart a C++ driven dll then only the linking C# code would need to be accessed, this would not require a full code license?

Not sure how this would impact the User Interface but as this is tweak-able and programmable developers could ensure their own build settings are used.

 

There's also this Feedback request which basically equates to updating Mono. As to how frequently checked a feedback system is that lists a number of launched 4.0 features as "Under Review" - the step before "Planned", "Started" and "Completed", is anyone's guess. Irrespective, superpig's request has my 10 votes.

------------------------------------
To help keep the thread on topic, we're waiting patiently for a response from UT to the following:

1. Has coding work started on a migration to Mono 2.8 ( not just talking about it ), or is it a case of it not being a priority right now, and 2.6 is considered good enough for the majority of users. If coding has started, what is the planned version number for release?

2. Can the API be improved by 4.1 to eradicate allocations AND/OR open it up to allow the community to fix it?

I've also sent an email to our account exec asking for this to be escalated.

 

You might also consider extending the scope to cover all functions in the API that cause allocation, for example terrain culling. There's also the non-caching of lookups like .transform. A lot might be solvable by the community if classes weren't sealed.

 

Thanks everyone for all your input, I'll forward this to the devs.

P.S. Don't be afraid to PM me links to threads like this.

 

In the MonoDevelop packaged with U 4 it says this on the about screen versions:

Is this not the version that Unity is using? How would I check what version Unity is using?

Edit: After running the following code, it shows that Mono 2.6.5 is still being used.

Code (csharp):

1. Type type = Type.GetType("Mono.Runtime");
2. if (type != null)
3. {                                          
4.     MethodInfo displayName = type.GetMethod("GetDisplayName", BindingFlags.NonPublic | BindingFlags.Static);
5.     if (displayName != null)                  
6.         Debug.Log(displayName.Invoke(null, null));
7. }

Does this mean that compiling dlls under MonoDevelop is with mono version 2.10.2 and could end up breaking in Unity at runtime?

 

In response to dreamora's lengthy waffle about how we're all bad programmers and should never allocate garbage, well ... what the hell is the point of using a managed GC language? Seems like you really don't get it, dreamora.

In any case, not worrying so much about trivial garbage spikes (but taking care of the big garbage stuff yourself) leads to a lot faster development, less optimisations needed and far higher productivity. Due to having less code as you don't need to worry about GC, you can be assured your game is bug free sooner as well.

We all know how to manage garbage. Having less to manage is a good thing. Be nice if people didn't have to explain.

 

Thanks for taking time to join us Joachim, I'm sure you are busy so it's very much appreciated. Reiterating previous posts in this thread, it appears the documentation is out of date, which is usually the first point of reference when it comes to implementing new Unity's features, and that only states Windows and Mac. I also posted that I'd performed all the steps mentioned in your post. http://docs.unity3d.com/Documentation/ScriptReference/Cursor.html. Perhaps the documentation can be updated and include the constraints, identifying which platforms are the constraining factor. I presume this must be Linux or Flash given the third-party hardware solution works on Windows and Mac. With some creative changes we can work within this constraint, so it doesn't need to be discussed further within this thread.

The thread evolved beyond the OP to crystallize into two important questions:

1. Has coding work started on a migration to Mono 2.8 ( not just talking about it ), or is it a case of it not being a priority right now, and 2.6 is considered good enough for the majority of users. If coding has started, what is the planned version number for release?

2. Can the API be improved by 4.1 to eradicate allocations AND/OR open it up to allow the community to fix it? <- THE MOST IMPORTANT QUESTION.

It is these questions we would very much appreciate a response on.

Question 2 is by far the most important. Most skilled developers have already gone to great lengths to eradicate allocations from their own code. Unfortunately given the closed/sealed nature of the API, we cannot eradicate allocations found therein. We appreciate it may not be an easy task to achieve in a generic system, therefore opening up the sealed classes and making certain variables public might enable developers to write their own optimized solutions for their specific projects.

 

I'm pretty sure he gets it.

The point is that you don't have to track what you use and that you don't need to write code that cleans it up for you when it needs to be cleaned up. You don't need to worry about memory leaks because the only things in memory are things you actually hold references to.

It's not what the garbage collector does that's the problem here. Nobody's going to argue that cleaning up after us so that we don't have to do it ourselves saves us bucketloads of time.

It's the when that matters, and there's only one way to control the "when" that can actually solve the problem.

If you write code that needs memory to be cleaned up when you're doing time-critical operations (such as maintaining a high frame rate on a mobile device) then you're not properly controlling the "when". As long as you are allocating at those times there is no full solution to the problem. The garbage must be cleaned up because if it is not then you will eventually run out of memory. Any control you can take other than fully eliminating allocations simply moves the problem elsewhere - and there are many elsewhere's that make it a lot worse.

 

Yeah, you're probably right on this. Unfortunately it devours and dilutes my 10 feedback votes Given how committed we are now to using Unity, it's in our interest to lobby for a resolution to the points raised in this thread. Would there be some interest in a community based project to identify as many API calls as possible that are causing allocation, all the non-cached variables that cause allocation ( e.g. .transform ), and a list of suggested improvements to the API?

I see it as a continuation of the thread "Garbage Collection, Allocations and Third Party Assets".

EDIT: I removed the incomplete feature implementations out of the scope as I think it will detract from the focus, and the Wish List already has this covered.

 

I'm bumping this thread now it's Monday because unfortunately only the OP was answered, and the not 2 important questions raised in the thread:

 

Thanks for bumping this topic in my inbox and adding the latest topics in the first post. I can assure you that the devs know about this thread.

 

Thanks for looking at this Lucas. If UT can eradicate all the allocations from the API, that should allow us to complete Folk Tale without the faster gc of Mono 2.8. This week I'll start documenting and reporting any API allocations I spot, and encourage community members to do the same. I'll probably start posting them over in this thread as well as submitting bug reports.

Any greater control you can provide over the gc in Mono 2.6 would obviously be welcome.

Is there a reason why so many classes are sealed btw?

 

I've just googled looking for the Public Bug Tracker so I can see what's already been raised, but it appears there isn't one. There's nothing under the support menu, so the next logical place would be under Community next to Forums, Answers, Feedback, [BUG TRACKER]. Does anyone know if there is one? I've seen plenty of requests asking for one spanning back a few years.

 

There isn't a public bug tracker.

--Eric

 

"Much" or "all"? We haven't upgraded to Unity 4 yet, but are planning to do so when we start our next round of projects. But if UnityGUI no longer allocates anything in Unity 4 that could well be worth an immediate upgrade for a couple of our projects.

 

Not all.

--Eric

 

Is it at least now confined to areas we can avoid? I'd be happy with that as a starting step.

 

Here's my main grievance with unity. Maybe for unity free, they could have an easier way to implement baked shadows into a scene you built in unity. I'd consider that a fix. Trying to set up thousands of blob shadows all over the place is ridicules, I could master UDK faster than it would take me to make one unity scene not look awful due to no lighting solution.

I could bake shadows in my modeling program, but I want to be able to add to my scene and not have to go through the baking and exporting phase each time. Seriously, am I missing something?

 

I just don't do shadows . That's a limitation of Unity free you have the option of working around that limitation , buying a student license and making a non commercial game ( enroll at your local community college ) OR buying Unity pro . You can get alot done in Unity free and save 120$ a month for a year, buy pro and upgrade your game right before shipping .

 

I thought that lightmapping worked in Free?

 

Eric or Aurore, should you wish ( and there are no objections from others ) this thread can be locked in 24 hours now the main questions have been answered and there is a call to action for community members wishing to report allocations in the API. I can always request it be re-opened at a later date should it be required. Thanks to everyone who took the time to provide their input.

For developers wishing to report an API allocation bug please consider following these steps:

a. Read all posts from this point in this topic to check a similar bug hasn't already been reported.

b. Submit a bug report with the first line reading "[Function Call] API call causes C# allocation". For example "Terrain.CullAllTerrains API call causes C# allocation"

c. Make a post in this topic including the bug report id ( from your email confirmation ) and a deep profiler image highlighting the allocation