Giter Club home page Giter Club logo

godot-headers's Introduction

godot-headers

This repository contains C headers for Godot Engine's GDNative API, which can be used to write NativeScripts.

GDNative enables the use of dynamically linked libraries inside of Godot.

NativeScript uses GDNative to implement scripts backed by native code.

Versioning

This repositories follows the same branch versioning as the main Godot Engine repository:

  • master tracks the current development branch. As this is a moving target, the headers in this repository may not always be fully in sync with upstream. See Updating Headers if you need to bring them up to date.
  • 3.x tracks the development of the next 3.x minor release. Like master, it might not always be fully up-to-date with upstream.
  • Other versioned branches (e.g. 3.3, 3.2) track the latest stable release in the corresponding branch.

Stable releases are also tagged on this repository: Tags.

For any project built against a stable release of Godot, we recommend using this repository as a Git submodule, checking out the specific tag matching your Godot version.

Getting Started

Build latest version of Godot GitHub Docs

Clone godot-headers into Library

Clone godot-headers under SimpleLibrary/

cd SimpleLibrary
git clone https://github.com/godotengine/godot-headers

Note that the master branch of this repository contains the headers for the latest Godot master branch. See Versioning for details. You can use -b <version> to the above Git clone command to retrieve a specific branch or tag (e.g. -b 3.x or -b godot-3.3.3-stable).

[SimpleLibrary]
  ├── lib/
  └── src/

Create Script

Create test.c under SimpleLibrary/src/.

#include <gdnative/gdnative.h>
#include <nativescript/godot_nativescript.h>

#include <stdio.h>

void *test_constructor(godot_object *obj, void *method_data) {
	printf("test.constructor()\n");
	return 0;
}

void test_destructor(godot_object *obj, void *method_data, void *user_data) {
	printf("test.destructor()\n");
}

/** func _ready() **/
godot_variant test_ready(godot_object *obj, void *method_data, void *user_data, int num_args, godot_variant **args) {
	godot_variant ret;
	godot_variant_new_nil(&ret);

	printf("_ready()\n");

	return ret;
}

/** Library entry point **/
void GDN_EXPORT godot_gdnative_init(godot_gdnative_init_options *o) {
}

/** Library de-initialization **/
void GDN_EXPORT godot_gdnative_terminate(godot_gdnative_terminate_options *o) {
}

/** Script entry (Registering all the classes and stuff) **/
void GDN_EXPORT godot_nativescript_init(void *desc) {
	printf("nativescript init\n");

	godot_instance_create_func create_func = {
		.create_func = &test_constructor,
		.method_data = 0,
		.free_func   = 0
	};

	godot_instance_destroy_func destroy_func = {
		.destroy_func = &test_destructor,
		.method_data  = 0,
		.free_func    = 0
	};

	godot_nativescript_register_class(desc, "SimpleClass", "Node", create_func, destroy_func);

	{
		godot_instance_method method = {
			.method = &test_ready,
			.method_data = 0,
			.free_func = 0
		};

		godot_method_attributes attr = {
			.rpc_type = GODOT_METHOD_RPC_MODE_DISABLED
		};

		godot_nativescript_register_method(desc, "SimpleClass", "_ready", attr, method);
	}
}

godot_variant GDN_EXPORT some_test_procedure(void *data, godot_array *args) {
	godot_variant ret;
	godot_variant_new_int(&ret, 42);

	godot_string s;
	godot_string_new_with_wide_string(&s, L"Hello World", 11);
	godot_print(&s);

	godot_string_destroy(&s);

	return ret;
}

Expand Details for example code.

Compile Library

On Linux:

clang -g -fPIC -c src/test.c -I/path/to/godot/headers/ -o src/test.os
clang -g -shared src/test.os -o lib/test.so

On MacOS:

clang -g -fPIC -c src/test.c -I/path/to/godot/headers/ -o src/test.os
clang -g -shared -framework Cocoa -Wl,-undefined,dynamic_lookup src/test.os -o lib/test.dylib
  • -g is for debugging information.
  • Use godot_nativescript_* methods only in the nativescript_init() function.

