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

Launch day is finally here with a flurry of activity. It all looks wonderful and full of promise. But today my enthusiasm-swing'o'meter has barely registered. 4.0 for our standalone project can only be described as a non-event, when really it shouldn't have been.

I'm a committed customer on a serious long-term project trying to communicate the issues that I've faced over 18 months of working in Unity all day nearly every day in the hope it leads to making a great product even better.

Issue 1: Incomplete Feature Implementations ( Grayed out as no longer relevant )
Okay, so the Linux build target is going to be really helpful if it all works. But earlier today I read in the Cursor API documentation that hardware cursors are only available on Windows and Mac. So that's a piece of unusable functionality for us if it's incomplete ( needs to include Linux, or perhaps the documentation is out of date ), much like the pathfinding was in 3.x and remains to this day. I've also discovered that only 32x32 cursors appear to be supported, and we have a lot of 48x48 or 64x64 cursors ( see a post on page 3 for more info ). These are but two of a number of features be they new or existing that the community have voiced their opinions on as being incomplete.

Issue 2: Mono 2.6 and Cripplingly Slow GC
The community has also complained exhaustively about the slow garbage collector. Many developers end up spending hundreds of hours rewriting code to avoid allocations - a hidden cost that has to be factored in. Unfortunately we can't self-fix a closed API that returns new arrays or makes internal allocations that only serve to feed the problem. So we're left tackling a periodic glitch in game play when the gc kicks in, causing the frame rate to hang for a brief but noticeable period, ruining the gaming experience. All those lovely 4.0 graphics are useless without an engine that runs smoothly - a claim made here. UT, please accept this as a request to eradicate allocations in the API by providing overloads that accept existing arrays for population and cleaning up sloppy code ( e.g. non cached lookups like .transform ), stop using sealed classes, and/or assign more resources to upgrading to Mono 2.8+.

Please note: obviously the title is intentionally a little bit silly to grab attention. We live in a world of commercial realities, and development of new features can and of course does happen in parallel to bug fixing because there is more than 1 developer. The community recognizes the need to be competitive, innovate and make sales to fund future development. The crux of this complaint is that we believe a greater priority needs to be given to more comprehensive implementations and fixing existing issues, a number of which have been around for a few years.


UPDATE 1
The thread has evolved beyond this 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?


UPDATE 2
There is a thorough response from Lucas@UT answering these questions. The focus of the discussion is now Issue 2.


UPDATE 3
If you notice allocations within API calls, please follow 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


BEFORE POSTING
Please consider following the steps to escalation to keep the discussion focused.

 

On the .NET/Mono Garbage Collection, one slight problem - even using something like Visual Studio (as I do in my day job), the programmer has zero control over when the GC fires. The problem is the same as that in Java.

...However, you can have your classes inherit from IDisposable (causes the classes to be required to provide a public override void Dispose() method) to null any special resources that you are no longer using so that you can get the reference count for that class down to 0, so that the GC will be significantly more tempted to fire.

This is a problem I traverse every day in my day job. While you could do what you said and simply not allocate resources (one day, that I've got to see...), in the end it's much easier and more effective to apply good software development practices.

I'm sure you're right in claiming that Mono 2.8 would solve some issues, but it won't avert the fact that the GC has some fundamental problems associated with it across the board, and across languages for that matter.

 

Yup, familiar with the general lack of control managed frameworks offer ( 10 years .NET experience prior to coming to Unity ). But do UT have the option to change that in mono given its open nature? That would be my suggestion if they didn't want to update to mono 2.8.

Allocations are well managed upfront and nearly eradicated on a per frame basis during game play in Folk Tale. Now it's mostly the odd third party component which hopefully a thread I ran a while back helped improve, unity's own API where arrays are returned, or just unoptimized classes that call non cached variables ( came across one in pro water specular today ).

 

While mono 2.8 might get you a better garbage collector, it's not actually true that you don't control when garbage collection happens.
You can make garbage collection happen by calling GC.Collect(); It's considered bad practice of course, but this way you can determine when it happens. If you do it every frame, you will have very little to collect, and therefor very little performance hit. As part of my normal work, we worked with Microsoft, and this was the only solution that worked all day, every day for our application that required us to limit pausing (non-game).

 

GC.Collect(0). Yup, being able to call it on demand is nice and all. But if you're going to do that, you also need a means of preventing it firing off when it likes. The issue with mono 2.6 however is that it doesn't matter whether you manually collect or let it do it automatically, the operation is simply far too slow when it happens.

I tested all time execution plans. GC performs badly under all, meaning avoiding unnecessary and regular allocation ( which will ultimately be treated as garbage ) is your only real option.

 

Honestly, losing your hat over not having a hardware cursor is over the top - is that really enough to completely spoil your excitement about 4.0? The garbage collection thingy I agree is a bit more of an issue, but ultimately overall it's not a huge problem.

 

The opening post could hardly be described as losing One's hat, even if it has taken 4 years to add a mandatory feature required by RTS games. We already have a hardware cursor solution that covers Windows and Mac. I was looking forward to adopting an integrated solution that covered all target platforms. The feature was highlighted to illustrate that partial feature coverage of target platform groups ( standalone = pc, mac, linux ) is not all that helpful. An equal comparison was made to the partial implementation of pathfinding in 3.x. Navmesh pathfinding solutions are only usable in a limited number of scenarios, and for that reason more comprehensive solutions include grid and list graph implementations as well.

Garbage Collection is a huge problem if you are working on a full-blown standalone game with long uninterrupted game play. It makes a project non-shippable without serious changes that compromise game design because of a quality defect. Sure, it's not a problem on say turn based games where game play is broken into separate sections, or on a short platformer level with regular level loads. But in a sandbox RTS game with potentially hours of uninterrupted play, it is ultimately a huge problem.

 

I very much agree with you.
I wasn't aware of the specific hardware cursor problem, as I haven't bothered to look at Unity 4 yet, nor do I need a cursor for what I'm working on currently, but I can see how that would be an issue. The only thing I can say is that I think Linux is still a developer preview/beta release, so maybe they will put some effort into this before it goes full release?
However, with regards to GC, I noticed this early on, and basically designed my game around an almost completely static memory footprint, which has been a pain to do nonetheless for something that has gotten quite a bit larger than what I initially planned, and as a result constantly uses more memory in each level than it probably could/should as a result.

Personally I see this as a fundamental problem with non open source middleware, and it would go a long way for Unity to make a concerted effort to not become like most middleware providers, which often ends up doing more harm than good, simply because of the constant need to add half done features and close off access to the internals to suit a business model, and limit upgrades on third party stuff (mono) simply because of whatever constraints/inefficiencies there are in their own development pipeline (or other reason?).

The up side is that Unity does a lot of things for us that make things easy, the down side is that if they are incomplete or don't run well, our game is at the mercy of their system. Personally I don't think a game engine product can follow the development methods of most other software, because often times a partially introduced feature in production software means you just need to do workarounds or some sort of extra steps to get something done. However, since the engine is integrated into our end product, half done or poorly implemented features are, in many cases, a much larger issue.

 

This thread is Stupid. The OP's complete development life has ended dramatically because of a Hardware Cursor and a Garbage Collector.

Unity guys better stop production immediately as the OP has discovered crippling, AND I MEAN CRIPEELLING, errors that have changed the balance of power in the Universe.

Yeah I know, but, a bullshit thread deserves a bullshit reply.

 

yeah, this is stupid! Besides his particular arguments, unity is perfect!! Everything in unity works as expected, and I never had to make work around for an oft publicized and advertised feature anything in unity... ever! /sarcasm

while the GC problem has been spoken about, I want to also add that many of the half implemented features should be fixed, and optimized. I dont need more fancy bells and whistles, just fix whats there. I'm looking at svn support, asset bundles and path finding in particular, but there are other things that bug me that I'm not even thinking of now.

 

Actually Amon, this is not a stupid thread. Granted some of the complaint was pointless, the idea behind the complaint is completely valid. Way too much time has been put into making 'cool' features, and not providing some solutions for existing problems.

GC is a problem.

I dont have the problem atm, but thats cause I spent weeks re-writing code to avoid destroying anything. I also removed a bunch of cool features. I suspect, that if I ever get to the point where I can work on games full time, I will drop Unity.

 

The thread isnt that stupid if you have been lurking these forums. There have been posts that pop up from time to time where someone is complaining about very specific features that dont work as expected. This isnt a new thing and it will probably never go away, but I feel there is merit in the idea "Have all features working as expected, then work on new stuff". But pre-existing features dont always sell product.

 

This.

The original poster's choice of specifics might not be the ones I would have picked but his broad point is spot on. The GC is a problem and Asset Server is an unholy mess. I've only just recently set it up locally and now I realize just what a lot of work the guy who manages our Asset Server for work has to do. A couple of guys at work were reporting bugs in Asset Server nearly a year ago - really basic things like a failed commit blocking all incoming commits for 48 hrs - and the same basic bugs are still in there.

The problem isn't only that they focus on headline features, it's that they focus on anything which gets headlines. So anything a big developer needs gets priority, because a big developer using Unity gets them headlines. Mechanim gets priority because it gets headlines. Asset Server? Presumably a lot of the larger developers already use SVN, so this is way down the list. I'm not sure why the GC is such a low priority, but evidently there's no publicity in it.

 

How about we still have cool new features AND old stuff gets fixed?

 

You know what they say... cant have your cake and eat it too

 

I really love using Unity, I really love Unity Technologies (UT), I'm amazed at the frequency of updates, there keenness to address bugs (when reported) and the value for money this can represent, especially compared to the last IDE I was using (Adobe/Macromedia Director = no update to 3D engine in 10 years).

However I completely agree with your premise. It is really frustrating to see incomplete features rushed out with new releases and then often forgotten about. Myself i'd site color32 as a good example. It was really cool that they added this to address part of the performance issue of having to use floats for colors as its not native for the common image data formats. However they still only let you update 24 or 32bit images and the color32 version of setpixels() isn't overloaded to take a sub-rect! I haven't been able to test out the navMesh since it was introduced, but again I felt far too many features were missing from it to call it complete and suspect many have not or will ever been retro-actively added. Again its just a missed opportunity.

I'd also make the point that i'm disappointed that UT seem to be so 'game-centric' focused too. As exciting and cool as many of the features of 4.0 and many 3.x releases were, i'd really welcome some effort on their part to support the wider market of developers using their IDE for non-game centric projects. A perfect example of this would be improved video support, at least offering mp4 (and streaming). For a recent high-profile project I needed to add a video tutorial, as it was browser based I had no choice to use the horrible ogv format. Not only did it produce larger files with poorer quality, but meant I couldn't leverage say youtTube to store the video and stream it down. So I ended up having a youTube version and a dedicated ogv version for playback within the browser player.

I'm not really up on the whole mono versions, but I am confused as to why a major release version hasn't switched to a more updated version. To my mind a major release is the perfect time to do this, due to the potential backward compatibility it might break ( which has often been an arguement for not updating to a newer version of mono).

In fact Unity's whole major vs dot releases is something I don't understand at all. From my perspective some of the 3.x releases were far more exciting and more feature packed than the 4.0 release. My expectation is that a major release introduces the most new and exciting features, then to releases fixes bugs, streamlines and improves existing features, but that doesn't really seem to be the case with UT.

So all said and done I would very much like to see a release that focuses on improving what we've got before adding more stuff, most of which is sadly irrelevant for my day to day client work.

 

Well, you can do GC.Collect() ...and optionally, GC.Collect(Int generationCount). If, to improve performance, you absolutely need to control a collection cycle, I say, sure. However, a question arises from your response: is it truly necessary to invoke the GC every frame? The engineer in me partially agrees with you, "yes, in certain circumstances." (Specifically, something that some other engineer has coded particularly horridly. Maybe I'm missing something...but under what well-designed circumstances would it be necessary? This is a genuine question. I truly don't see the perspective underlying that statement.)

However, the engineer in me also disagrees; I've done some work with C++, and one of the basic instruction patterns you have to use in that language, due to the low-level nature, is the Allocate, Use, Deallocate pattern. That is, define a resource, perform some operations. When the app no longer requires that resource, free it because something else probably needs that memory (thus, a more performant program that dosen't starve the OS or other applications of resources...not that that is a serious concern in most modern OSes, let alone Unity.)

