@U02S4QZAH61 are you still working on this? I'm trying to work out if it is possible to use godot from clojure and still compile out to other targets such as web... I've got a build sort of working on macos, with some changes required to compile it. Let me know if this is of interest 😃...

Hey! I have abandoned this project and am not planning to return to it for a while. Speaking about exporting, I only tested it on Linux. If you have extra questions, I'll try to answer them. Besides, Godot 4 is here and if I remember correctly, there's a new way of integrating languages with Godot. You might want to check that out since this project is for Godot 3.*.

Ah, cool. Yea. I have no idea how complicated that is, hence being interested in the project, do you have any suggestions of stuff that I could read as to how to go about doing it? For example, try to build godot 4 and then hook into it with dtype next?

What would be a decent approach / starting point? :)...

I dug through my archives and found my notes about each file in the repo, might come handy: - =scripts/= :: helper bash scripts - =test/= :: tests - =test-resources/= :: files needed for tests; mainly scene files - =godot-headers= :: submodule; contains the C API - =src/c/= :: C source - =src/clojure= :: Clojure source * Clojure source Located at =src/clojure/godotclj/= - =api/gen_gdscript.clj= :: =api/gdscript.clj= file generator. The generated file is used to interface with godot. - =bindings/godot.clj= :: lower level helpers? Registering utilities, converters between Godot and Clojure structures. There also seems to be higher level helpers such as vector access, vector deftype. - =annotation.clj= :: It annotates but I don't know what. It seems like it could be a helper for code generation. - =api.clj= :: Higher level helper; similar to =bindings/godot.clj= but without the low level stuff - =clang.clj= :: Code generation/FFI for clang. Probably works for all sorts of C compilers, not just clang. Makes use of meander and transit which I'm not too familiar with. - =connect.clj= :: Connection functionality. My own code. - =context.clj :: 7LOC. It seems like it makes a Java class. IIRC I asked Tristan (original developer) about it and it is a class that is needed for some other place. - =core.clj= :: Entry point, the main API. Partially written by me. - =defer.clj= :: Deferring API. Written by me - =defs.clj= :: Some definitions. I believe this file is responsible for designating different kinds of bindings (functions, structs, enums) and their location. Not too long, refers to =godotclj.clang= - =gen_bindings.clj= :: Side-effecting namespace that is seemingly responsible for generating code for graalvm - =gen_directives.clj= :: 8LOC side-effecting code with only one expression (excluding ns) - =gen_wrapper.clj= :: 6LOC side-effecting code with only one expression (excluding ns) - =graalvm.clj= :: GraalVM stuff; only 2 functions - =graalvm_model.clj= :: For GraalVM; only =extend-type= expressions - =hook.clj= :: Hooking API; my code - =insn.clj= :: 14LOC; 1fn - =jna_model.clj= :: Side-effecting ns; 35LOC; only =extend-type= expressions - =loader.clj= :: Gen-class; 14LOC; I think it loads classes - =main_graalvm.clj= :: Gen-class; Exposes graalvm to =godotclj.bindings.godot= functions - =main.jvm= :: Defines some FFI libraries; loads side-effecting jna-model; probably is responsible for running JVM version of godotclj - =natives.clj= :: 11LOC; 1fn; loads native (C?) files - =godotclj.paths= :: Side-effecting ns; 7LOC; just prints - =proto.clj= :: Trivial protocol definitions; 19LOC - =registry_utils.clj= :: Tools to build registries; my code; 18LOC; 1fn - =runner.clj= :: I believe this provides some convenience in launching godotclj - =scene-processing.clj= :: Processing =tscn= files; my code - =strings.clj= :: 8LOC; 1fn; 1 string utility; file deserves to be deleted and the only function should go to util - =util.clj= :: Miscellaneous assortment of functions; my code

Would a valid starting point being just reading / writing tscn files :thinking_face:? Godot autoloads them right?

I am not sure if it's done automatically but they are needed in order to make classes, which is why they are there.

About the new stuff that Godot 4 brought -- it's called GDExtensions https://godotengine.org/article/introducing-gd-extensions/ which is successor to GDNative (that is used in this project and is meant for Godot 3.x). I haven't researched it much but it seems like it has removed some boilerplate that was in GDNative.

Also I wanted to ask, were you able to successfully export the output?

I did manage to export a game and play it on Linux if that's what you meant

Ok great, did you ever test web export?

I just wanted to make sure that I'll be able to do that at least :)... That would give me a decent level of confidence that most exporters should work :)...

Nope, only exported in Linux. My knowledge on exporting is very shakey which is also why I haven't been able to export on other platforms.

Ok, I'll have to keep an eye on that then...

I'm not sure if web export is possible since you need to get jar into web (or maybe you can run it from backend, not sure)

Keep in mind that I'm not the original author of the library and pretty much most of the knowledge comes from digging through code.

So the godot export should spit out webassembly for the web export option... The thing I need to figure out is whether coding via this approach doesn't break that...

Oh and here's https://app.gitter.im/#/room/#godotclj_community:gitter.im which has chat history between me and Tristan (the original author). This content might help you get a feeling about what I have done and what problems I encountered.

Godot for me is interesting from a multiplatform coding perspective...

Thanks!

Ok, I'm going to try and throw a quick project together and see what happens.

Hmm, there's a lot of context in this codebase I'm missing it seems 😃...

yeah, that's sadly how it is with the project