Recent Posts

Pages: [1] 2 3 ... 10
NGUI 3 Support / One-sided UISprite functionality
« Last post by HISPID on November 20, 2017, 02:56:52 AM »
In my project i had a Find And Match (cards game) built with NGUI v 3.9.8 where i used custom shader with Cull Off option and cards were single-sided. After i updated to latest version 3.11.4(u5) all standard NGUI shaders now are Cull Off but the functionality of single-sided sprites are gone.

Sprites hierarchy:

CardContainer(Empty GameObject)
|_CardBackSide (UISprite)
|_CardFrontSide (UISprite rotated to  x:0, y:180, z:0)

The Topic: Latest Version: 3.10.2 (September 21st, 2016) says:
    - FIX: NGUI's geometry should now work with one-sided shaders.

I tried custom shaders with options Cull Back, Cull Front but without any results.

If anyone faced this problem already, please help to figure it out. Thank you! 
NGUI 3 Support / Re: Work with Text Mesh Pro?
« Last post by Darkmax on November 17, 2017, 01:11:51 PM »
Im also interestring in use text mesh pro with ngui, would some guide on how the the people are integrating it with ngui?
The particular issue that I was having was reproducible in all cases, both in editor and client (PC.)  So, I'm sorry, but I'm not sure about your issue dafunker
NGUI 3 Support / Re: [Solution] Using NGUI in linear lighting
« Last post by BORODA on November 16, 2017, 05:34:15 AM »
Sorry for digging this up, but does anyone have a solution for washed out fonts on linear color space?
I've attached a screenshot of the problem. Fonts are NGUI font, keep crisp is set to always. And yes, I've applied the modification to OnFill method.

NGUI 3 Support / Fuzzy edge after update to Unity 2017
« Last post by Charriu84 on November 16, 2017, 04:41:33 AM »

I recently updated my project from Unity 5.5.2 to Unity 2017.2. While testing I noticed that some of my sprites now have a fuzzy edge, as you can see on the attached images. But this only happens on iOS devices and unfortunatly not in the editor. I tried many things and at the moment I don't know what could cause this behaviour. So I hope somebody might know what causes this. Here is some additional context:

Because of my unity update I first tested in which Unity version this happens. Everything until 5.6.4 looks fine. It first happened in Unity 2017.1. and is persistent through all 2017 versions.

This is my scene setup. I generate my atlases during runtime. Therefore I load my atlas textures via. www.texture and www.textureNonReadable. The fuzzy white background you can see is a sprite using one of these atlases. The SpriteData is 40 in width and height. The sprite is then scaled up via transform.scale. I'm using OpenGL2. My NGUI version is 3.9.6

Looking at the problem it seems like the whole texture is moved 1 pixel horizontally and vertically. I compared the SpriteData x, y, width and height with my Unity 5.5.2 version and they are the same.
I've also checked the unity changelog, but could pinpoint anything that would cause this.
I have a similar problem in a UIScrollView populated with some draggable UIWidget (Collider, 3D).

Everything works in Editor.
Everything works on ~95% of Android Phones.

However, on ~5% (Galaxy S4 Mini by example), i have this particular flow :
- on press, drag the scroll list
- everything is moving fine
- on release, all the elements in list disappear.

I have debugged with ADB and there are some error message about raycast/collider issue.
I have tested the Unity 2017.2 p2 and Unity beta where it was supposed to fixed.. but no.

I have tried many things (Adding rigibody with kinematic, without, ...) but the issue still occurs on some Android devices.
Have you ever seen something like this ?
NGUI 3 Support / Input Caret doesn’t show when inputting from Device.
« Last post by cleancoder on November 16, 2017, 02:57:44 AM »

I have an issue with NGUI.
This issue can be found in "Example 12 - Chat Window" in NGUI’s sample. You can check this sample to understand more easily.

