Godot 4.0 adaption (Windows + MacOS)

bitbrain commented 2 years ago

logo_large_monochrome_dark

Goal

This pull request aims to make this addon compatible with Godot 4.0+, relates to #121

Todo list

[x] make C++ code compile with new Godot 4.x headers by adjusting the syntax
[x] make gdscript Godot 4 compatible
[x] replicate signals
[x] ensure argument names are configured -> https://github.com/paddy-exe/GDExtensionSummator/issues/8
[x] configure .svg icon for FmodEventEmitter
[x] update build pipeline to build against Godot 4 (done by @2shady4u )
[x] ensure GUT works with Godot 4 -> https://github.com/bitwes/Gut/pull/378
[x] Ensure SConstruct file works correctly
[x] Successfully build .gdextension file
[x] Port demo project to Godot 4 - use the new command-line project converter for this
[x] rewrite the build and release pipelines: 4.x branch should build against Godot 4 while the main branch should build against Godot 3 https://github.com/utopia-rise/fmod-gdnative/blob/master/.github/workflows/all_builds.yml#L15
[x] port FmodEventEmitter as C++ type to be natively available within Godot
[x] remove Fmod.gd script
will be done in seperate PR: re-enable Gut as part of tests @2shady4u
will be done in seperate PR: change README.md docs to explain how to build/contribute
will be done in seperate PR: apply https://github.com/utopia-rise/fmod-gdnative/pull/136 once merged
[x] apply https://github.com/utopia-rise/fmod-gdnative/pull/137 once merged

Currently known issues

[x] 🐛 timeline beat signals do not seem to work quite @CedNaru
[x] 🐛 missing FMOD_ constants @bitbrain
[x] 🐛 iOS build does not work (@2shady4u is investigating this)

Testing

[x] test finished branch on WINDOWS (including demo project)
[x] test finished branch on MACOS (including demo project)
will be done in seperate PR: test finished branch on LINUX (including demo project)
will be done in seperate PR: test finished branch on ANDROID (including demo project)
will be done in seperate PR: test finished branch on iOS (including demo project)

Additional notes

To work on this PR update the godot-cpp submodule to latest master:

git submodule update --init --recursive

then build this project, e.g.:

# 32bit for Windows
scons target=editor platform=windows arch=x86_32 generate_bindings=yes
# 64bit for Windows
scons target=editor platform=windows arch=x86_64 generate_bindings=yes

bitbrain commented 2 years ago

@piiertho the Todo list is wildly guessed. Feel free to suggest changes in terms of what we have to do here. There also seem to be some issues with missing includes:

Spatial.hpp seems to have completely vanished in Godot 4? What else should we use here?
Transform.hpp is not a thing any longer. There is now transform2D.hpp and transform3D.hpp - by using transform3D we might not be able to be compatible for both 2D and 3D? Does this mean for Godot 4 we'd need to split the Fmod class into 2D and 3D variations?

Feel free to raise a PR against this PR (to avoid merge conflicts) to address some bits. Main objective for now is to at least make it build somehow.

piiertho commented 2 years ago

