Unity has opened up their roadmap to make their plans for improvement transparent with a Feedback voting system for the features that matter most to us so it is every Unity developers’ duty to participate in making the Unity the engine we wish it to be.
Unity developers should not settle for putting up with problems or complaining to each other when they can instead lobby on the Unity Feedback voting system and ask about issues with the Unity reps we meet.
To that end, here are some of our community’s top feature requests including some that have been adopted to be fixed.
We encourage you to participate in the Feedback voting process:
- cast votes for these if you agree.
- comment about WHY the issue matters to you because clearly reasoned comments carry much more qualitative weight tham quantitative votes.
- Suggest things that we should vote for to us and we’ll feature them here if we agree.
Unity suggestions we’re voting for
- High DPI support on Windows (Already completed for the Mac version!)
Unity should acquire Flipbook Games’ ScriptInspector and make it the default code editor option for Unity, with Visual Studio and MonoDevelop as options in Preferences. It would make Unity easier to learn and teach, and make development faster and more consistent across Mac, Windows & Linux. It would also set Unity Labs up for VR interactive editor and runtime coding in the future.
ScriptInspector is much faster than MonoDevelop or Visual Studio and many developers have made it their primary IDE. MonoDevelop hangs or fails to start on many students’ laptops during classroom uses, and Visual Studio is powerful but a slow-launching 12GB overkill for the job of editing Unity C# files for most coding uses.
ScriptInspector works the same across Mac/Windows/Linux to make scripting tutorials more consistent than saying “Do this if you have Visual Studio, if you have MonoDevelop you’re out of luck”.
The developer is finishing implementation of debugging and refactoring features, at which point there will be few reasons to use the external editors at all.
If you watch the development thread, you’ll see the dev is constantly incorporating community feedback and improvements unlike MonoDevelop which still has hilariously broken indentation, no word wrap, and a host of other problems that have not been addressed in the infrequent updates made to it (presumably since everyone switches to Visual Studio in frustration rather than fix it.)
Here’s the description:
Si3 is an advanced IDE (a Code Editor) for scripts, shaders, and text assets, seamlessly integrated inside the Unity Editor. Si3 comes with context sensitive auto-completion for C# scripts and a rich set of additional tools, key bindings and mouse handling.
Si3 will blow your mind – it’s that fast!!!
Si3 features a custom made advanced C# parsing and code analysis engine! Thanks to its novel approach to code analysis (a hybrid of .Net’s Reflection and incremental syntactic and semantic analysis techniques) Si3 can easily outperform any other IDE (yes, including Visual Studio!)… Files open instantly! Code changes are reflected instantly in its internal data structures, in the parse tree, and in the type model with symbol tables. Changes are then instantly reflected back to all your scripts…
You will enjoy Unity as never before!
Programming in Unity now with Si3 is a very smooth, fluent, and pleasant experience. =) Programmers can finally focus on their tasks instead of waiting for (and sometimes fighting with) the external IDE’s to run, load the correct script, or jump to the correct line.
– Automatic code completions for C#, a.k.a intellisense
– Customizable code snippets
– Code generators for Unity magic methods
– Code generators for override methods
– Auto-closing braces
– Automated saving and reloading
– Quick inspection of static fields and properties
– Inspection of MonoBehaviour fields and properties
– Easily execute parameterless static methods
– Unlimited and independent undo and redo buffers per asset
– Quick call-stack navigation to Console log entries
– Code symbols and #region navigation
– Go To Definition
– Find All References with filtering
– Unity Scripting Reference
– MSDN Reference for .Net symbols
– Cursor history navigation
– Search / Quick Search / Find in Files
– Replace in Files with preview and selections
– Global Undo/Redo after Replace in Files
– Semantic and syntax highlighting
– Error highlighting
– Read/write reference highlighting
– Matching braces highlighting
– Version control (including P4Connect) integration
– Multiple handpicked fonts and color themes
– Full source code included!
Comments on the idea so far
High DPI Support on Windows 23+ votes
I use Unity on a Microsoft Surface Pro 4 which has a resolution of 2736 x 1824, and everything is soooo small. I can turn on DPI scaling, but then everything looks super pixelated. Support for high resolutions would be a good addition. I realize that support for Mac retina displays are in the works now, but support for Windows would be great too.
Unity on a 4K monitor was the reason I stuck with using it at native DPI which was hurting my eyes. I finally relented and let myself see the rest of the screen at high DPI and have to now set Unity to ignore scaling to prevent it from being blurry which is worse than being tiny.
This is a pretty serious eye strain health issue as nearly every laptop and desktop has a high DPI and in many cases 4K option. How is this not “PLANNED” yet? I thought this had been promised in 5.4.
There’s feature requests and there’s unmet roadmap expectations. This is one of those.
According to the roadmap archive, this shipped in 5.4.x:
“Retina/HDPI Support Editor
Crisp fonts and 3D views on retina displays on OS X.
Most existing editor code will just support retina without changes.”
This was already shipped on Mac OS X because of its all-Retina product line but somehow no high DPI support for Windows feature is on the roadmap and this needs to be fixed if is not already in the works and accidentally omitted. Is this quietly in Unity 5.6 or is it going to end the 5.x cycle with still no high DPI support?
Here are three support threads asking about this:
“Unity editor on high dpi display? I am looking at purchasing a laptop with a high density dpi display, does unity currently support.”
“Unity Editor looks blurry on high resolution displays appears very blurry in comparison to the text shown in the title bar and task bar of Windows. This is not.”
Here’s a Unity forum thread where it was mistakenly stated that high DPI support would arrive on all platforms universally when it actually only shipped for Mac:
“Unity unfortunately behaves the same on all platforms on high DPI displays. It’s being worked on (see ‘Editor: Retina/HDPI Support’ on https://unity3d.com/unity/roadmap) — but this issue is not specific to Linux.”
It turned out that it was only addressed for Macs and since most Unity users are on Windows the lack of support is puzzling. Nearly every Windows computer shipped this year has a high DPI display.
When can we expect to see this back on the roadmap to actually get fixed for Windows and Linux?
Unity currently builds standalone AppName.exe files with accompanying AppName_Data folders that are ugly and easily hackable.
Builds should have the option of being a single EXE that hides the Data folder’s files. This can be done already with the free version of Enigma:
You can work with them to bundle such a process as a checkbox in the Build Settings.
Unity apps work great from inside Enigma Virtual Box and they’re much cleaner to distribute and deal with.
We can hack this together with a build postprocessing plugin for the time being to show how this should work. Does anyone know how to script a tool like Enigma to do this?
Hierarchical scripting reference 2+ votes
I dont like the new scripting reference, because there is no structure in it.
The old structured reference is by far better.
The idea that all classes are found under one folder is terrible. Hope that will be changed back to original in the future. Thank you. With a structure i meant a class hierarchy, Its so much harder to spot the right classes and see whats else is there without it.
“I agree, the class hierarchy view was better.”
Features requests that are now planned
Remove global limit on shader keywords 407+ votes
There currently exists a global limit on the number of keywords that can be used in shaders (64 in unity4, 128 in unity5).
Keywords are essential to writing multipurpose shaders (ubershaders), but enforcing a global limit on the combined number of keywords across all shaders, makes them effectively useless on large projects. A limit per shader/material is fine.
It is a great feature, particularly for large projects, so it needs to scale.
Aras: Unity 5.5 increases shader keyword limit to 256, and that might be coming into 5.4.x too (pending QA testing).
Increasing it is good, and using less keywords by optimization will help, but we need a shader management view in Unity where we can see how many keywords are in use for what assets to help us prune our shader keyword usage until the limit is removed.
We will write up this proposal in more detail and suggest it there.
This issue looks like a good step in the right direction:
ImproveShader Keyword Handling 2+ votes
Shader keywords are a great way to optimize shader code. It allows to have different compiled versions of the same shader, one for each combination of the keywords exposed. This way, when the shader is executed, depending of the keywords passed to the material, the appropriate compiled code is taken.
My suggestion is to allow to expose the list of shaders with keywords (and the keywords itself) in a proper menu in the Unity Editor. The goal for this menu is to make easier enabling or disabling features globally.
For instance, if a shader has a keyword that enables a specific feature, I could just open the menu, select that shader and specify that I don’t want that feature, so at build time that keyword won’t be taken into account.
The benefit for this new menu are important:
– Provide the developer of a global, single point, to review what keywords are seen by the compiler (better control and understanding).
– Detect shaders that could be adding extra work to the compiler unnecessarily and help remove them.
– Optimise build time deactivating some shader keywords globally.
– Provide more control and freedom to the user to fix the “Too many shader keywords in the project” error.