WebGl Beta 5.3 and build process

Target Platforms Web
1

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!

1 Like
2

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

3

I think this is something we can easily do. Let me see if I find time for this next week.

2 Likes
4

And it’s added and will be in a future 5.3 build!

1 Like
5

Awesome… thank you!!

6

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.

7

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’.

8

yes

we pass the memory initializer path to emscripten, and that can be configured via memUrl. What do you see hard-coded in the generated js ?

9

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

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:

// === Body ===

var ASM_CONSTS = [function($0, $1) { { Module.printErr('bad name in getProcAddress: ' + [Pointer_stringify($0), Pointer_stringify($1)]); } }];

function _emscripten_asm_const_2(code, a0, a1) {
return ASM_CONSTS[code](a0, a1) | 0;
}



STATIC_BASE = 8;

STATICTOP = STATIC_BASE + 1124672;
  /* global initializers */  __ATINIT__.push[...] //truncated for readability


memoryInitializer = "build0.js.mem";





/* no memory initializer */
var tempDoublePtr = Runtime.alignMemory(allocate(12, "i8", ALLOC_STATIC), 8);

assert(tempDoublePtr % 8 == 0);

function copyTempFloat(ptr) { // functions, because inlining this code increases code size too much

  HEAP8[tempDoublePtr] = HEAP8[ptr];

  HEAP8[tempDoublePtr+1] = HEAP8[ptr+1];

  HEAP8[tempDoublePtr+2] = HEAP8[ptr+2];

  HEAP8[tempDoublePtr+3] = HEAP8[ptr+3];

}
10

For all we know, this should be working. Could you post a link to a build where this does not work?

11

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