Doing the impossible(?). Getting a Unity 2018 or 5.6 build to work in IE

Hi all. For reasons that are both complicated and very stupid, I need to be able to get a Unity project to run on Internet Explorer 11 or 10. I know this is not recommended and later versions have dropped support entirely, but I've found 5.6 and 2018 versions can still build for it...just not well. It takes a very long time to load and causes the web page to restart more than half the time.

The build in question is purely 2D, has no lights, no audio, no physics, images compressed to 256 and below, low quality settings, and basically all the other optimization tricks I could glean from these forums. So I suspect the bulk of the issue is that UnityLoader.js takes too long and is crashing the web page.

Does anyone have any advice for things I can do to optimize the UnityLoader script to make sure the program loads without causing IE to force restart the web page?

Any help/advice would be greatly appreciated as my coding skill extends only into the basics of C#. The script for the UnityLoader is far beyond my basic comprehension.

P.S.
For other stupid reasons this can only be done on my end. I need people to be able to access it but I can't tell them to download an extension, change IE base settings, etc. I don't need this to load super fast: under 30 seconds I think is acceptable.

 

It's been some time, but in the recent past my build target was also Internet Explorer.
Things that must be done (as far as I remember)
- Set the Graphics API in the build settings to WebGL 1.0
- Don't use WASM, use the asm.js
- About the Unity version, I would recommend sticking a version where you can disable the builtin packages (2018, maybe can also be done in Unity 2017, which may be better):
- Disable the built-in packages of EVERYTHING you don't use in your game. The main villains are the physics packages
- Strip Engine code must be enabled
- Use the master optmization level
- Enable Exceptions should be "Explictely Throw Excpetions Only" or "None"
- Use GZIP compression instead of Brotli compression

In the graphics part, in the Graphis Settings, you must set everything to low or off, something like this:

In the quality settings, set the default to the "Fastest", only changing texture size if you need

- Your textures must be crunch compressed, and when talking about UI assets, use a TextureAtlas
- In the Audio settings, enable the checkbox "Disable Unity Audio"
- Don't forget to set the memory use to the LOWEST POSSIBLE this is essential. You can track this in other browsers using this tool: https://github.com/kongregate/Unity-WebGL-Utilities (no idea if it still works)

You will also need to disable the warning when the game is opening, you can follow this: https://answers.unity.com/questions/1339261/unity-webgl-disable-mobile-warning.html

Also, in IE DONT EXPECT full fps. It is a lot slower than other browsers.

If I remember correctly, there was also a problem sometimes when loading the game from the Cache, which can be avoided forcing your host to always invalidate the cache
And also: it is almost impossible to use the developer console of IE when the game is running. The browser will just crash.
And the initial loading will make the browser hang a little also.

 

Appreciated. However when you say set memory usage to the lowest possible, how low are we talking? It started at 16 which i think is the lowest recommended. Also, frame rate is not really a factor. The application in question needs no fluid transitions from anything and it uses basically only 6 sprites all of which are 256x256 or lower. Also how do I disable packages? I am thankful for the help, I've had to optimize pretty heavily in my line of work before, but never figured I'd be designing for dead tech.

 

In my case, my application was running fine when setting a limit between 64mb and 96mb. But the ideal way is: use a script to log the amount of memory used in your app (like the kongregate tool above) in a another browser (chrome or firefox. Just be sure to be testing the asm.js build instead of a wasm build). Then, you need to set this like this: https://docs.unity3d.com/ScriptReference/PlayerSettings.WebGL-memorySize.html (in older Unity versions, there was a input field in the player settings where you could set this) to something close to the maximum memory logged by the script. If you start in a too low value, the memory grow will happen in much larger steps than you expect (if I am not mistaken, the memory allocation doubles when the limit is reached in asm.js builds), so it is better to preset it to the necessary memory for the gameplay as it will not need to allocate more memory during the game.
I am not sure if disabling packages was present in version 2017. But it is > Window > Package Manager > Click in the builti-in packages option > disable EVERYTHING you don't use

BUT I recommend: try building in 2017. Do another build with 2018 with the packages disabled. In both of these, set the compression to None.
Why: Check the sizes of the .code file generated in each Unity version. If the 2017 (where there isn't the Package Manager) file is lower in size than the 2018 with packages disabled, I would stick to building in 2017. That is because the IE code interpreter sucks, and the lower amount of code for him, the better.

 

Unfortunately I can't use anything other than 5.6. May main source of complication is a function in the loader script called "math.fround" which seems to be slowing everything down to the point of crashing. A guide i found online walked me through how to remove it without breaking everything buy the process was very specific. 5.6 doesn't let me disable packages. So working on other issues. Currently, I'm trying to find out how to manually compress the code.unityweb script since I had to go into it to disable math.fround. Do you know how to manually gzip something outside of Unity? Currently with math.fround disabled i can get the program to run in 30-40 seconds on ie11. Better than before but still not ideal

 

Oh yeah, the Math.fround problem. Now I remembered that it was exactly my problem too, and I did a post back then about that: https://forum.unity.com/threads/how-to-manually-optmize-math-fround-calls.498735/#post-3265338
To gzip after generating the uncompressed version, use 7zip if you are in windows.
If sticking to 5.6 just make sure to have the strip engine code disabled. And be sure to NOT have any collider (meshcollider, box, etc) in any scene.
Also, if you use Physics.Raycast code, I would recommend to change for something else. That's because the Physics code is TOO large (5-6mb when decompressed), and if there is no reference to it in the scenes or code, it will probably be stripped.

 

Oh right. I didn't realize that was you. Right, I'm following your advice about math.fround from 2017. I've been using 7zip, but it keeps returning a bug. Then again, I thought i was supposed to have strip engine code on. Will try turning it off for next build. Frustrating how many extra steps this adds to building, but I have to get this running on IE

 

Okay so removing math.fround does not seem to diminishing load times. I've tried using 7zip to gzip the code.unityweb file. When I try testing it after it being compressed, I get a syntax error at some "blob" point, which is impossible for me to decipher or change. Is there a zip setting i should be checking? These are the zip settings i am using. And yes, when i gzip it I change the file type back to unityweb and the name matches what is loaded from the .JSON

 

Sorry, it was a digitation error: strip engine code must be enabled.
Yep, Internet Explorer is a hell. Try ignoring the fround if they didn't gave you the necessary boost. Also, let me ask something: Even running Internet Explorer, the hardware of the computer is good? And also note: Internet Explorer 10 will NOT run anyway. The minimum is IE 11.
The gzip settings are in fact correct

 

My computer is adequate. I can't be sure it will be for the users though. But at this point im just testing empty scenes. I weirdly feel like I'm losing progress sometimes i get the load down to 15 seconds. Then next time it just gives me a javascript error at some blob. I'm using 2018 now since i found where the spots to change are in your last post. I'm frequently getting errors like these in IE
and I don't know how to fix them or the cause since A. I know nothing about how to change "blob" stuff and B. I am terrible at Javascript.

 

- The math.fround fix from my old post can be the cause. That was a highly experimental method (that worked for me, but I was sure that could lead to problems)
- If you have control of the server hosting the files, try to add the "content-encoding" "gzip" to your files there
(https://docs.unity3d.com/Manual/webgl-deploying.html)
- Try to notice: If the first loading seems to go faster, and reloading the page seems to make the browser stuck. This can be related to the cache problem I mentioned first. If this is the case, if you can configure the files in the server to NOT be cached, that can help (only if you notice that this behaviour of the first loading is really happening)
Sorry I cannot help much more than that. Basically make a build work in IE was in my case a lot of trial and error and unconventional fixes.

 

I've switched back and fourth from doing the fround fix. Right now just trying to get it to run without a javascript error first then trying the fround optimization. Bee deleting history in between reloads and tests to make sure it wasn't a cache thing. I haven't looked into my server hosting options though so I'll see if that can assist in any way. Currentky I'm just hosting this on a local apache server otherwise I'd be contacting the network manager at my office every ten minutes to upload something and he's pretty swamped as it is. I haven't changed any settings in there since I don't really know anything about this stuff without walking through steps like it's a shopping list. For some reason the synapses just don't fire in a way that i can remember this stuff longer than a day after i read it