thindx - 轻量级 DirectX 包装器

Rust的轻量级DirectX包装器。

为什么不直接使用 winapi 呢？

• 此crate旨在尽可能使函数安全/正确/略微Rust化。
• 通过大量单元测试尝试验证API的正确性，即使它们主要测试DirectX的行为。
• 文档注释为一站式智能感知、安全文档等。

为什么不使用 <其他图形 crate> 呢？

• 大多数其他图形crate都专注于尽可能多地隐藏底层图形API，以提高应用程序的可移植性。
• 此crate尽可能多地暴露底层图形API，以提高与其他图形代码/中间件应用程序交互的可能性。

❌ 此crate可能不正确！❌

我在将庞大的C++ API暴露给Rust。错误会发生。

尽管如此，正确性是一个 非常高的目标。 thindx 将在需要时添加一些东西，如额外的边界检查、参数验证、额外的初始化等，以确保尽可能在安全函数中保持正确性。当无法验证不正确性时，相关的函数应标记为 unsafe。此crate力求比你自己编写的任何手动FFI更加正确，这是一个 很高的 标准。

但是，这里有一些实际的限制。如果一个后台驱动线程在没有直接关联到特定API误用（如大整数溢出）的情况下，由于无法分配内存而引发UB，那么我无法通过安全函数合理地缓解这个错误。我的意思是，理论上我可以编写DirectX运行时的纯软件克隆...但不会。

此外，虽然我在寻求通过测试验证我的API，但有关API的旧实现可能存在更多错误/未检查的参数/等等，我可能无法通过无法触发它们自己来缓解这些问题。虽然我很乐意进行调查、接受pull请求、扩展测试覆盖率等，但除非你自己测试过，否则值得假设此crate在旧版本中不正确。

⚠️ API主要版本变更 ⚠️

单个fn函数可能会在无尽的尝试中获取/失去unsafe、特性和等，以使DirectX访问听起来更好。因此，thindx自身可能会一直受到主要版本更替的影响。这并不是一个大问题，直到两个crate想要在彼此之间共享/传递thindx类型。可能通过将它们放逐到子crate中，在一定程度上稳定一些类型，但这尚未实现。此外，单个扩展特型/函数/方法可能永远不会得到同样的待遇（不需要？）

项目状态

示例 • 头文件覆盖率 • docs.rs • lib.rs • crates.io

许可证

根据您的选择，受以下许可证之一许可

• Apache许可证，版本2.0（LICENSE-APACHE 或 https://apache.ac.cn/licenses/LICENSE-2.0）
• MIT许可证（LICENSE-MIT 或 http://opensource.org/licenses/MIT）

。

贡献

除非您明确声明，否则根据Apache-2.0许可证定义的您有意提交以包含在作品中的任何贡献，均将根据上述方式双许可，而不附加任何其他条款或条件。