<Issue> Input Caret doesn’t show when inputting from Device.
When inputting in the Unity Editor, it shows normally, but when inputting from a device, Input Caret doesn’t show.
Here’s how to reproduce it: NGUI -> Examples -> Scenes -> Example 12 - Chat Window Build -> Input Caret doesn’t show when inputting from Device
You can refer to these screenshots: Screenshot_UnityEditor.png, Screenshot_Device.png

<Current development environment>
* Unity 3D engine: 5.6.3 f1
* NGUI: 3.11.1
* Test Devices: Samsung Galaxy Note 3, Samsung Galaxy Note 5, iPhone 5, iPad New 9.7

FYI, the issue also occurs in NGUI v3.11.4. Please let me know how to fix this.

NGUI 3 Support / Converting a project to Ngui
« Last post by neufoctobre on November 14, 2017, 12:18:40 PM »
Hello everybody,

I would like to convert a game template bought on asset store to Ngui because this asset will be a part of my game which is entirely made with Ngui.

So as a newbie about coding in general, I post here because I would like to know if there is any recommandation or warning by doing this. (I did it before but not sure I did this in a good way).

Thanks !
Dev Blog / Nov 11, 2017 -- How to edit UnityEngine.dll
« Last post by ArenMook on November 11, 2017, 09:41:34 AM »
I'm currently working on performance optimizations for Project 5: Sightseer, and a part of that involved editing the UnityEngine.dll to fix a nasty bug Unity introduced back in ~2014 that they seem to refuse to fix. That bug, is an absurd amount of GC allocations coming from the AttributeHelperEngine.

The bug in question is glaringly obvious to anyone even with a little proficiency in C#, and stems from the lack of caching of expensive GetAttributes calls:

