See #136

我在我的 linux 系统上倒是可以运行起来，但是在这一步出错：

[2024-05-17 08:05:51.18][ERROR]( ant.resource_manager|resource ) compile failed: /home/cloud/ant/pkg/ant.resources.test/sky/colorcube2x2.texture
----------------------------
3rd/bimg/src/image.cpp(5278): ASSERT size == imageSize -> KTX: Image size mismatch 64 (expected 384).

@junjie020 这个 colorcube2x2.ktx 文件你是怎么制作的？有可能在 luamake 中增加一个步骤从更原始的数据在构建流程生成吗？

colorcube2x2.ktx 这个文件看起来不符合标准，见 bkaradzic/bimg#63 。

The exception is non-array cubemap textures (any texture where numberOfFaces is 6 and numberOfArrayElements is 0). For these textures imageSize is the number of bytes in each face of the texture for the current LOD level, not including bytes in cubePadding or mipPadding.

这里 64 才是对的，文件里编码了 384 （ 64 * 4 ）。

因为 release 版本是不做 assert 检查的，所以在 ios 上运行（也会使用 ktx 版本）时没有报错。ios 我们只运行 release 版本。

去掉这个检查后，我在 linux 上遇到了同样的问题，接下来再看看具体为什么。

3rd/bgfx/src/renderer_vk.cpp(3848): ASSERT texture.m_currentImageLayout == texture.m_sampledLayout -> Mismatching image layout. Texture currently used as a framebuffer attachment?
Fatal error at 3rd/bgfx/src/renderer_vk.cpp(3848): [DebugCheck] Mismatching image layout. Texture currently used as a framebuffer attachment?

我查了一下，这里 texture.m_currentImageLayout 的值为 VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL ，它应该是 VK_IMAGE_LAYOUT_GENERAL 。是在 https://github.com/bkaradzic/bgfx/blob/master/src/renderer_vk.cpp#L2878 这行被改的。

即 assert 里描述的，这个 texture 被当作 framebuffer attachment 使用了。

调用栈：

#6  0x0000555555e275ed in bgfx::vk::RendererContextVK::getDescriptorSet (
    this=0x7fffedbb2010, program=..., renderBind=..., scratchBuffer=...,
    _palette=0x7fffd6510940) at 3rd/bgfx/src/renderer_vk.cpp:3849
#7  0x0000555555e11d15 in bgfx::vk::RendererContextVK::submit (
    this=0x7fffedbb2010, _render=0x7fffd6510140, _clearQuad=..., 
    _textVideoMemBlitter=...) at 3rd/bgfx/src/renderer_vk.cpp:8772
#8  0x0000555555dce4c6 in bgfx::Context::renderFrame (this=0x7fffd4bd2040, 
    _msecs=5000) at 3rd/bgfx/src/bgfx.cpp:2461
#9  0x0000555555dc9ea3 in bgfx::renderFrame (_msecs=-1)
    at 3rd/bgfx/src/bgfx.cpp:1480
#10 0x0000555555dee619 in bgfx::Context::renderThread ()
    at 3rd/bgfx/src/bgfx_p.h:3149
#11 0x00005555556626ad in bx::Thread::entry (this=0x7fffd4bd2240)
    at 3rd/bx/src/thread.cpp:325

我感觉正确的执行路线应该执行到 https://github.com/bkaradzic/bgfx/blob/master/src/renderer_vk.cpp#L2852 这一行才对。

我看到这里有两个条件：https://github.com/bkaradzic/bgfx/blob/master/src/renderer_vk.cpp#L2844C4-L2845C30

if (NULL == oldFrameBuffer.m_nwh
			&&  m_fbh.idx != _fbh.idx)

是不是因为第二条件没有满足，即m_fbh.idx和_fbh.idx是一样的（都是初始化的0或者其它值）：
m_fbh.idx != _fbh.idx

