you can do it with the standard editor. Just define a byte array in GUI and choose an array size of 1048576, if that fails when loading the map, reduce size by 524288 (half of 1048576), if it works, add 524288. Repeat until youve added/subtracted 1. 2095103 ((2^21)-1-2048) minus the size of the byte array at that point is about the size of all global allocations. I say about because i think allocations after the allocation of the byte array dont get factored into the calculation.
Actually, 0 is false, any other value is true.
And i suspect blizzard doesnt compile Galaxy JIT. At least not to x86 ASM. The VM most likely interprets the bytecode it compiles Galaxy into.
The tests we did focused on data limitations. I have no idea what influences code space.
But i doubt declaring natives takes up code space.
However, removing Galaxy code thats unused would free up code space.
@Mexaprone: Go
Oh, now i remember. But isnt NativeLib loaded by Core.SC2Mod? So, wouldnt removing LibertyLib only avoid loading LibertyLib, but not NativeLib, since Core still loads NativeLib? Thus, wouldnt you always have to import an empty NativeLib?
Imagine you dont use any function inside NativeLib.galaxy. Why include it in MapScript.galaxy? Now, if you think that should be enough to not load NativeLib.galaxy, youre mistaken. The only way to prevent loading content from NativeLib.galaxy is to either mess with the dependencies, which sometimes, like with the Liberty dependecy, is not such a good idea, since theres data and art that wouldnt be accessible without the dependency, or you overwrite the files with files containing what you want them to contain.
Some time ago, Mexa and I were messing a bit around with memory limitations and noticed a few things:
Every string literal (eg. "hello") allocates 4 bytes. 4 bytes that cannot be recovered. Something like someString="hello"+"hello"; allocates 8 bytes. Optimizers should help saving memory space by replacing string literals with global constants wherever sensible to do.
Native functions can be used without having to declare them.
Dependencies can force SC2 to load script files. MapScript.galaxy can be empty and NativeLib.galaxy will still be loaded. You can import empty files to replace those forcefully loaded by dependencies.
you can do it with the standard editor. Just define a byte array in GUI and choose an array size of 1048576, if that fails when loading the map, reduce size by 524288 (half of 1048576), if it works, add 524288. Repeat until youve added/subtracted 1. 2095103 ((2^21)-1-2048) minus the size of the byte array at that point is about the size of all global allocations. I say about because i think allocations after the allocation of the byte array dont get factored into the calculation.
Do a binary search using a byte array.
@Iggyhopper: Go
Actually, 0 is false, any other value is true. And i suspect blizzard doesnt compile Galaxy JIT. At least not to x86 ASM. The VM most likely interprets the bytecode it compiles Galaxy into.
The tests we did focused on data limitations. I have no idea what influences code space.
But i doubt declaring natives takes up code space. However, removing Galaxy code thats unused would free up code space.
@Mexaprone: Go Oh, now i remember. But isnt NativeLib loaded by Core.SC2Mod? So, wouldnt removing LibertyLib only avoid loading LibertyLib, but not NativeLib, since Core still loads NativeLib? Thus, wouldnt you always have to import an empty NativeLib?
Imagine you dont use any function inside NativeLib.galaxy. Why
includeit in MapScript.galaxy? Now, if you think that should be enough to not load NativeLib.galaxy, youre mistaken. The only way to prevent loading content from NativeLib.galaxy is to either mess with the dependencies, which sometimes, like with the Liberty dependecy, is not such a good idea, since theres data and art that wouldnt be accessible without the dependency, or you overwrite the files with files containing what you want them to contain.Some time ago, Mexa and I were messing a bit around with memory limitations and noticed a few things: