WebGl Beta 5.3 and build process

Hey Unity -
the cleanup on your JS in 5.3 beta is nice, but has an unfortunate side effect. Your generated UnityLoader.js has hard-coded paths in it which don't work well in a build system where this ends up on S3, referenced via facebook canvas. We have to beautify your code, modify / diff it, and maintain it each time you release a beta.

Please make any references something we can predefine in the hosting html file, just like the memory.

To be specific, something like:
var Module = {
TOTAL_MEMORY: 268435456,
errorhandler: null, // arguments: err, url, line. This function must return 'true' if the error is handled, otherwise 'false'
compatibilitycheck: null,
pathToFileLoader..
pathToGameJs..
turn on/off data caching??
anything else we might want to conditionally set..
};

Thanks!

 

I support this idea 29385235%! We are in exactly the same situation.

 

Awesome.. thank you!!

 

How about MINIMUM_MEMORY in addition to TOTAL_MEMORY.

TOTAL_MEMORY is an amount developer wants to allocate. If the allocation is failed, unity decrease the amount gradually and tries again. This process ends when memory is allocated successfully of the MINIMUM_MEMORY param.

Currently, Unity try to allocate once. Developers have to set a minimum as possible. Actually, It increases a risk for abnormal game termination even the computer has a lot of available memory.

 

Is this meant to be working in the current beta (5.3.0f2)?

I see in the example index.html file, there are 3 fields, 'dataUrl', 'codeUrl' and 'memUrl', but the .js file Unity generates has the memory initializer path hardcoded to be 'outputfilename.js.mem'.

 

If my output folder is, for example, build0, then in the generated file build0.js there is a line

Code (csharp):

1. memoryInitializer = "build0.js.mem";

Even though I set the memUrl to be the correct location, when the build runs it fails because it tries to load the memory initializer from that hardcoded location.
Not only does the file not have the extension '.js.mem', the game is trying to load it from the domain root which is not where the file (or the rest of the game) is hosted.

The location is uses looks something like - "http://domainroot/build0.js.mem",

where the correct url is something like - "http://domainroot/webgl/builds/build0/build0.mem"

I managed to get around this for now by setting Module.locateFile to a method that's hardcoded to return the correct path. From what I could see, locateFile if set will override the memoryIntializer value and is not used for anything else.


The section where the memoryInitializer is set incorrectly looks like this:

Code (csharp):

1.  
2. // === Body ===
3.  
4. var ASM_CONSTS = [function($0, $1) { { Module.printErr('bad name in getProcAddress: ' + [Pointer_stringify($0), Pointer_stringify($1)]); } }];
5.  
6. function _emscripten_asm_const_2(code, a0, a1) {
7. return ASM_CONSTS[code](a0, a1) | 0;
8. }
9.  
10.  
11.  
12. STATIC_BASE = 8;
13.  
14. STATICTOP = STATIC_BASE + 1124672;
15.   /* global initializers */  __ATINIT__.push[...] //truncated for readability
16.  
17.  
18. memoryInitializer = "build0.js.mem";
19.  
20.  
21.  
22.  
23.  
24. /* no memory initializer */
25. var tempDoublePtr = Runtime.alignMemory(allocate(12, "i8", ALLOC_STATIC), 8);
26.  
27. assert(tempDoublePtr % 8 == 0);
28.  
29. function copyTempFloat(ptr) { // functions, because inlining this code increases code size too much
30.  
31.   HEAP8[tempDoublePtr] = HEAP8[ptr];
32.  
33.   HEAP8[tempDoublePtr+1] = HEAP8[ptr+1];
34.  
35.   HEAP8[tempDoublePtr+2] = HEAP8[ptr+2];
36.  
37.   HEAP8[tempDoublePtr+3] = HEAP8[ptr+3];
38.  
39. }
40.  

 

Hmm, it might be some old files hanging around that are causing our issues. Will keep looking into it.