Create GDNativeLibrary Resource

The GDNativeLibrary resource contains links to the libraries for each platform.

  1. Create a new resource in memory and edit it.
  2. Select Resource > GDNativeLibrary.
  3. Set the library file for your platform inside the inspector.
  4. Save the edited resource as a .tres

Note: Remember to save GDNativeLibrary as .gdnlib

Expand Details for screenshots.

Using GDNativeLibrary in GDScript

extends Node

func _ready():
	var gdn = GDNative.new()
	gdn.library = load("res://lib/libtest.tres")

	gdn.initialize()

	var res = gdn.call_native("standard_varcall", "some_test_procedure", [])

	print("result: ", res)

	gdn.terminate()

Attaching GDNativeLibrary to a Node

  1. Attach a new script to a node.
  2. In the pop-up dialog, choose NativeScript in the Language menu.
  3. Enable built-in script, or create a .gdn file, which only contains a name.
  4. Specify the Class Name.
  5. Press Create.

The GDNativeLibrary field in a NativeScript is empty by default.

Expand Details for screenshots.

FAQ

What is the difference between GDNative and NativeScript?

GDNative is a new class that can call native functions in libraries. GDScript / VisualScript / C#, etc, are able to use this class.

Godot treats NativeScript as a scripting language, enabling the use of GDNative to implement scripts backed by native code.

Which languages are binding as a NativeScript?

C++, D, Nim

Can you debug NativeScripts?

You must compile the library with debug symbols, and then you can use your debugger as usual.

Can you use one GDNativeLibrary for all NativeScripts?

You can! ✨

What is the reason behind the name "GDNative"?

GDNative was originally named "cscript" because it exposes a C API, but people mistook a relation to C#, which is sometimes abbreviated as "cs". Then named "DLScript", but that brought up some confusion, so we settled with GDNative. 📖

Updating Headers

See Versioning for details on the Godot versions tracked by each branch of this repository.

If the relevant branch is not up-to-date for your needs, or if you want to sync the headers with your own modified version of Godot, here is the update procedure used to sync this repository with upstream releases:

  • Compile Godot Engine at the specific version/commit which you are using.
  • Use the compiled executable to generate the api.json file with: godot --gdnative-generate-json-api api.json
  • Copy the file modules/gdnative/gdnative_api.json to this repository.
  • Copy the files and folders from modules/gdnative/include to this repository, overwriting existing content. (To be sure to be in sync, you can delete the folders of this repository first, then copy the upstream folders in place.) Make sure that you compiled the correct Godot version so that the generated gdnative_api_struct.gen.h is up-to-date.

godot-headers's People

Contributors

akien-mga avatar bastiaanolij avatar calinou avatar dsnopek avatar karroffel avatar khairul169 avatar l-as avatar lupodharkael avatar marcelofg55 avatar rameshravone avatar vnen avatar vonagam avatar wg-romank avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

godot-headers's Issues

Clarify status of this repo with respect to Godot 4

It's unclear to me what the status of this repository is with respect to Godot 4 and the new GDExtension API. This readme and godot-cpp's readme have similar Versioning notes at the top, saying that master is being kept in line with Godot's master and that branches exist for 3.x stable releases. However, whereas godot-cpp has clearly been updated for GDExtension, as far as I can tell this repo has no GDExtension support, even on master. The header is still called gdnative_interface.h, and it's missing several newer interface functions, which causes the whole header to be out of sync with Godot master.

If this repo is only intended for use with Godot 3 and GDNative, then that should be made clear in the readme. If this repo is going to be updated to GDExtension and has not yet, then that should also be made clear (and a link to the place in the Godot repo where gdextension_interface.h can be found in the meantime might be useful as well).

godot_net.h includes reference types

I believe the header files are meant to be C-compatible, but godot_net.h includes reference types (for example int &r_received on line 54).

Means I can not compile C code using GDNative if I want to #include "net/godot_net.h"

Create branches for Godot versions

I suggest we start creating branches to support different versions of Godot.
Say the current master is branched as "3.0.4" and master is brought up to the current 3.1 master.
That way we can keep master up to date with any changes applied to the Godot master repo.
If 3.0.5 or later get any changes to the header we can simply branch the 3.0.4 branch. Obviously we should only create branches for official godot release that actually have changes in the headers.

Especially for those of us who use submodule this works brilliantly because the repos are linked to specific commits so you can keep branches of GDNative modules for 3.0.x linked to the 3.0.x branch and the latest version linked to whatever commit on master that relates to your godot build.

I also suggest doing the same with godot-cpp

mac support

Is this functionality supported on Mac OS? I've run the README test.c example, after changing:

#include <godot/gdnative.h>
#include <godot_nativescript.h>

to

#include <gdnative/gdnative.h>
#include <nativescript/godot_nativescript.h>

as it seems the header files have been moved.

If I run the compilation commands I get:

macbook-pro:simplelibrary pietro$ clang -g -fPIC -std=c99 -c src/test.c -Igodot_headers -o src/test.os
macbook-pro:simplelibrary pietro$ clang -g -shared src/test.os
Undefined symbols for architecture x86_64:
  "_godot_nativescript_register_class", referenced from:
      _godot_nativescript_init in test.os
  "_godot_nativescript_register_method", referenced from:
      _godot_nativescript_init in test.os
  "_godot_print", referenced from:
      _some_test_procedure in test.os
  "_godot_string_destroy", referenced from:
      _some_test_procedure in test.os
  "_godot_string_new_unicode_data", referenced from:
      _some_test_procedure in test.os
  "_godot_variant_new_int", referenced from:
      _some_test_procedure in test.os
  "_godot_variant_new_nil", referenced from:
      _test_ready in test.os
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

And the outpu with -v is:

macbook-pro:simplelibrary pietro$ clang -g -v -shared src/test.os
Apple LLVM version 9.0.0 (clang-900.0.37)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 "/Library/Developer/CommandLineTools/usr/bin/ld" -demangle -lto_library /Library/Developer/CommandLineTools/usr/lib/libLTO.dylib -dynamic -dylib -arch x86_64 -macosx_version_min 10.12.0 -o a.out src/test.os -lSystem /Library/Developer/CommandLineTools/usr/lib/clang/9.0.0/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture x86_64:
  "_godot_nativescript_register_class", referenced from:
      _godot_nativescript_init in test.os
  "_godot_nativescript_register_method", referenced from:
      _godot_nativescript_init in test.os
  "_godot_print", referenced from:
      _some_test_procedure in test.os
  "_godot_string_destroy", referenced from:
      _some_test_procedure in test.os
  "_godot_string_new_unicode_data", referenced from:
      _some_test_procedure in test.os
  "_godot_variant_new_int", referenced from:
      _some_test_procedure in test.os
  "_godot_variant_new_nil", referenced from:
      _test_ready in test.os
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I'm on latest master of Godot and godot_headers.

I really don't understand the error as for example godot_nativescript_register_class is defined in the godot_nativescript.h header.

Is there something that needs to be changed to the compilation commands for them to work on Mac OS?

Please read before posting issues and PRs to this repository

godot-headers is a mirror of key files from the main Godot repository and files generated from a compiled version of Godot.

If there are any problems in the header files, implementation file or json files please raise an issue on the Godot Issue page as the fix will be needed there.

Equally if you have problems using any of the binding libraries using godot-headers please report your issue there.

Issues and PRs in this repository should relate to supporting files such as the README.md and for updating the repository with new files from upstream.

How to document pure C NativeScript/GDNative?

Hi everybody !

I really want to document the native C module I'm developing right now, just like the rest of Godot's main API is documented.

I've noticed in godot_headers functions that are supposed achieve that, in particular:

  • godot_nativescript_set_method_argument_information
  • godot_nativescript_set_method_documentation

However they are not accessible from godot_gdnative_ext_nativescript_api_struct which seems to be the only one exposed to the C API. Or at least, it's the only one explained in the little documentation/tutorials for godot native C libs so far. These functions would perfectly fit my desire to integrate in Godot a lib that is made to be used by others.

I deliberately avoid C++ API because it's much heavier and I don't like the idea of having a 50MB library just because I have to bundle all the godot-cpp static libraries (if you have a solution for this by the way I'm interested :))

So: What is the solution right now to document the methods I register through C API? Is it possible and how?

Thank you! <3

(NB: I've posted this in Godot Forums as well and will keep both sides updated)

wchar.h file does not exists and while compilling for Mac it generates error

In file included from simple.c:1:
In file included from ../../godot_headers\gdnative_api_struct.gen.h:5:
In file included from ../../godot_headers\gdnative/gdnative.h:141:
../../godot_headers\gdnative/string.h:39:10: fatal error: 'wchar.h' file not found
#include <wchar.h>
^
1 error generated

Command, i used:
clang -std=c11 -fPIC -c -I../../godot_headers simple.c -o simple.os
clang -dynamiclib simple.os -o ../bin/libsimple.dylib

I am using the newest version of Godot Headers and Godot 3.2

Default arguments in signals

There are default_args, num_default_args in godot_signal and default_value in godot_signal_argument.

Based on source code for godot_nativescript_register_signal (link to master, there are no changes to relevant part in question since third version) seems like default_args are not used. Instead a number of num_default_args default_values is collected from the start of args for use as defaults.

So seems like either default_args or default_value should be removed.

It seems wrong that default values are collected from the start and not the end of args.

And usage property in godot_signal_argument seems meaningless (it is absent from godot_method_arg for example).

`godot_color_to_argb64` and `godot_color_to_rgba64` Return Values Downcasting

Not sure if this is the correct place to open the issue. If not, please let me know where best to forward this to.

Within Godot Core both godot_color_to_argb64 and godot_color_to_rgba64 return int64_t, however in the API exposed

https://github.com/godotengine/godot/blob/3ed5ff244f679da590d360b38e35adcdcb0aeaf7/core/color.h#L51-L56

Through godot_headers, as well as GDNative itself, the returned value is down-cast to int32_t, aliased as godot_int.

https://github.com/godotengine/godot_headers/blob/d93984d8201ae6952f200ca55d91f1b6f58daeec/gdnative_api_struct.gen.h#L180-L183

This is most likely causing the returned result to be truncating and creating both erroneous and divergent behavior between GDNative and GDScript.

Questions about creating new bindings

I am planning to create GDNative/Nativescript bindings for the Crystal language. I already had a look at some bindings for other langauges, and they all seem to generate their source files based on an api.json specification file provided by the engine executable itself. However, I still don't understand how those generated files are related to the Godot C headers. Apart from this, what other steps are required in order to make the bindings work?
Thanks in advance!

Include nullability information

It will be nice to have a field that denotes if the returned type of a property or method can be null. This is useful for language bindings that support nullable types (i.e Kotlin).

godot_native_terminate: Can't resolve symbol

ERROR: get_dynamic_library_symbol_handle: Can't resolve symbol godot_native_terminate.
 Error: xxxx.so: undefined symbol: godot_native_terminate
   At: drivers/unix/os_unix.cpp:465.

That should be either in the docs as mandatory or fixed in the code.

Adding new overloads for Vector3 (Vector2) nad one more constructor.

I am working with Vector3 objects a lot right now and I see there is no overloaded operator for -= (real_t) and many others like this. Also, constructor which would initialize all coordinates to the same value could be nice.

I will definitely implement it in my version of godot-cpp. Just wanted to know if there is a reason why it is not already implemented.

Mutex causing trouble on OSX

Hi there.
I got a problem on Fmod GDNative implementation using a Mutex on OSX.
The lock is called in runCallbacks, which is called by update.
Here is stack trace:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib            0x00007fff6c3202c6 __pthread_kill + 10
1   libsystem_pthread.dylib           0x00007fff6c3dbbf1 pthread_kill + 284
2   libsystem_c.dylib                 0x00007fff6c28a6a6 abort + 127
3   org.godotengine.godot             0x0000000104770d75 handle_crash(int) + 1605
4   libsystem_platform.dylib          0x00007fff6c3d0b5d _sigtramp + 29
5   ???                               000000000000000000 0 + 0
6   libGodotFmod.osx.dylib            0x000000011d4777b7 godot::___godot_icall_void(godot_method_bind*, godot::Object const*) + 55
7   libGodotFmod.osx.dylib            0x000000011d44b7a4 godot::GodotFmod::runCallbacks() + 52
8   libGodotFmod.osx.dylib            0x000000011d44704c godot::GodotFmod::update() + 412 (godot_fmod.cpp:141)
9   libGodotFmod.osx.dylib            0x000000011d44cc9b godot_variant godot::__wrapped_method<godot::GodotFmod, void>(void*, void*, void*, int, godot_variant**) + 59 (Godot.hpp:211)

I tried with the engin version, the problem is not present.
I tried GDNative version on windows and the problem is not present.
So it seems to be a problem with Mutex gdnative binding on OSX platform.
Here is the code
Look for runCallbacks method in godot_fmod.cpp.
It does the same thing with a Mutex as local variable.
Even if I change gdnative init (just to test):

extern "C" void GDN_EXPORT fmod_gdnative_init(godot_gdnative_init_options *o){
    Callbacks::mut = new Mutex();
    Godot::gdnative_init(o);
}

by:

extern "C" void GDN_EXPORT fmod_gdnative_init(godot_gdnative_init_options *o){
    Callbacks::mut = new Mutex();
    Mutex mut2;
    mut2.lock();
    Godot::gdnative_init(o);
}

It crash at starting.

Typo in godot/vector2.h:100

I noticed that godot_vector2_operator_substract should probably be _subtract instead. Changing this might break people's current bindings.

Godot 3.1 branch?

Now that Godot 3.1 stable has been released I'm guessing we should update this repo to it's latest settings and create a 3.1 branch so enhancements for 3.2 don't end up in project prematurely?

Windows Project Files

Hello,

A big percentage of gamedevs and majority of games out there are on Windows platforms, especially for Steam. This means ideally we do need some good docs on how to setup and build GDNative with Visual Studio. Can you provide some example build scripts, cmake etc. to show how to do this? We are not on linux and neither are our customers.

Thanks

Missing header file for AtlasTexture

It seems the header file AtlasTexture.hpp is missing from this repository. The binding for it is in api.json.

Is there any reason AtlasTexture does not have complete bindings?

Question: iOS supported?

I could not find if iOS is supported by gdnative, which will be really useful as it would allow to share c code between android and iOS devices at native speed.
On the other hand, can the compilation process for each target be automated with scons during the exportation?

C++ easy coding via GDNative technology

If you accept suggestions, I have one that would be very welcomed by C++ users (me included), judging by feedback on the internet. Additionally, the idea may be applied to other languages as well.
Although coding in C++ is doable as it currently is, it's always better (for the users) to be able to simplify it and bring it as close to GDScript-ing as possible. So, do you think it would be feasible to automate most part of the workload more or less like:

  • let the users write cpp's for individual nodes, with the respective callbacks like _ready(), _process(), etc.
  • automatically wrap the cpp's and h's with code necessary for registering the classes and methods (maybe based on access modifiers - only register public ones).
  • build whole code into an so/dll.
  • in Godot make a new Language like "external C++" that when created, it automatically creates behind the gdnlib and gdns (or maybe combine them into a dedicated type according to the language, C++, D, etc.
  • when pressed, the script button next to the node would bring up the IDE.

The advantage: the user only worries about the actual cpp/h and when s/he modifies the code in the IDE, all the "re-importing" process (re-building, overwriting the so/dll) happens automatically.

Disadvantage: the user wouldn't have the same degree of freedom but then again, they'd be spared from the workload and it would be more than perfect for those looking for a simple way to code in C++ (like in Unreal). This would probably not work great with 3rd party libraries but it's great for C++ node scripting.

RootMotionView methods are missing

Had 4 inconsistencies that i found during writing bindings. With get_name in EditorSpatialGizmoPlugin, rotate in PathFollow2D, light_mask in LightOccluder2D and missing getter/setters in RootMotionView.

First three problems seem to be solved in godot 4 with proper renames, but RootMotionView issue still remains:

RootMotionView has 4 properties defined with getters and setters, but none of those getters or setters are present in api (json or documentation).

Tag specific commits for each Godot stable version

Follow-up on #24, which added dedicated branches for stable Godot versions, matching the Godot repository.

In 3.1.1 we broke GDNative compatibility with 3.1 to fix a security issue, so the need to tag stable version arises. I propose to use the same convention as the Godot repository and to tag specific commits from the stable branches with matching 3.1-stable, 3.1.1-stable, etc. tags.

IINM, 489db27 would be 3.1-stable and 98ee825 would be 3.1.1-stable.
It might be worth tagging 3.0.x versions in the 3.0 branch too (it's OK if several tags share the same commit if no update happened in the meantime).

I can do this if we agree on this versioning. CC @karroffel @BastiaanOlij

I'm also working on an update of http://docs.godotengine.org/en/latest/tutorials/plugins/gdnative/gdnative-c-example.html which includes some misleading information. Once we have tags, I would suggest that this tutorial makes people checkout the actual tag matching their Godot version, instead of assuming compatibility.

How to use godot_variant_evaluate?

Hello,I'm doing some cool things with godotC library recently.
I use godot_variant_evaluate to complete the 'operator'
In the API, 'godot_variant_evaluate' is like this
void (*godot_variant_evaluate)(godot_variant_operator p_op, const godot_variant *p_a, const godot_variant *p_b, godot_variant *r_ret, godot_bool *r_valid);
This is my code:
godot_variant A;
godot_variant B;
godot_variant ret;
api->godot_variant_new_real(&A,43.658);
api->godot_variant_new_real(&B,4.36);
godot_bool i=false;
api2->godot_variant_evaluate(GODOT_VARIANT_OP_ADD,&A,&B, &ret, &i);

I use the mingw64 compiler on Windows x64 bit system, which compiles normally
But when I use the DLL, Godot crashes!!!
So does anyone know what's wrong with it, please

Header does not provide information on what is expected from the object produced by GDExtension to be a valid Godot object

It's unclear what this create function should return:

GDNativeExtensionClassCreateInstance create_instance_func; /* this one is mandatory */

But looking at the code in main godot repo, which handles this objects, it's obvious that there are specific requirement, including functions this object should have. Godot-cpp is complient with it as it appears.
Thus, to me it seems like it's important to cover this information in the header file. Be it a comment or (preferably) a struct.

How does the function of godotC library work?

I've been using the godotC library for a while, and most of the time, it works.
However,I have some doubts, because I found that godotC library only includes '.h' files. I want to know where the function definition is.
Then I found that some of the function definitions are in the gdnative module
likegodot/modules/gdnative/gdnative/variant.cpp
But I also found some strange things. For example, there are some functions that I can't find in the gdnative module!!! (/゚Д゚)/

First

I can't find the definition of godot_vector2_get_x() in the godot_headers/.../vector2.h file
But I can use it!!!
WHY? w(゚Д゚)w

Second

in transform2d.h,I want to get the x property of transform2d,But I didn't find godot_transform2d_get_x()
HOW can I get x? (´?ω?`)

If you know the answer, please let me know. Thanks (=゚ω゚)ノ

Built-in GDScript functions

This is not a bug, just a question.

There are multiple issues about yield which has obviously a gdscript specific implementation, but what about others?

Almost one hundred useful methods that are currently unavailable for native bindings. Looking at C++ and C# adapters it seems like you have to write your own implementation to match the api...

(I guess for now i'll have to create some singleton that exposes all those methods (which do not have varargs) and then simply "call" them (not the most performant way, but something).)

How hard it would be to expose those methods and are there any plans to do so?

Missing getter/setter for RootMotionView properties

The property RootMotionView::animation_path defined in the api.json uses accessors get_animation_path, set_animation_path, but these functions are not present in the api description. there is a similar issue with the following properties:

  • cell_size
  • color
  • radius
  • zero_y

Missing APIs for core types

Hello! I'm working on a new native binding for Godot (https://github.com/raniejade/godot-kotlin) and I have notice that there are quite a lot of missing APIs for the core types.

One example is that the getters and setters for Vector3 are missing, e.g:

  • godot_vector3_get_x
  • godot_vector3_get_y
  • godot_vector3_get_z
  • godot_vector3_set_x
  • godot_vector3_set_y
  • godot_vector3_set_z

I know that there are versioned struct aside from the core one, however, I didn't find the missing APIs there.

Readme out of date

The test script provided in the README file wil no longer compile.
godot_string_new_unicode_data(&s, L"Hello World", 11); does not seem to be in the API at all anymore.
Actually, the readme script no longer uses the most up to date API. If you get it to compile, Godot will just crash when loading it.

access missing api’s

Sorry for asking, but Is there a way through gdnative to access AudioStreamPlayer’s _mix_to_bus, or is it module only?... Or in general: is it possible to access everything in Godot also in gdnative?

How to use this?

It seems cool for script binding.
But how can I use them?
Where are the definitions of the functions godot_*

Enum types are not used for arguments and properties in the api.json

Question about api.json:
Why enum types are presented as such only in return_type and shown as int everywhere else?

Random example: OS has screen_orientation property with type of enum OS.ScreenOrientation, but this enum is presented only in return_type for getter, while set_screen_orientation has an argument orientation of type int and property itself typed as int too.

In documentation there is no such discrepancy everything that is enum has enum attribute.

Can GDNative instances interact with or create other GDNative instances?

I have a GDNative module called int_test that has p_user_data pointing to an int. I would like to create a method for this module that takes in another int_test instance and adds the parameter int_test's int to its own int. In GDScript, it would look like this:

func example():
    var int_test_res = preload("res://bin/int_test.gdns")
    var int1 = int_test_res.new()
    var int2 = int_test_res.new()
    int1.set(3) # sets int1's p_user_data int to 3
    int2.set(4) # sets int2's p_user_data int to 4
    int1.increment(int2) # adds int2's int (4) to int1's int (3). How is this done in C?
    print(int1.get()) # prints 7

In this example, is it possible for the module's increment function to take in another int_test instance and get it's p_user_data? If so, how?

If the above can be done, here's a similar question: Can a new int_test instance be created and returned within a GDNative method? I would like to have an add function that takes in 2 int_test instances and returns a new one whose int value is the sum of the 2 parameters'. The GDNative code would look like this:

func example():
    var int_test_res = preload("res://bin/int_test.gdns")
    var int1 = int_test_res.new()
    var int2 = int_test_res.new()
    int1.set(3) # sets int1's p_user_data int to 3
    int2.set(4) # sets int2's p_user_data int to 4
    var int3 = int1.add(int1, int2) # Creates a new int_test instance whose int = 3 + 4
    print(int3.get()) # prints 7

Is this possible in GDNative?

Win10 VS2015-built DLL: Fails to load GDNativeLibrary

Context:
Windows 10
Visual Studio 2015 Community Edition
Godot latest as of commit ceded65 from 06/20/2017
Having just compiled a .dll in visual studio (walkthrough in this issue from /cpp_bindings.

Issue:
Built the cpp_bindings tutorial SimpleClass into the .dll. SimpleClass has no parent class it inherits from as far as the scripting language is concerned (?).
Attempting to load the .gdn resource after setting it to point towards the .tres of the GDNativeLibrary appears to fail with the following errors:

Can't open dynamic library: [path to project_folder/lib/gdtestdll.dll] Error: 126
Condition ' initialize_status != OK ' is true.
Condition ' !native_library->scripts.has(p_name) ' is true. returned: 0
Condition ' !script_data ' is true.

Reproducible Steps:

  1. Create a godot project. In this case I'll reference GDNativeTest as the project name and project_folder name.

  2. Create lib folder and insert into it the .dll file generated from visual studio project build (referenced above).

  3. Create Node2D as root node in first scene. Save scene as main.tscn in GDNativeTest.

  4. Click on the Add Resource button, select GDNativeLibrary. Set the "Windows" file to be GDNativeTest/lib/gdtestdll.dll. Save it as GDNativeTest/gdtestdll.tres.

  5. Click on the Add Resource button, select GDNativeScript. Set the target to be GDNativeTest/gdtestdll.tres. Set the Class Name to "SimpleClass".

  6. Add a built in GDScript inheriting from Node2D to the root node. Add, below the extends statement, the following:

var SimpleClass = preload("res://SimpleClass.gdn")

  1. Run the game. The errors discussed initially will display in the debugger. Attempting to call more functions, such as

func _ready():
var sc = SimpleClass.new()

...will result in an error as new() is considered a nonexistent function.

The size of godot_variant seems wrong on 32bit builds

I need to transfer dozens of arguments of various types in an array from gdscript to gdnative. I found that the Color is transferred incorrectly. Example code based on gdnative c example:

gdscript:

extends Control

# load the Simple library
onready var data = preload("res://bin/simple.gdns").new()

func _on_Button_pressed():
    $Label.text = "Data = " + data.get_data([Color(1, 1, 1, 1), "unused"])

cpp:

#include <stdio.h>

godot_variant simple_get_data(godot_object *p_instance, void *p_method_data,
        void *p_user_data, int p_num_args, godot_variant **p_args) {
    godot_string data;
    godot_variant ret;

    godot_array arr = api->godot_variant_as_array(p_args[0]);
    godot_variant v = api->godot_array_get(&arr, 0);
    godot_color clr = api->godot_variant_as_color(&v);

    char s[1024];
    sprintf(s, "(%g,%g,%g,%g)",
        api->godot_color_get_r(&clr),
        api->godot_color_get_g(&clr),
        api->godot_color_get_b(&clr),
        api->godot_color_get_a(&clr));

    api->godot_string_new(&data);
    api->godot_string_parse_utf8(&data, s);
    api->godot_variant_new_string(&ret, &data);
    api->godot_string_destroy(&data);

    return ret;
}

It's expected to get (1,1,1,1), but it actually returns (1,1,1,random number) on Win32 platform.

I suspect that the size of godot_variant is wrong in https://github.com/GodotNativeTools/godot_headers/blob/master/gdnative/variant.h

#define GODOT_VARIANT_SIZE (16 + sizeof(void *))

#ifndef GODOT_CORE_API_GODOT_VARIANT_TYPE_DEFINED
#define GODOT_CORE_API_GODOT_VARIANT_TYPE_DEFINED
typedef struct {
	uint8_t _dont_touch_that[GODOT_VARIANT_SIZE];
} godot_variant;
#endif

while in https://github.com/godotengine/godot/blob/3.2/core/variant.h it has members

	// Variant takes 20 bytes when real_t is float, and 36 if double
	// it only allocates extra memory for aabb/matrix.

	Type type;

	// ...

	union {
		bool _bool;
		int64_t _int;
		double _real;
		Transform2D *_transform2d;
		::AABB *_aabb;
		Basis *_basis;
		Transform *_transform;
		void *_ptr; //generic pointer
		uint8_t _mem[sizeof(ObjData) > (sizeof(real_t) * 4) ? sizeof(ObjData) : (sizeof(real_t) * 4)];
	} _data GCC_ALIGNED_8;

I notice the GCC_ALIGNED_8, which implies that godot_variant has size 24, but not 20, even on 32bit platforms.

I also inspected the actual memory layout of godot_variant (if you pass a separate Color as the second argument):

	uint32_t *ptr = (uint32_t*)p_args[1];
	for (int i = 0; i < 6; i++) printf("%08X\n", ptr[i]);

and it seems that the _data actually start at offset 8 even on 32bit platforms.

Anyone can confirm this?

Missing 'const' in signatures in transform.h

Hello,
while making bindings for Godot in Rust, I've encountered strange function signatures in transform.h file:
void GDAPI godot_transform_set_basis(godot_transform *p_self, godot_basis *p_v);
void GDAPI godot_transform_set_origin(godot_transform *p_self, godot_vector3 *p_v);
I believe both '*p_v" arguments should be constants.

Native scripts crash on Windows with MinGW

Whenever I try to call any Godot function from a native script, the scene or engine crashes depending on which is trying to use it. I should mention, that I am not trying to cross compile from Linux, but rather building on Windows with MinGW-w64.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.