如何建造

rayfork 只有一个 .c 文件，并且只依赖于 libc，这意味着它可以轻松地从命令行编译为库。

 # -c compiles the code as a library
# -EHsc disables exceptions on msvc

gcc -c rayfork.c
clang -c rayfork.c
cl -c -EHsc rayfork.c

原则

rayfork 不提供平台层，这意味着它不会为您创建窗口、加载 OpenGL 或捕获输入。

这是设计使然，以便您可以使用最适合您的方法在多个平台（包括游戏机）上轻松使用 rayfork。有一些模板可以将 rayfork 与 GLFW、SDL、sokol-app 和自定义平台层一起使用。

该渲染器目前具有 OpenGL33 和 OpenGL-ES3 后端（还有更多后端需要添加），这些后端以可移植的方式实现，允许 rayfork 在任何平台上编译，唯一的依赖项是 libc。 OpenGL 过程显式传递给 rayfork，并且有一个简单的宏可以帮助实现这一点。

因此，您可以轻松地为任何平台（无论是 PC、移动设备还是控制台）编译 rayfork。

执行 IO 的函数通常是可选的，并且明确要求 IO 回调。 libc IO 函数的简单包装器作为rf_default_io提供。

显式分配的函数需要一个分配器，有时还需要一个临时内存分配器（在函数内部释放的内存）。 libc 的 malloc/free 的简单包装器作为rf_default_allocator提供。

所有依赖项也都与自定义分配器一起使用，库永远不会在您不知情的情况下进行分配。

每个需要分配器或 io 回调的函数都有一个_ez版本，它包装原始函数并使用rf_default_allocator和/或rf_default_io调用它，这对于快速测试代码非常有用。

该库只有一个头文件和源文件，可以在编译时使用预处理器定义进行自定义。不需要额外的编译标志，具体取决于您可能需要链接到某些库的图形后端。

raylib 最初是为了教育目的而创建的，随着时间的推移已经成熟为一个非常有用的游戏库，类似于 XNA。

然而，由于其性质，raylib 中的一些设计选择使其难以被专业游戏开发人员使用：

rayfork 旨在解决这些问题，并让使用 raylib 的 API 轻松开发专业游戏。

我开始这个项目是因为我喜欢 raylib 和 C99，并且我真的很想使用它们来开发我的游戏。

然而，许多库并不遵循我在库中寻找的原则（请参阅本文），这使得在游戏中使用它们变得困难/烦人，这就是为什么我想创建一个库，独立开发人员可以自信地轻松地使用它来开发他们的项目无需牺牲控制性、便携性或质量。

如果您希望能够使用尊重上述原则的库轻松开发游戏，请考虑为 rayfork 做出贡献。

您可以检查问题选项卡并找到很多您可以做出贡献的事情。

我也在寻求帮助来开发我的专业知识之外的东西：

请在 #rayfork 频道的 raylib Discord 服务器上联系我，我是 @BananyaDev#0001，或者在 Twitter 上@SasLuca。
保持蛇形命名约定，对接口函数使用rf_function_name ，对私有函数使用_rf_function_name 。
所有函数都带有rf_public或RF_INTERNAL前缀
不要在界面中包含额外的标头，总体上尽量减少包含。
使用#pragma region #pragma endregion来折叠代码区域，并考虑使用支持折叠这些区域的编辑器，以便更轻松地掌握代码。
尝试总体应用本文中的建议。一些更重要的建议是：
- 不要分配内存，向用户询问 vertex_buffers/allocators。
- 不要使用非常量全局变量。
- 避免依赖于操作系统的函数。