5 个版本 (3 个破坏性更新)
| 0.4.0 | 2024年7月5日 |
|---|---|
| 0.3.1 | 2024年2月21日 |
| 0.3.0 | 2024年2月17日 |
| 0.2.0 | 2024年1月11日 |
| 0.1.0 | 2024年1月3日 |
#916 in 游戏开发
每月139次下载
37KB
291 行
bevy_webp_anim
bevy 中加载和播放动画 .webp 图像的插件。我们假设使用提供的 WebpLoader 加载的任何 webp 文件都是动画。帧的实际解码由 image 包处理。
解码在 tokio::runtime::Runtime 线程池中运行。资源 WebpAnimator 持有一个从视频 uuid 到通道接收器的映射。运行时将 bevy::Image 帧发送到通道接收器。
注册系统 load_next_frame 以自动继续动画。该系统与核心组件 RemoteControl 一起工作。该组件包含视频的 uuid 和 FPS 设置。通过在 Update 或与视频 FPS 匹配的固定时间表上运行 load_next_frame 系统等,每个 RemoteControl 组件将加载视频的下一帧到实体的 Handle<Image>。如果实体没有 Handle<Image> 组件,则丢弃该帧。
示例
$ cargo run --example basic 为兔子运行。
问题:支持大视频
当前 bevy_webp_anim 的实现将每个帧加载到内存中。然后,它通过循环将帧向量中的帧发送到通道接收器。这适用于我的用例,因为我的视频很小,我想循环播放。
然而,另一种方法将便于处理更大的视频。我们可以存储解码器(来自 image 包)并在需要时解码帧。目前实施此方法的麻烦在于,启动异步任务需要 Send 期货。然而,image 包中的 Frames<'a> 迭代器有一个内部的 Box<dyn Iterator<Item = Frame<'a>> + 'a> 类型。我们不能在 .await 点之间保持迭代器,这些点位于我们的通道发送者 async fn send 调用中。
特性:重用解码帧
我们可以让多个实体监听相同的视频帧。如果你想在屏幕的多个位置播放相同的视频,这将很有用。目前,你需要分别的解码器和分别的 Handle<Image>。
目前我项目中不需要这个特性,但如果有人需要,我很乐意添加。
问题:探索使用 bevy 的工作负载系统而不是自定义的 tokio 运行时
Bevy 自带线程池可以运行任务。可能最好使用这个而不是启动另一个 tokio 运行时。
依赖关系
~39–77MB
~1.5M SLoC