Missing backend implementation
xpenatan opened this issue · 7 comments
As for now, if your game works fine in GWT and not with teaVM, it may be because some backend code are not implemented yet or is not ported from GWT.
Some examples are WebApplication, WebGraphics and WebInput classes.
Solutions that requires javascript code, there is an example in WebGraphics. It uses a WebJSGraphics interface.
I might be able to help. Mostly maybe with networking and file handling (saving files).
How would I go about adding an e.g. WebNet.java class for networking? Especially, this might be a stupid question, but what's with all the src, emu, emuBk packages? Would I duplicate code there? How does this all exactly work?
Another question: how do I use classes from org.teavm.jso. I added provided "com.github.xpenatan.gdx-teavm:backend-teavm:$gdxHtmlVersion$gdxHtmlType to the build.gradle and it builds the jar files. Somehow it doesn't work otherwise though.
What's the proper way to call org.teavm.jso?
Hey, sorry for not having a proper documentation. I'll try to make one later.
The current repo state contains backend-web and backend-teavm. It had backend-dragome before but I deleted because the sdk is not maintained anymore
backend-web contains reused code that would work for any backend. If a new javascript solution comes up we don't need to rewrite everything. It acts like a generic code/interface. (I might rename to something like backend-core). When backend-web needs to call a native js code, I pass a interface to it and do the implementation in backend-teavm.
About the emulated mess:
emuBk are old files that needs to be deleted. This repo contains more than 1 solution to emulate a class, the last one I created is to use the "@emulate" annotation. With the annotation, the emulated class can be inside any package inside emu folder.
The emujava and emuorg are using teavm solution to emulate class. It uses the resources/META-INF/teavm.properties to rename emujava to java and emuorg to org (I might remove this solution and use annotation instead).
For WebNet, I think you can create WebNet in backend-web and TeaNet in backend-teavm for teavm related stuff. You can take a look at WebGraphics on how I pass the WebJSGraphics interface using TeaJSHelper.
Another question: how do I use classes from org.teavm.jso. I added provided "com.github.xpenatan.gdx-teavm:backend-teavm:$gdxHtmlVersion$gdxHtmlType to the build.gradle and it builds the jar files. Somehow it doesn't work otherwise though.
What's the proper way to call org.teavm.jso?
Your trying to use it in your project? You mean anything from this folder https://github.com/konsoletyper/teavm/tree/master/jso ?
When you add backend-teavm lib it also include the teavm-cli-0.7.0-dev-1200.jar file to your module so you can use teavm api.
Your trying to use it in your project?
TeaVM works perfectly call if I use it from my project. I meant using it in gdx-teavm/backend-web where I can't use it. That said, how you explained it makes sense.
backend-web contains reused code that would work for any backend. If a new javascript solution comes up we don't need to rewrite everything. It acts like a generic code/interface. (I might rename to something like backend-core). When backend-web needs to call a native js code, I pass a interface to it and do the implementation in backend-teavm.
For WebNet, I think you can create WebNet in backend-web and TeaNet in backend-teavm for teavm related stuff. You can take a look at WebGraphics on how I pass the WebJSGraphics interface using TeaJSHelper.
I think what you did is great, so don't take it the wrong way. Also, I submitted a PR for the file system for FileType.Local, so I'm not just randomly commenting. 😅
How it's built now, it works well, but it makes development really hard. Given the name gdx-teavm, I would not really have a separate backend-teavm, but rather put everything into backend-web (or vice-versa).
- Development is easier, I just call TeaVM where needed. No need for wrappers/helpers/etc.
- It will be easier for volunteers to contribute. It's not very clear and very cumbersome at the moment.
- It makes development of the build system/etc. easier (your part), as you can really focus on TeaVM.
- Publishing & reviewing changes will make merging easier as there are less files to look at.
- You don't need to write documentation to explain how it works.
- Would replacing
backend-teavmbe really feasible in the end? And when it comes to that, just clone the repository with the new backend?
Sure, your right. Single backend module will make it easier to call teavm directly without the need of wrappers and hacks.
Was there many issues getting age of conquest to run ? or its just the setup process that is hard ?
I'm trying to get imgui to work with emscripten+webidl and after that I'll start merging both modules.
Was there many issues getting age of conquest to run ? or its just the setup process that is hard ?
It was not that much of a problem. The PRs I sent fixed a few things. Then I had to do some minor adjustments locally. All-in-all pretty straightforward.
I'm trying to get imgui to work with emscripten+webidl and after that I'll start merging both modules.
Great! I'll probably re-do the file system using IndexedDB as it's better in the long run (large persistent storage). And then probably also the networking interface. When do you approximately think you will be done with the merge (no rush)? Maybe easier to wait as I don't have to do all the wrappers and stuff.
I'll start next week and slowly start merging files. I guess by the end of this month everything is ready.