[译]Godot 引擎 GDNative 架构初探

图片 1

GDNative的架起极度早为“DLScript”的时节到目前为止已经发出了老大充分之生成。随着Godot
3.0本接近尾声公布以及API越来越稳定,是早晚针对GDNative目前的相作一个概述了。

GDNATIVELIBRARY

GDNativeLibrary是同种资源类型。它是对每种平台所用的实际上二进制文件的一样种浮泛:包含有性质、“入口”库加载路径清单及“入口”库所指库的清单。

这些清单是千篇一律效仿功能特色标记的简单映射形式 –
一般是一个文本路径;如果起因关系之讲话,就是同样组路径。

特点标记

Godot有平等效仿特性标记系统。特性标记表示拥有相应之一定的性或效益,例如Windows,
X11, 32, 64,
mobile等等。在导出游戏常常,你啊得自动定义标记,从而可能移戏之运行方式。

再度多关于特性标记的消息,可以去http://docs.godotengine.org/en/latest/learning/workflow/export/feature\_tags.html查看。

GDNativeLibrary资源遭到的列表由键值对形式结合,键中根据需要好分包多只特色标记,以英文句点“.”分隔。

像一个支撑64各Linux机器的库房,它的键名即“X11.64”,如果对应的凡Windows的机器,则键名为“Windows.64”。

Godot编辑器提供了GUI来再人性化的进展这种资源的概念及编。

图片 2

它见面于上而下的针对性拥有入口进行检测,并超越了那些休存在的特征标记。在拥有可用之符中,第一独会受视作入口,所以排序很重要。

SINGLETON 库

GDNativeLibrary中起一个性能是用于定义其是否支持单例形式以的。单例库会于Godot启动期间尽量早地载入,且会调用库中的gdnative_singleton函数。这种库常用于需要提供与Godot紧密结合的效果。

GDNATIVE

GDNative对象表示所载入的堆栈,至于实际要加载哪个库就如于GDNativeLibrary资源文件被匹配了,Godot环境下之C++代码可以去调动用该库中之函数。由于这种措施去调用函数太过灵活、底层且未安全,所以是不建议由GDScript这些脚本语言中去调的。

假使真想从脚本语言环境一直调用相应功能,可以据此GDNative.call_native方法来满足急需。对于这种函数指针调用的根细节,抽象出了千篇一律栽所谓的“调用类型”来进展描述。目前独来同一栽预定义调用路:standard_varcall

  • 求让调用的函数签名也
    godot_variant function_name(godot_array *)。单例库可以依照需要报新的调用类型。

GDNATIVE/GODOT API

假若某库想调用Godot的一部分效能,它就是得去调整用Godot的代码。而各种C++编译器之间的移植性非常有题目,所以我们摘用C语言API的款式来封装对C++的调用。这被了多种语言访问API的可能性,但也带了一部分冗余性。

API 结构

一个仓库为了看那些用C封装的函数,它首先要知道那些函数的岗位。最直接的想法是留空,然后被操作系统的库加载机制来处理。

不幸的是,这种办法不可知在颇具平台正常运行(此处Windows可能而尴尬的咳两声),所以为了保在具有平台安装GDNative库用同样的代码和步骤,我们决定采取其它一样栽途径:在加载函数时,以函数指针结构(struct)的花样传递。

欠组织存在被Godot中,并蕴含版本信息、将来底API改动字段及扩充API列表。

struct godot_gdnative_api_struct {
    unsigned int type;
    godot_gdnative_api_version version;
    const godot_gdnative_api_struct *next;
};

struct godot_gdnative_core_api_struct {
    unsigned int type;
    godot_gdnative_api_version version;
    const godot_gdnative_api_struct *next;
    unsigned int num_extensions;
const godot_gdnative_api_struct **extensions;
    // ...
};

库可以起这种struct中做客所需要的函数,也即意味着不再是编辑
godot_some_function();这种样式了,而是api->godot_some_function();

稍加人爱不释手简单的通过函数叫作而无是struct来拜会函数,所以在发亟待经常,Godot的构建系统会扭转一个静态库,来包裹有的同名函数指针为静态函数。

扩展

GDNative 扩展是千篇一律种为库提供GDNative/Godot API
之外功能的办法。它们可以不同方法利用,下面会列有几乎栽时支持之形式之扩展。

恢宏通常含C语言API,可能还陪同着发由定义数据类型。Godot里平常有用于包裹那些和其余功能密切结合的C函数的C++类/方法。

每个扩展都出其自己之子API结构,其中蕴含了版本信息及前景API修改信息之字段。

ARVR

运GDNative来实现平等栽VR驱动的有所API可以参照文档: file。

这套API的起点是 godot_arvr_register_interface
函数,它需从一个单例库进行调用。那些要被Godot调用的函数则集体改为一个布局以参数的款式传递过去。

目前有 null-driver 的实现、 OpenVR 的实现 和 WIP OpenHMD 的实现。

NATIVESCRIPT

GDNative的初开发生涯里,它不过给计划用于脚本化编程,后来给挖掘出又多活和有效性的地方,脚本化编程能力现在就是内部一个扩大。

NativeScript 实现了平仿“脚本语言” –
在Godot中可以这么叫,但事实上是为此GDNative库而未是诸如GDScript那样的文书及文书的样式来保存有关逻辑。

NativeScript会调用库中的一个函数 nativescript_init
告知Godot哪来类似和方式是可用之。在苟就此到那些看似和方的时节,NativeScript就会杀简单的去调用之库房来实现相应功能。

坐 NativeScript
仅对库房开展操作,它并无关注这些库是故什么语言构建的,如果开发者要就此好爱的编程语言进行库底开销,就让
NativeScript 成为 Godot
里之等同栽最佳选项,尽管在这基础及还要交良多矢志不渝。

那么想要又活且还如脚本的发吧,就活该考虑用一下 PluginScript 了。

PLUGINSCRIPT

PluginScript也是一个扩张,它吃Godot加入了包脚本语言实现的特点。对Godot而言,它是平种植运行良好且全集成的脚本语言,但所有逻辑都是以一个储藏室中贯彻的。

NativeScript
把库房都当作脚本用,而PluginScript是因此库来定义脚本。也便是要以公的Godot项目受到补充加有文书,就可填补加相同栽新的脚本语言支持。

目前为止,这种“野生”的要紧利用还才发一个 godot-python项目。

与ARVR扩展类似,PluginScript的API也是颇细,仅来一个需要调用的函数
godot_pluginscript_register_language。该函数接受一个struct作为参数,struct里含有函数指针及脚本语言的别样信息。

Godot编辑器重开后,就会见效了。

计划

俺们在计划创建更多之壮大,如只是插拔式音视频解码器。

对于GDNative当前的架构,我们已相当满意了,下同样步要是圆满文档和改善语言绑定。