Amusingly, the bug has been reported to Unity years ago, alongside the code required to fix it ( and yet -- Unity refused to do anything about it, claiming that a future redesign of the system will fix it. Well, guys -- fast forward to several years later -- the bug is still there, all the way in Unity 2017.2, and no actions have been taken to address it.

Here's the thing about closing bugs that are affecting people today hoping for a future redesign to fix it later -- until this "later" comes, the problem will still keep affecting all 4.5 million Unity developers, and it can be (and usually is) years before gets resolved! And if someone submits a bug report with actual code on how to fix it -- why not fix it? Boggles my mind...

Anyway -- this post isn't meant to be a rant about Unity's choices -- I'll do that in another one. Instead, let me explain how you -- the developer -- can fix this problem yourself, to an extent. Fortunately, this particular problem comes from the side of Unity that lives in the UnityEngine.dll file, and C# files are quite easy to modify. The first thing we need to do is make a new C# project in Visual Studio.

I was editing Unity 5.6.4f1 -- so I made the application target .NET Framework 3.5. "The Output type" needs to be a Class Library -- as we need to create a DLL with the edited functions first.

Compile this code into a DLL:
  1. using System;
  3. namespace UnityEngine
  4. {
  5.         internal class AttributeHelperEngine
  6.         {
  7.                 private static Type GetParentTypeDisallowingMultipleInclusion (Type type)
  8.                 {
  9.                         return null;
  10.                 }
  12.                 private static Type[] GetRequiredComponents (Type klass)
  13.                 {
  14.                         return null;
  15.                 }
  16.         }
  17. }
This simple DLL will not be referencing any Unity classes, so there is no need to reference the UnityEngine.dll. Compile the DLL (I targeted Release) and move it into the solution folder, or somewhere you can find it. I called mine FixUnityEngine.dll. If you choose to fix it by adding caching instead, like in the bug report's suggested fix code, you will need to reference the UnityEngine.dll. Personally, I saw no adverse effects of simply returning 'null' in Sightseer. Worked just fine.

The next step is to create a program that will replace the code in one DLL (UnityEngine.dll) with code from another (FixUnityEngine.dll). Since I no longer needed the code above, I simply commented it out, choosing to reuse the project instead of making a new one -- but if you plan on editing your replacement code you may want to create a separate VS solution.

The API that lets us devs replace C# code is part of Mono.Cecil, but interestingly enough it's actually a part of the Visual Studio installation, at least in the current version (2017). Here's all the code needed to edit the DLL:
  1. using System;
  2. using Mono.Cecil;
  4. public class Application
  5. {
  6.         static MethodDefinition Extract (AssemblyDefinition asm, string type, string func)
  7.         {
  8.                 var mod = asm.MainModule;
  9.                 if (mod == null) return null;
  11.                 var existingType = mod.GetType(type);
  12.                 if (existingType == null) return null;
  14.                 var methods = existingType.Methods;
  16.                 foreach (var method in methods)
  17.                 {
  18.                         if (method.Name == func)
  19.                         {
  20.                                 return method;
  21.                         }
  22.                 }
  23.                 return null;
  24.         }
  26.         static bool Replace (AssemblyDefinition original, AssemblyDefinition replacement, string type, string func)
  27.         {
  28.                 var method0 = Extract(original, type, func);
  29.                 var method1 = Extract(replacement, type, func);
  31.                 if (method0 != null && method1 != null)
  32.                 {
  33.                         method0.Body = method1.Body;
  34.                         Console.WriteLine("Replaced " + type + "." + func);
  35.                         return true;
  36.                 }
  38.                 Console.WriteLine("Unable to replace " + type + "." + func);
  39.                 return false;
  40.         }
  42.         static int Main (string[] args)
  43.         {
  44.                 var dll0 = "C:/Projects/FixUnityEngine/UnityEngine.dll";
  45.                 var dll1 = "C:/Projects/FixUnityEngine/FixUnityEngine.dll";
  47.                 var asm0 = AssemblyDefinition.ReadAssembly(dll0);
  48.                 var asm1 = AssemblyDefinition.ReadAssembly(dll1);
  50.                 Replace(asm0, asm1, "UnityEngine.AttributeHelperEngine", "GetParentTypeDisallowingMultipleInclusion");
  51.                 Replace(asm0, asm1, "UnityEngine.AttributeHelperEngine", "GetRequiredComponents");
  53.                 asm0.Write("C:/Projects/FixUnityEngine/UnityEngine_edited.dll");
  55.                 Console.ReadKey();
  56.                 return 0;
  57.         }
  58. }
You may notice that I'm referencing a local copy of UnityEngine.dll -- I chose to copy it to the project's folder, but you can reference it all the way in Program Files if you like. Its default location is "C:\Program Files\Unity\Editor\Data\Managed\UnityEngine.dll".

So what does the code do? It simply reads the two DLLs and replaces the body of one function with another! In the replacement DLL I kept the same namespace, class name and function names for consistency (but as far as I can tell this isn't actually necessary). In my case though, since I did, the code to perform the replacement ended up being shorter.

Once you compile and run the program, it will spit out an edited version of the DLL (UnityEngine_edited.dll). Simply close all instances of Unity and replace C:\Program Files\Unity\Editor\Data\Managed\UnityEngine.dll with this version. That's it.

Want to test the result? Here's a test program for you:
  1. using UnityEngine;
  3. public class Test : MonoBehaviour
  4. {
  5.     private void Update ()
  6.     {
  7.         var go = gameObject;
  8.         if (Input.GetKeyDown(KeyCode.Alpha1))
  9.         {
  10.             for (int i = 0; i < 1000; ++i)
  11.             {
  12.                 var t2 = go.AddComponent<Test2>();
  13.                 Destroy(t2);
  14.             }
  15.         }
  16.     }
  17. }
  1. using UnityEngine;
  3. public class Test2 : MonoBehaviour {}
The actual GC amounts and timings will vary greatly with project complexity (the more C# scripts you have, the slower the whole process becomes thanks to Unity), but this is what I was seeing before the edit and after:

There's nothing I can do about Unity calling this useless functions, and indeed in my project Unity doing so wastes 0.16 ms per call to AddComponent... but at least the 325 MB of memory allocation is gone. Yay for small victories.
Pages: [1] 2 3 ... 10