是这样的。这个是用来设新的 frame buffer ，设置新的就恢复旧的。

现在出错是在 submit() 里（同一次调用）：

https://github.com/bkaradzic/bgfx/blob/master/src/renderer_vk.cpp#L8315 调用 setFrameBuffer 把里面的 texture current layout 改了

运行到下面 https://github.com/bkaradzic/bgfx/blob/master/src/renderer_vk.cpp#L8771 调用 getDescriptorSet 时，断言 texture 的 current layout 就出错了。

不知道 bgfx vulkan 是不是有什么特殊的约束条件：比如当前 frame 用到的 texture 不可以是当前的 frame buffer ，这个要 @junjie020 确认一下。其实 windows 也可以切换到 vk 测试的，可能需要先在 windows 下试试用 vulkan 的 renderer 调试一下。

我把 https://github.com/ejoy/ant/blob/master/pkg/ant.hwi/main.lua#L7 改为 windows = "VULKAN" 后， debug 版本出现了同样的问题。btw, @fangyidong linux 版本这里也应该设置一下正确的 renderer 。

release 版可以运行，但效果不对，模型是黑色的。

奇怪的是，windows 下使用 vulkan 并没有触发 3rd/bimg/src/image.cpp(5278): ASSERT size == imageSize -> KTX: Image size mismatch 64 (expected 384). 这个断言，具体原因待查。

我猜想 linux 版如果编译 release 也是可以运行的。但是现在编译有点问题：

[104/417] Compile C++ build/linux/release/obj/ozz/ozz.obj
FAILED: build/linux/release/obj/ozz/ozz.obj 
gcc -MMD -MT build/linux/release/obj/ozz/ozz.obj -MF build/linux/release/obj/ozz/ozz.obj.d -std=c++20 -O2 -Wall -I./3rd/ozz-animation/include -I./3rd/bee.lua -Iclibs/luabind -Ibuild/linux/release/lua54 -DNDEBUG -o build/linux/release/obj/ozz/ozz.obj -c clibs/ozz/ozz.cpp
clibs/ozz/ozz.cpp: In member function ‘virtual void* HeapAllocator::Allocate(size_t, size_t)’:
clibs/ozz/ozz.cpp:21:59: 错误：‘malloc’在此作用域中尚未声明
   21 |                 char* unaligned = reinterpret_cast<char*>(malloc(to_allocate));
      |                                                           ^~~~~~
clibs/ozz/ozz.cpp:7:1: 附注：‘malloc’ is defined in header ‘<cstdlib>’; did you forget to ‘#include <cstdlib>’?
    6 | #include <ozz/base/io/archive.h>
  +++ |+#include <cstdlib>
    7 | #include <ozz/base/io/archive_traits.h>

cc @actboy168

linux renderer也是VULKAN对吧，这样我在 https://github.com/ejoy/ant/blob/master/pkg/ant.hwi/main.lua#L7 里面加一行就好？

linux = "VULKAN",

linux renderer也是VULKAN对吧，这样我在 https://github.com/ejoy/ant/blob/master/pkg/ant.hwi/main.lua#L7 里面加一行就好？

linux = "VULKAN",

理论上是的。因为每个平台都有多套 renderer 可选，如果不设置会让 bgfx 去猜。linux 下除了 vulkan 应该还有 opengl ，目前优先级比较低，所以默认选了 vulkan 。

而我们不打算支持 opengl ，所以 opengl 也没有得到充分测试。明确指定 vulkan 会好一些。btw, 你可以在 linux 下试试 opengl 的 renderer 。不过需要在 luabgfx binding 里加两行，现在没把 opengl 的字符串加进去：

分别在

https://github.com/ejoy/ant/blob/master/clibs/bgfx/luabgfx.c#L313
https://github.com/ejoy/ant/blob/master/clibs/bgfx/luabgfx.c#L696