A good many programmers I've worked with (sadly enough) have mistaken the GC as an amenity that lops the D off of the AUD pattern. This is not the case; if you read the salient documentation, you find that it's controlled by references. The GC was made smart enough to not deallocate something that is being used by something else in case it is still needed, to prevent those pesky NullRef exceptions that we C/C++/C# programmers hate (yes, you can still get NullRefs in C# if you're not careful, or simply miss a spot!)

The reason in my post I brought up the IDisposable interface was that, since C# has no actual destructor in the same way that C++ does (there are finalizers, but it's far from the same thing, given the control the GC has over itself), we need some way to clean up this reference count. Having objects be disposed when they are done hardly ensures that the GC will immediately clean them up, but as you said - if to improve performance you need to insta-perform a cleanup, well, you can always do GC.Collect(); GC.WaitForPendingFinalizers();

However, the GC is a nice convenience too. It does some of this stuff on a 'when it thinks it should basis', and there's many situations where - if you've coded correctly - you really don't need to concern yourself with invoking garbage collection. A small bit of design/architecture can make your game performant, with little need to directly invoke garbage collection.

Easy reader version: Use the right tool for the right job.

 

As far as I understand how GC works, it [almost] doesn't matter how much garbage it collects. The thing that matters is how big is the dependency graph of objects that are still in use. The ideal case is all the allocated objects are garbage.