Hello @bitbrain ! Thanks for starting this big work. In Godot 4 classes have been renamed for consistency purpose. ˋTransformis nowTransform3D, but this should not change how we manage between 2D and 3D, we already have distinct methods for this. Spatialhas been renamedNode3D, for consistency withNode2D`.

Edit: maybe this would be a good idea to split 2D and 3D for fmod too, I think this can be done fast using a CRTP. What do you think about this idea @CedNaru ?

bitbrain commented 2 years ago

Both FIND_AND_CHECK and ERROR_CHECK are currently failing (these macros resolve into invalid syntax) - need to figure out what is causing it.

I also added additional TODOs. For example, the SConstruct file does not seem to work correctly with the new godot-cpp version - it simply fails to discover the includes correctly:

cl /Fosrc\godot_fmod.obj /c src\godot_fmod.cpp /TP /nologo /O2 /EHsc /DNDEBUG /MD /IC:\Users\Miguel\git\fmod-project\godot-cpp\godot-headers /IC:\Users\Miguel\git\fmod-project\godot-cpp\include /IC:\Users\Miguel\git\fmod-project\godot-cpp\include\core /IC:\Users\Miguel\git\fmod-project\godot-cpp\include\gen /IC:\Users\Miguel\git\fmod-project\libs\fmod\windows\core\inc /IC:\Users\Miguel\git\fmod-project\libs\fmod\windows\studio\inc
godot_fmod.cpp
C:\Users\Miguel\git\fmod-project\fmod-gdnative\src\godot_fmod.h(4): fatal error C1083: Cannot open include file: 'godot.hpp': No such file or directory
scons: *** [src\godot_fmod.obj] Error 2
scons: building terminated because of errors.

It doesn't seem to check for the correct godot-cpp\include\godot_cpp path where this file exists: Capture

bitbrain commented 2 years ago

It's alive! (with 10000 errors of course but still)

Capture

bitbrain commented 2 years ago

@piiertho @2shady4u apart from the issue raised above, this seems the other obvious compilation issue related to the FIND_AND_CHECK macro right now:

src\godot_fmod.cpp(1702): error C2440: '<function-style-cast>': cannot convert from 'const uint64_t' to 'godot::String'
src\godot_fmod.cpp(1702): note: No constructor could take the source type, or constructor overload resolution was ambiguous

I did some digging and it looks like for some reason it interprets the const uint64_t (which is the instanceId type) as godot::String for some reason and then basically complains that it cannot replace it at compile time.

Any suggestions highly appreciated!

bitbrain commented 2 years ago

Update: the 4.0 branch of GUT does not seem to work correctly https://github.com/bitwes/Gut/tree/4.0 so as part of this we'll also have to update that one to be compatible with the latest Godot 4 version. giphy

bitbrain commented 2 years ago

Raised https://github.com/bitwes/Gut/pull/378

bitbrain commented 2 years ago

Now we are facing a completely new beast. Most of the C++ errors within this extension are gone but now new errors appeared:

C:\Users\Miguel\git\fmod-project\godot-cpp\include\godot_cpp/core/method_bind.hpp(331): error C2512: 'godot::MethodBindT<const godot::String &,godot::Node *,const godot::Dictionary &>::MethodBindT': no appropriate default constructor available
C:\Users\Miguel\git\fmod-project\godot-cpp\include\godot_cpp/core/method_bind.hpp(331): error C2440: 'reinterpret_cast': cannot convert from 'void (__cdecl godot::Fmod::* )(uint64_t,godot::Node *)' to 'void (__cdecl godot::___UnexistingClass::* )(uint64_t,godot::Node *)'
C:\Users\Miguel\git\fmod-project\godot-cpp\include\godot_cpp/core/method_bind.hpp(331): note: Pointers to members have different representations; cannot cast between them
C:\Users\Miguel\git\fmod-project\godot-cpp\include\godot_cpp/core/class_db.hpp(192): note: see reference to function template instantiation 'godot::MethodBind *godot::create_method_bind<godot::Fmod,uint64_t,godot::Node*>(void (__cdecl godot::Fmod::* )(uint64_t,godot::Node *))' being compiled
src\godot_fmod.cpp(109): note: see reference to function template instantiation 'godot::MethodBind *godot::ClassDB::bind_method<godot::MethodDefinition,void(__cdecl godot::Fmod::* )(uint64_t,godot::Node *),>(N,M)' being compiled
        with
        [
            N=godot::MethodDefinition,
            M=void (__cdecl godot::Fmod::* )(uint64_t,godot::Node *)
        ]
C:\Users\Miguel\git\fmod-project\godot-cpp\include\godot_cpp/core/method_bind.hpp(331): error C2512: 'godot::MethodBindT<uint64_t,godot::Node *>::MethodBindT': no appropriate default constructor available
C:\Users\Miguel\git\fmod-project\godot-cpp\include\godot_cpp/core/method_bind.hpp(490): error C2440: 'reinterpret_cast': cannot convert from 'R (__cdecl godot::Fmod::* )(uint64_t)' to 'R (__cdecl godot::___UnexistingClass::* )(uint64_t)'
        with
        [
            R=godot::Node *
        ]
C:\Users\Miguel\git\fmod-project\godot-cpp\include\godot_cpp/core/method_bind.hpp(490): note: Pointers to members have different representations; cannot cast between them
C:\Users\Miguel\git\fmod-project\godot-cpp\include\godot_cpp/core/class_db.hpp(192): note: see reference to function template instantiation 'godot::MethodBind *godot::create_method_bind<godot::Fmod,godot::Node*,uint64_t>(R (__cdecl godot::Fmod::* )(uint64_t))' being compiled
        with
        [
            R=godot::Node *
        ]
src\godot_fmod.cpp(111): note: see reference to function template instantiation 'godot::MethodBind *godot::ClassDB::bind_method<godot::MethodDefinition,godot::Node*(__cdecl godot::Fmod::* )(uint64_t),>(N,M)' being compiled
        with
        [
            N=godot::MethodDefinition,
            M=godot::Node *(__cdecl godot::Fmod::* )(uint64_t)
        ]
C:\Users\Miguel\git\fmod-project\godot-cpp\include\godot_cpp/core/method_bind.hpp(490): error C2512: 'godot::MethodBindTR<R,uint64_t>::MethodBindTR': no appropriate default constructor available
        with
        [
            R=godot::Node *
        ]
C:\Users\Miguel\git\fmod-project\godot-cpp\include\godot_cpp/core/method_bind.hpp(490): fatal error C1003: error count exceeds 100; stopping compilation

There are A LOT of those and I do not know yet what is causing this. It looks like some of the type conversion between the godot::Fmod and the way we bind methods does not really work at the moment.

EDIT I think the issue is that I need to specify the arguments explicitly when binding methods. EDIT2 nope. That did not help. EDIT3 asked around on Discord and got some advice:

You have many functions with Node parameters, you need to change them to Object and use Object::cast_to to cast them into Nodes. In the SConstruct file, change C++ support from 14 to 17. Other errors after that should be easy to fix yourself

EDIT4 that did not work lol EDIT5 another suggestion:

you need to add env.Append(CPPDEFINES=["TYPED_METHOD_BIND"]) to your windows sconstruct, see this pr: https://github.com/godotengine/godot-cpp/pull/649

EDIT6 it works! 🎉

bitbrain commented 2 years ago

Made some more progress! Now it seems to be stuck at the linker stage: https://gist.github.com/bitbrain/6ffac642e8b20e4ea19dfdc136f660aa (64bit)

These initial linker errors are odd, as well:

scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
link /nologo /WX /dll /out:bin\libGodotFmod.windows.release.64.dll /implib:bin\libGodotFmod.windows.release.64.lib /LIBPATH:C:\Users\Miguel\git\fmod-project\godot-cpp\bin /LIBPATH:C:\Users\Miguel\git\fmod-project\libs\fmod\windows\core\lib\x64 /LIBPATH:C:\Users\Miguel\git\fmod-project\libs\fmod\windows\studio\lib\x64 libgodot-cpp.windows.release.64.lib fmod_vc.lib fmodstudio_vc.lib src\godot_fmod.obj src\register_types.obj src\callback\event_callbacks.obj src\callback\file_callbacks.obj
libgodot-cpp.windows.release.64.lib(Variant.obj) : error LNK2005: "public: __cdecl godot::Variant::Variant(int)" (??0Variant@godot@@QEAA@H@Z) already defined in godot_fmod.obj
libgodot-cpp.windows.release.64.lib(Variant.obj) : error LNK2005: "public: __cdecl godot::Variant::Variant(unsigned int)" (??0Variant@godot@@QEAA@I@Z) already defined in godot_fmod.obj
libgodot-cpp.windows.release.64.lib(Variant.obj) : error LNK2005: "public: __cdecl godot::Variant::Variant(float)" (??0Variant@godot@@QEAA@M@Z) already defined in godot_fmod.obj
libgodot-cpp.windows.release.64.lib(Variant.obj) : error LNK2005: "public: __cdecl godot::Variant::Variant(unsigned __int64)" (??0Variant@godot@@QEAA@_K@Z) already defined in godot_fmod.obj

perhaps we are partially compiling godot-cpp as part of our usual build (I changed some of the scons file) causes this to happen? Still very odd.

@2shady4u @piiertho Any ideas or suggestions welcome!

bitbrain commented 2 years ago

Also, perhaps we want to update our SConstruct file and simplify it like this: https://github.com/nathanfranke/gdextension/blob/main/SConstruct (with additional FMOD dependency setup)

We could also add godot_cpp as a git sub module as shown in that template project?

CedNaru commented 2 years ago

I like the idea. It seems it makes the project scons much more simpler by copying the environnement of the Godot CPP so we only need to add the extra sources.

piiertho commented 2 years ago

Also, perhaps we want to update our SConstruct file and simplify it like this: https://github.com/nathanfranke/gdextension/blob/main/SConstruct (with additional FMOD dependency setup)

We could also add godot_cpp as a git sub module as shown in that template project?

I love the idea to be able to extends godot-cpp's scons.

piiertho commented 2 years ago

Made some more progress! Now it seems to be stuck at the linker stage: https://gist.github.com/bitbrain/6ffac642e8b20e4ea19dfdc136f660aa (64bit)

These initial linker errors are odd, as well:

scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
link /nologo /WX /dll /out:bin\libGodotFmod.windows.release.64.dll /implib:bin\libGodotFmod.windows.release.64.lib /LIBPATH:C:\Users\Miguel\git\fmod-project\godot-cpp\bin /LIBPATH:C:\Users\Miguel\git\fmod-project\libs\fmod\windows\core\lib\x64 /LIBPATH:C:\Users\Miguel\git\fmod-project\libs\fmod\windows\studio\lib\x64 libgodot-cpp.windows.release.64.lib fmod_vc.lib fmodstudio_vc.lib src\godot_fmod.obj src\register_types.obj src\callback\event_callbacks.obj src\callback\file_callbacks.obj
libgodot-cpp.windows.release.64.lib(Variant.obj) : error LNK2005: "public: __cdecl godot::Variant::Variant(int)" (??0Variant@godot@@QEAA@H@Z) already defined in godot_fmod.obj
libgodot-cpp.windows.release.64.lib(Variant.obj) : error LNK2005: "public: __cdecl godot::Variant::Variant(unsigned int)" (??0Variant@godot@@QEAA@I@Z) already defined in godot_fmod.obj
libgodot-cpp.windows.release.64.lib(Variant.obj) : error LNK2005: "public: __cdecl godot::Variant::Variant(float)" (??0Variant@godot@@QEAA@M@Z) already defined in godot_fmod.obj
libgodot-cpp.windows.release.64.lib(Variant.obj) : error LNK2005: "public: __cdecl godot::Variant::Variant(unsigned __int64)" (??0Variant@godot@@QEAA@_K@Z) already defined in godot_fmod.obj

perhaps we are partially compiling godot-cpp as part of our usual build (I changed some of the scons file) causes this to happen? Still very odd.

@2shady4u @piiertho Any ideas or suggestions welcome!

This can cause it indeed.
It's like cpp code from godot-cpp has been added godot_fmod.obj

2shady4u commented 2 years ago

@piiertho yeah, i was working on this in the godot-4.0-adaption-actions branch (= the simplification of the SConstruct file)

bitbrain commented 2 years ago

@2shady4u @piiertho I am currently drastically simplifying the Scons file by directly basing it on the godot_cpp Scons. Firstly, I made godot_cpp an actual git submodule. If this is something you strongly disagree with, it can be reverted, however, a lot of already existing GDExtension projects do that, too.

While doing that I also noticed that some of the linker issues can be explained because in Godot 4 there is no concept of "bits" any longer but instead, the godot_cpp Scons exposes a env["arch_suffix"] which can have all sorts of values that should be used instead:

"universal", "x86_32", "x86_64", "arm32", "arm64", "rv64", "ppc32", "ppc64", "wasm32"

I am adjusting our Scons to support this (custom mappings for FMOD lib dirs are required since those usually are simply x86or x64).

programmer-programming

EDIT @2shady4u I now updated the SConstruct file: https://github.com/utopia-rise/fmod-gdnative/pull/123/commits/aca811b57d6455a413f22eda870ca13deb346570 but still get some linker errors (9 instead of 70+ which is a good sign?). I suspect this is due to me incorrectly composing the new SConstruct file.

CedNaru commented 2 years ago

I'm not against the Godot CPP as sub module. The current design (having the godot CPP in the parent folder) was made in order to have a single godot CPP used by different GDNative projects so we don't need one copy for each. It makes it easier for local development when you are working on different plugins but it makes it harder for maintainability in the github repo itself as it's not self contained. But as long as we still have the option the set a different path for the godot cpp in the scons arguments (default to the submodule one, fallback to parent folder) I'm fine with the change. That way we can still use the old approach with a parent godot cpp and not using the git recursive option.

bitbrain commented 2 years ago

@2shady4u I used your SConstruct file as a base and was able to get it building :)

Capture

bitbrain commented 2 years ago

Made some significant progress of getting the gdextension running within Godot 4. A couple of caveats:

the .gdextension file now correctly points to the Windows dll paths
when building the project currently it still puts it into a /bin folder @2shady4u perhaps we might want to place it into the addons/fmod/libs/platform/arch folder instead
there is currently an issue building the 32bit version for Windows (see error below)

> scons target=release platform=windows arch=x86_32

results in:

...
godot_fmod.windows.release.x86_32.obj : error LNK2019: unresolved external symbol "public: enum FMOD_RESULT __cdecl FMOD::Studio::Bank::getEventList(class FMOD::Studio::EventDescription * *,int,int *)const " (?getEventList@Bank@Studio@FMOD@@QEBA?AW4FMOD_RESULT@@PEAPEAVEventDescription@23@HPEAH@Z) referenced in function "private: void __cdecl godot::Fmod::_load_all_event_descriptions(class FMOD::Studio::Bank *)" (?_load_all_event_descriptions@Fmod@godot@@AEAAXPEAVBank@Studio@FMOD@@@Z)
godot_fmod.windows.release.x86_32.obj : error LNK2019: unresolved external symbol "public: enum FMOD_RESULT __cdecl FMOD::Studio::Bank::getBusCount(int *)const " (?getBusCount@Bank@Studio@FMOD@@QEBA?AW4FMOD_RESULT@@PEAH@Z) referenced in function "public: int __cdecl godot::Fmod::get_bank_bus_count(class godot::String const &)" (?get_bank_bus_count@Fmod@godot@@QEAAHAEBVString@2@@Z)       
godot_fmod.windows.release.x86_32.obj : error LNK2019: unresolved external symbol "public: enum FMOD_RESULT __cdecl FMOD::Studio::Bank::getBusList(class FMOD::Studio::Bus * *,int,int *)const " (?getBusList@Bank@Studio@FMOD@@QEBA?AW4FMOD_RESULT@@PEAPEAVBus@23@HPEAH@Z) referenced in function "private: void __cdecl godot::Fmod::_load_all_buses(class FMOD::Studio::Bank *)" (?_load_all_buses@Fmod@godot@@AEAAXPEAVBank@Studio@FMOD@@@Z)
godot_fmod.windows.release.x86_32.obj : error LNK2019: unresolved external symbol "public: enum FMOD_RESULT __cdecl FMOD::Studio::Bank::getVCACount(int *)const " (?getVCACount@Bank@Studio@FMOD@@QEBA?AW4FMOD_RESULT@@PEAH@Z) referenced in function "public: int __cdecl godot::Fmod::get_bank_vca_count(class godot::String const &)" (?get_bank_vca_count@Fmod@godot@@QEAAHAEBVString@2@@Z)       
godot_fmod.windows.release.x86_32.obj : error LNK2019: unresolved external symbol "public: enum FMOD_RESULT __cdecl FMOD::Studio::Bank::getVCAList(class FMOD::Studio::VCA * *,int,int *)const " (?getVCAList@Bank@Studio@FMOD@@QEBA?AW4FMOD_RESULT@@PEAPEAVVCA@23@HPEAH@Z) referenced in function "private: void __cdecl godot::Fmod::_load_all_vca(class FMOD::Studio::Bank *)" (?_load_all_vca@Fmod@godot@@AEAAXPEAVBank@Studio@FMOD@@@Z)
event_callbacks.windows.release.x86_32.obj : error LNK2019: unresolved external symbol "public: enum FMOD_RESULT __cdecl FMOD::Sound::getName(char *,int)" (?getName@Sound@FMOD@@QEAA?AW4FMOD_RESULT@@PEADH@Z) referenced in function "enum FMOD_RESULT __cdecl Callbacks::eventCallback(unsigned int,struct FMOD_STUDIO_EVENTINSTANCE *,void *)" (?eventCallback@Callbacks@@YA?AW4FMOD_RESULT@@IPEAUFMOD_STUDIO_EVENTINSTANCE@@PEAX@Z)

C:\Users\Miguel\git\fmod-project\libs\fmod\windows\core\lib\x86\fmod_vc.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
LINK : error LNK1218: warning treated as error; no output file generated
scons: *** [demo\addons\fmod\bin\libGodotFmod.windows.release.x86_32.dll] Error 4272
scons: building terminated because of errors.

I am wondering why it raises that linker warning. Yes, I am running on a 64bit Windows machine but I told it to compile for 32bit specifically.

EDIT this issue was caused by me using the wrong fmod DLLs (64bit instead of 32bit)

bitbrain commented 2 years ago

I am actually able to load the GDExtension now within Godot! The next challenge is to solve the "Fmod Singleton" situation within the GDExtension.

Currently getting some nasty crash when trying to open up Godot. Looks like something about the singleton registration it doesn't quite like:

Godot Engine v4.0.alpha.custom_build.22bb15cde - https://godotengine.org
Vulkan API 1.2.0 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1080

Editing project: C:/Users/Miguel/git/fmod-project/fmod-gdnative/demo

ERROR: Method definition has more arguments than the actual method.
   at: godot::ClassDB::bind_methodfi (godot-cpp\src\core\class_db.cpp:158)
ERROR: Method definition has more arguments than the actual method.
   at: godot::ClassDB::bind_methodfi (godot-cpp\src\core\class_db.cpp:158)
ERROR: Failed to retrieve non-existent singleton 'Engine'.
   at: (core\config\engine.cpp:248)
ERROR: Condition "singleton_obj == nullptr" is true. Returning: nullptr
   at: godot::Engine::get_singleton (godot-cpp\gen\src\classes\engine.cpp:48)

================================================================
CrashHandlerException: Program crashed
Engine version: Godot Engine v4.0.alpha.custom_build (22bb15cde52b2b0623907c889be2c71227d0258e)
Dumping the backtrace. Please include this when reporting the bug on: https://github.com/godotengine/godot/issues

 ~/git/fmod-project/fmod-gdnative (godot-4.0-adaption)
 > [0] godot::Engine::register_singleton (C:\Users\Miguel\git\fmod-project\fmod-gdnative\godot-cpp\gen\src\classes\engine.cpp:209)
[1] godot::Engine::register_singleton (C:\Users\Miguel\git\fmod-project\fmod-gdnative\godot-cpp\gen\src\classes\engine.cpp:209)   
[2] initialize_fmod_module (C:\Users\Miguel\git\fmod-project\fmod-gdnative\src\register_types.cpp:22)
[3] godot::GDExtensionBinding::initialize_level (C:\Users\Miguel\git\fmod-project\fmod-gdnative\godot-cpp\src\godot.cpp:77)       
[4] NativeExtension::initialize_library (C:\Users\Miguel\Documents\godot\core\extension\native_extension.cpp:316)
[5] NativeExtensionManager::initialize_extensions (C:\Users\Miguel\Documents\godot\core\extension\native_extension_manager.cpp:102)
[6] register_core_extensions (C:\Users\Miguel\Documents\godot\core\register_core_types.cpp:342)
[7] Main::setup (C:\Users\Miguel\Documents\godot\main\main.cpp:1272)
[8] widechar_main (C:\Users\Miguel\Documents\godot\platform\windows\godot_windows.cpp:162)
[9] _main (C:\Users\Miguel\Documents\godot\platform\windows\godot_windows.cpp:201)
[10] main (C:\Users\Miguel\Documents\godot\platform\windows\godot_windows.cpp:215)
[11] WinMain (C:\Users\Miguel\Documents\godot\platform\windows\godot_windows.cpp:229)
[12] __scrt_common_main_seh (D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
[13] BaseThreadInitThunk
-- END OF BACKTRACE --
================================================================

bitbrain commented 2 years ago

Fmod Singleton now works within Godot Engine 4!

Capture

I'll still have to fix some outstanding errors in gdscript as part of the demo project but the .gdextension loads correctly, including FMOD!

CedNaru commented 2 years ago

Good job.

Glad to see native code being visible from the editor directly. The reason I had to create a whole GDScript wrapper previously was to force a singleton (now fixed as we can register them) and because doc and autocompletion was not working well with GDNative. In your screenshot, I'm noticing that all parameters are unnamed, is there some option in GodotCPP to fix that ?

bitbrain commented 2 years ago

@CedNaru yeah! I added a TODO. Basically, we have to add an XML file containing documentation + arg names because godot_cpp will not generate them on its own when building with target=release but only with target=debug according to Yuri: https://twitter.com/YuriSizov/status/1558570787900104711?t=yRKkQlehBMn-SovX9GbfdA&s=19

2shady4u commented 2 years ago

Most Github Actions have now been ported for GDExtension, thus checks are (mostly) working again!

Some missing things & bugs:

iOS compilation still crashes due to some incompatibility of the FMOD libraries with the arm64 architecture. @piiertho knows more about MacOS (and iOS as a consequence?) so maybe he has some clue why it is crashing...
The automatic GUT check and the release job haven't been ported yet, but I'll get to it eventually!

bitbrain commented 2 years ago

@2shady4u one thing we might want to consider doing is when building: to export the dynamic libraries into the respective folders listed here: https://github.com/utopia-rise/fmod-gdnative/blob/godot-4.0-adaption/demo/addons/fmod/fmod.gdextension#L5 (the paths for non-Windows are not updated yet)

as currently, I think everything is just exported into a lib folder. This becomes especially mandatory to differentiate between 32bit and 64bit FMOD dependencies (as they need to sit in the same directory as the libFmod.

2shady4u commented 2 years ago

@2shady4u one thing we might want to consider doing is when building: to export the dynamic libraries into the respective folders listed here: https://github.com/utopia-rise/fmod-gdnative/blob/godot-4.0-adaption/demo/addons/fmod/fmod.gdextension#L5 (the paths for non-Windows are not updated yet)

as currently, I think everything is just exported into a lib folder. This becomes especially mandatory to differentiate between 32bit and 64bit FMOD dependencies (as they need to sit in the same directory as the libFmod.

In a similar vein: Do we need to supply both DEBUG and RELEASE binaries for the plugin? (As there's now an entry for both debug and release in the .gdextension-file)

Also with the new FmodEventEmitter2D, shouldn't you hook up the NOTIFICATION_PAUSED and NOTIFICATION_UNPAUSED notifications so that the node pauses correctly?

bitbrain commented 2 years ago

In a similar vein: Do we need to supply both DEBUG and RELEASE binaries for the plugin? (As there's now an entry for both debug and release in the .gdextension-file)

Good question! I'd say let's only use release then!

Also with the new FmodEventEmitter2D, shouldn't you hook up the NOTIFICATION_PAUSED and NOTIFICATION_UNPAUSED notifications so that the node pauses correctly?

Oops! Let me do that.

We also currently get this error with FmodEventEmitter2D:

ERROR: Can't open dynamic library: C:/Users/Miguel/git/fmod-project/fmod-gdnative/demo/addons/fmod/libs/windows/x64/libGodotFmod.windows.debug.x86_64.dll, error: Error 1114: A dynamic link library (DLL) initialization routine failed.

No idea yet what is causing this!

piiertho commented 2 years ago

IOS is failing because of a linked error:

Undefined symbols for architecture arm64:
928
  "_AVAudioSessionCategoryPlayAndRecord"

My guess is that a lib path is not set correctly in link options.

piiertho commented 2 years ago

@2shady4u one thing we might want to consider doing is when building: to export the dynamic libraries into the respective folders listed here: https://github.com/utopia-rise/fmod-gdnative/blob/godot-4.0-adaption/demo/addons/fmod/fmod.gdextension#L5 (the paths for non-Windows are not updated yet)

as currently, I think everything is just exported into a lib folder. This becomes especially mandatory to differentiate between 32bit and 64bit FMOD dependencies (as they need to sit in the same directory as the libFmod.

In a similar vein: Do we need to supply both DEBUG and RELEASE binaries for the plugin? (As there's now an entry for both debug and release in the .gdextension-file)

Also with the new FmodEventEmitter2D, shouldn't you hook up the NOTIFICATION_PAUSED and NOTIFICATION_UNPAUSED notifications so that the node pauses correctly?

I think we should provide both debug and release, so that correct library is included in debug exports of games.

2shady4u commented 2 years ago

IOS is failing because of a linked error:
Undefined symbols for architecture arm64:
928
  "_AVAudioSessionCategoryPlayAndRecord"
My guess is that a lib path is not set correctly in link options.

All library paths seem to be correctly set imo 🤔 The exact same library path were used in the 3.X version of this plugin and there wasn't any issue there.

bitbrain commented 2 years ago

@2shady4u I am not an SConstruct expert - how do I adjust it so we can avoid having to use <godot_cpp/... in our includes?

bitbrain commented 2 years ago

ERROR: Can't open dynamic library: C:/Users/Miguel/git/fmod-project/fmod-gdnative/demo/addons/fmod/libs/windows/x64/libGodotFmod.windows.debug.x86_64.dll, error: Error 1114: A dynamic link library (DLL) initialization routine failed.

No idea what is causing this still. It started happening after adding FmodEventEmitter2D - I do not see anything wrong with that class and its registration... perhaps I am missing something here.

bitbrain commented 2 years ago

Looks like GDExtension did not actually support _notification until now: https://github.com/godotengine/godot-cpp/commit/270ad28931e57b7babdd7316c9b3d66b6f6a9e58! Time to re-test this.

bitbrain commented 2 years ago

When trying to start the demo project it now hangs for some reason and there seems to be an issue especially with the set_sound_3d_settings method:

Godot Engine v4.0.alpha.custom_build.ca5c3d6df - https://godotengine.org
Vulkan API 1.2.0 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1080

FMOD Sound System: Successfully initialized
FMOD Sound System: Live update enabled!
Custom File System enabled.
ERROR: FMOD Sound System: Failed to set 3D settings :|void __cdecl godot::Fmod::set_sound_3d_settings(float,float,float)src\godot_fmod.cpp1531

bitbrain commented 2 years ago

Someone discovered a workaround to specify custom icons for GDExtension nodes.

I will try this on the weekend: https://github.com/godotengine/godot-cpp/issues/863#issuecomment-1255159977

bitbrain commented 1 year ago

Tested this on both Windows and MacOS without issues (apart from the signal issue @CedNaru is looking into)

utopia-rise / fmod-gdextension