其实，bgfx 是支持的 https://github.com/bkaradzic/bgfx/blob/master/include/bgfx/c99/bgfx.h#L91

我刚才试了一下，windows 下用 opengl 会白屏，看起来是 shaderc 无法正确编译 shader 。所以暂时也不用在 linux 下试了。

侦听XConfigureEvent（窗口大小变动触发的事件），然后调用window_message_size，这样显示相对正常了，但是还遇到以下问题：

1. 使用鼠标拖拽窗口进行缩小的放大操作的时候，会产生频繁的窗口变动事件，导致整个程序响应不过来了（有时甚至我的整个界面挂掉了，需要注销重新登录）；

2. 后来用了一个简单的方式，减少调用window_message_size的频率（见：5edc147
   ），稍微改善了一些，有响应了，但是程序还是经常黑屏；

3.点右上角按钮放大窗口，然后缩小到原来尺寸，如果只做一次，正常，但是再重复一次，界面就不动了；

4.模型显示的效果和window那个截图不太一样；

5.窗口左上方的memu没有显示出来.

发现只要调用一次window_message_size，那么关闭窗口的时候，console的ant的进程是不会退出的，如果把window_message_size的调用去掉就可以正常退出。（不过如果不调用window_message_size，窗口放大的时候，页面就没内容了）

那个ui是imgui，没实现imgui的后端，所以不显示。

侦听XConfigureEvent（窗口大小变动触发的事件），然后调用window_message_size，这样显示相对正常了，但是还遇到以下问题：

1. 使用鼠标拖拽窗口进行缩小的放大操作的时候，会产生频繁的窗口变动事件，导致整个程序响应不过来了（有时甚至我的整个界面挂掉了，需要注销重新登录）；
2. 后来用了一个简单的方式，减少调用window_message_size的频率（见：5edc147
   ），稍微改善了一些，有响应了，但是程序还是经常黑屏；

之前有个处理是，每一帧只处理一次resize事件。但最近被人回滚了，@junjie020。

https://github.com/ejoy/ant/blob/master/pkg/ant.world/inputmgr.lua

一个渲染帧内处理很多次 resize 好像真没什么意义？

我在ubuntu22.04上跑了下这个pr，debug下面运行会出现错误Mismatching image layout. Texture currently used as a framebuffer attachment?，release效果看起来跟 @fangyidong 运行的一致，模型显示是黑色的。

经过尝试发现，在关闭了bloom效果之后，debug运行不再报错了，猜测是不是bloom的实现里把frameBuffer中attachment的texture拿出来作普通的贴图渲染了，导致layout对应不上。
但是在关闭了bloom效果之后模型显示效果和上面的一样，还是黑色的，应该还有别的问题存在。

这个具体问题还在查。

bloom 的实现理论上没有问题，问题有可能出在 bgfx 的 vulkan renderer 里。也不只这一个问题。

另外，在 windows 上换用 vulkan renderer 可以完全复现，和 linux 关系不大。

目前的进展。vulkan 的问题是 bgfx 的 bug ，之前我们提过 fix ，但是 pr 没有被合并。接下来还需要督促 bgfx 修这个问题。

见：

bkaradzic/bgfx#3083
bkaradzic/bgfx#3063

如果把 bloom 关掉，应该是可以跑测试的。除此之外的部分，这个 pr 还有没有做完的吗？可以考虑先合并。

接下来准备实现以下内容：1.imgui的x11实现；2.鼠标move等事件; 3.fullscreen事件。也可以先合并。

imgui菜单可以显示了（但响应鼠标事件还有些问题，继续实现中）：

现在可以让imgui选中菜单和点击了，让动画也动起来了，看来是work了。不过现在把mouse move传递到imgui是通过某种hack的方式传递的，可能还有更好的方式.

建议合并, 这样我现在可以开始实现一个小游戏，然后在实现和测试的过程中，如果有遇到x11 window没有实现的能力，我可以根据需要补充实现即可。