Calling GC.Collect() is considered bad practice, because it may move potential garbage from generation 0 to higher generations. But since the current Mono's GC doesn't support generations, calling GC.Collect() manually, I guess, is not a big deal.

It does work.

 

There are a lot of things that would be nice if they were finished but even before then I would prefer to see some decently complete documentation. Spending hours scouring the web or diving into the dll's because some api functionality isn't adequately covered has caused more lost time than anything else for me.

 

I don't understand why people get upset over the lack of control over the GC. Unless you eliminate allocations all you can possibly do with more GC control is move the problem around. You can't fix it, and you can potentially make it much, much worse. I'm interested to know what kind of control people desire and how they think it will help?

One thing I would like is for Unity to provide us with allocation-free versions of all functions (except those used to create things, of course). If we need to get an array it'd be sweet if we could pass in one we've pre-allocated, the built-in GUI system (OnGUI) is a monster that really ought to be tamed, and so on. If we follow a few best practices of our own (such as pre-allocation and pooling) those things will make it much easier to write smoothly running games.

 

I was under the impression that the current version of mono used in Unity is sub-optimal in terms of performance when doing GC and not that poeple simply want to control (though they want that too). I'm sure I remember reading about GC being slow in the version used in Unity and that later versions of mono improve on it, but I might have just imagined that

 

I disagree with the fact that this thread is BS, it just hasn't listed all the potential items that could be fixed that are time consuming to fix due to incomplete features in new releases that are never revisited. Hardware cursors is just the newest. What about the Input Manager. How long has that been at the stage where you cannot even set things at run time ? Sure it's annoying and sure you can hack your way around it, but that is fairly basic functionality that should really work out of the box. I'm all forwarding the engine features, direct x 11 support is cool, but some basic features should be reviewed with release roadmaps as well.

 

Well, there are definitely faster GCs around. But a faster collection just means a smaller hitch, so while it might make it less noticeable it doesn't properly solve the problem unless you've got enough free CPU time that it doesn't impact the duration of the frame it happens in.

 

I best clarify or emphasize a couple of points. As a business we enjoy using Unity. It meets 95% of our business and technical requirements exceptionally well. We haven't jumped ship, we've committed, but that doesn't mean we shouldn't discuss it's weaknesses and the impact those have in the hope that it might push the issue higher up the agenda within UT and help the product mature into a AAA tool. Emotions aren't a factor in determining our position. We're a business with an important requirement ( to us ) from one of our key suppliers that we are trying to get addressed before it impacts the welfare of our team. Basic risk management. It would be negligent of me in my duties as a company officer and Project Lead were I not to pursue a resolution.

While the incomplete list of issues vary in severity, and only the gc issue will prevent a final product shipping until a workaround is found ( thus considered critical on a multi-year 10,000 man hour+ project ), it's not holding up development. However, it is consuming a lot of extra hours working around a significant part of the non-performing framework on which the product sits. A certain degree of frustration comes from there being a solution in existence ( Mono 2.8 ), however UT have to my knowledge made no meaningful statement of intent regarding the upgrade.

Important note: this issue is not really about gaining greater control over GC. The issue is that we can't eradicate all allocations because aspects of the system are closed to us ( API ), and unfortunately they feed the garbage collector because of their design. The desired solution is for UT to either modify their API ( providing overloads that let us supply an existing array ) just like we developers have to do with our own code, or provide the much faster garbage collector in Mono 2.8+ which as angrypenguin has pointed out, doesn't fix the problem, it simply reduces the impact.

