Replies: 2 comments 5 replies
-
|
This highly depends on particular case and can be solved using various methods. I guess what you mean is just a resource file, right? Then why don't you just load and supply this file from within (i.e. from JS loader)? You can change your main class to be TeaVM JS module rather than standard Java entry point and you can expose two distinct methods to the outer world (one for setting PAL data, another for actual launching).
This has nothing to do with my efforts. Lack of objects as a first-class citizens in pre-GC WebAssembly did not allow to produce compact binaries, despite all possible efforts. |
Beta Was this translation helpful? Give feedback.
-
Current version:Metadata is created like that: ... and in Java accessed like that ...
Maven build currently creates: Proposal:Metadata is created like that: ... and in Java accessed like that ... Maven build could create: Glue Code (I don't know if it makes sense that way): |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
My motivation:
I create all versions like JS and WASM using TeaVM, which is a great deal.
My release version is at least about 3.5 MB big. JS and WASM_GC with nearly the same size, which is a great progress thanks to Alexey compared to the old WASM build (>7MB).
And this is not his fault but mine, that it has grown really big to include ereything.
The huge size is due to the fact, that I add 2MB precompiled PAL palette data, which in fact is only required, if video output is enabled using my emulator.
Some people using my release only want to play music without ever activating video screen output.
The Idea:
If compile time dependencies could be defined to be optional and separated from a release, gives more flexibility.
Compile time data and release version would be stored in different files.
At runtime one can decide to combine them to a full release or not by some glue code.
For the java code it would mean, that accessing that data must check the availability first.
The result would be a much smaller release for some people, around 1.5 MB max. And still 3.5 for the full functionality.
And I would provide just different file sets.
Possible problems are:
How to combine them together? Maybe optional data is always JavaScript code and can be imported and for WASM?
I really don't know yet what options we have here, therefore the discussion.
Or is it already possible?
Beta Was this translation helpful? Give feedback.
All reactions