For those interested in our efforts to combat the problem, we use an object pool manager and pre-warm objects when the game begins. We use cached variables wherever possible. We've done extensive research which we've shared, and encouraged third-party component suppliers to clean up their own allocations. We've eradicated most per-frame allocations from game play, apart from where we have no control ( like the sealed API returning arrays or Terrain.CullAllTerrains ). Design wise, we have event triggered cut scenes and force garbage collection at the start and end of play during fade-to-black to minimize the chance of frame freeze when the gc kicks in while the player is watching the cut scene. The problem is we cannot control the duration between the events because that is determined by the players own pace, and during that time, calls to the API are creating new allocations that end up marked for collection.

UPDATE: To help illustrate the point, here's a deep profile from the first 30 seconds where a player begins to play. We've eradicated all per-frame allocations from code over which we have control. The game runs at 60fps within the editor, so Camera.Render related calls in this instance are allocating 6.3KB x 60fps= 378KB per second on the heap, which feeds the gc.



We recently replaced 1 large 2000x2000 terrain having 28 textures with 25 chunks of stitched smaller terrain, each with 8 or less textures to reduce fill rate which had become an issue on lower end GPUs ( the terrain which fills the screen was being drawn 7 times ( excluding shadow pass ), 1 draw call for each splat map required ). These extra terrains may result in a higher allocation per frame than other users may experience.

P.S. I love the profiler.

 

Doesn't this work in Unity?

http://msdn.microsoft.com/en-us/library/bb384202.aspx


I don't know if this applies at all, but maybe worth investigating?
http://msdn.microsoft.com/en-us/library/yhwwzef8.aspx

 

Worth investigating as it looks like it's included in .NET 3.5, many thanks. Mono might not match the MSDN documentation though.

UPDATE: tried System.Runtime.GCSettings.LatencyMode = GCLatencyMode.LowLatency; compiles okay ( no surprise as it's supported ) but doesn't do anything. GC still firing of it's own accord. Looks like this isn't going to help.

 

How do you tell that the GC is firing?

 

In the cases where it matters it causes your game to hitch, so you can notice it. It's most noticeable on mobile devices.

 

Yup, it's incredibly obvious. As the first paragraph in that MSDN article described, GC freezes all your threads while it cleans up memory. It's this very behavior that makes it a critical issue for games with long sections of uninterrupted 60FPS game play, and why C# isn't really a good choice for such games.

Using the profile in the editor you can see when the GC.Collect spike happens and become very familiar with recognizing when it's happening in game. So when you run a standalone build, you know that's exactly what is happening.

 

The release notes say "Support for hardware cursors on the following platforms: Windows, Mac OS X, Linux, Flash."

--Eric

 

http://docs.unity3d.com/Documentation/ScriptReference/Cursor.html

So is the documentation incorrect?

"Supports Hardware Cursors on OSX and Windows, falls back to software cursors on unsupported platforms."

 

Well, one of them is incorrect....

--Eric

 

The point of the thread is still valid. There are enough other issues. Like the crashy and unflexible tree creator. Or the incomplete shuriken particle system.

That`s the old development dilemma. Focussing at fixing bugs and making the tools as fool proof as possible costs time and manpower, and can quickly lead to loose the connection to the opponents and their feature lists. And this could quicky lead to "outdated" because the opponents have much more features after a while. Focussing at throwing in new features only to stay state of the art and don`t care about fixing bugs makes the product unuseable in the end. The gap becomes too big at one point to get the baby stable enough again. The art is to find the right balance here.

Unity is overall at a not this bad track. I´ve seen much worse, up to features that just theoretically exists at the list because in reality the tool crashed all the time. And Unity is miles away from that. But it could of course be better.

 

I'm currently working on a project with 1.5 mio lines of code. A CAD software package for pressure vessel design (so completely non-Unity related). The software has grown since 1994 and was a total mess when I started working on it a couple of years ago: Bugs, missing or wrong implementations, difficult to maintain etc.

Beginning this year we switched the copy protection method which now enables us to make monthly releases with a mix of bug fixes, new features and usability improvements.

Why do I tell this? Because writing a complex, multi-million lines of code containing software can be a real PITA if you don't keep track of what you're doing. Solely concentrating on bugfixes will result in customers not happy about missing features that have been requested. Concentrating on new features will anger those who a waiting for a requested (semi-)important bugfix.

While I'm working together with my employee on the CAD software and we can carefully plan the content of the next months update, it's much more difficult for a company who has several dozents of programmers who must "hit" the same milestone with the implementation of their feature or the solving of the bugs in their buglist.

That said, Unity now has pushed 4.0 on the roads... now it's time to do some clean up for 4.1 before attacking new features for 4.5...

 

Yeah, but part of the original post was pointing out that features are being released early and incomplete, then requiring bug-fixing or additional time spent adding missing features, or worse just forgotten about and become legacy issues that developers end up having to work around.

 

With Unity , a solution for this would be to let 3rd parties implement the features . A perfect example of this would be NGUI ( the author and the RageSpline guy got hired on by Unity, yay) , when Unity failed to get something working right the asset store filed the void .

2D tool kit, ect . I'd love for Unity to fix monodev ( or pay the monodev team to fix it) . When I use JS in mono in quickly turns into a nightmare, and even though I have VS, I can't use it with JS !

 

Unity has quite a few employees. It seems to me as though they should be able to dedicate some of them to fixing old problems, and still have enough to make the new features people are excited for. Unity isn't the same as it was 5 years ago.

 

I'm in complete agreement with the OP. But then I'm out there in the trenches selling stuff.

Shame some kids joined the party without any clue why OP's issues are important, but thankfully they seem to have moved on.

I don't want control over the GC or anything like that. I want improvements to old junk that's rotting and festering. If that means new mono is faster execution, then I want it. If it means upgrading the physics engine then I want it. It is simple, the more speed I have, the better my graphics look. It has a knock-on effect all through the dev pipeline.

For me, that's more important than anything else.

 

I guess an apology is due so my apologies to Games Foundry. I'd blame it on me having a bad day but that's no excuse.

 

Yeah its not what you do but how you do. Dont half ass it.

 

It would be nice if Unity made some comments about updating Mono versions and keeping up to date with .NET iterations...

Right now I worry that we'll still be on the same mono in 3 more years.

 

Well unity are probably going to be bug munching immediate 4.0 issues for a while yet. When the dust settles, I'm thinking they'll want to get some more units of 4.0 sold, so that does mean it's likely we'll see some more features before we see upgraded <insert smelly old sock thing here>.

This is fine, I just hope they feel they can justify the time on being competitive with their competition in speed. I know from twitter, that the guys ARE taking GC "very seriously" - that was their exact words.

So assuming that, I think I would encourage them to improve any old stuff that's just not optimised as well and seeing that as a "compelling reason to upgrade" for many.

 

hippo, may I ask whom you are following on twitter? I follow a couple of UT guys but would like to track GC commentary.

The thread title was deliberately exaggerated. Obviously we live in commercial reality and recognize that a call to focus entirely on bug fixing is at bit silly. But the points raised throughout are incredibly important to a significant number of developers, all of whom I'm sure would appreciate a response from someone appropriate within UT.

 

I think it was rej, robert or aras... robert probably... check my twitter list which ones, as I can't check right this second (not online long).

 

Just sat down to migrate from Aleksey's HardwareCursor asset to Unity 4.0's Hardware Cursor. Very simple to do, and it even works in the Editor which is fantastic. BUT, following on the theme of partial feature implementations which end up being unusable, we have a number of 48x48 PNG cursors. These appear to be resized to 32x32 with aliasing which looks terrible. Perhaps NPOT is the issue, so I padded one such cursor to be 64x64, confirmed the texture type was set to cursor on import, and confirmed the max size was set to 64. Alas, it still gets resized to 32x32.

When this gets fixed, can I also encourage the addition of the ConstrainToWindow() wish list method I posted that keeps the hardware cursor within the window. This is extremely useful on dual-monitor setups when drag and drop or panning at the edge of the screen.

Raising a bug report.

 

For those that are interested, this is the improvements to the garbage collector in mono 2.8 http://www.mono-project.com/Generational_GC - there are even some more improvements in 2.10.

IMHO Unity should dedicate a few engineers to work fulltime on Mono (and maybe MonoDevelop), both to give something back to the open source project, but also to be able to improve/modify Mono in ways that are beneficial to Unity. I think it would be a win-win for both the Mono project and for Unity.

 

Hi,

I believe that "No More "Cool" Features Please Until Crippling Stuff Is Addressed" will result in fewer sales. This will hurt the further maintenance - development of the engine.
I suggest when one finds something that seems broken to report it, both in bug tracker and the forums. Until the issue is addressed, it is a good idea to try and find alternatives ( different coding techniques, 3rd patry solutions, other engines, make an engine from scratch).

 

Too much half implementend and buggy features leads to less sales too. As told, the art is to find the right balance between maintaining and staying state of the art.