# wasmbox **Repository Path**: lightsever/wasmbox ## Basic Information - **Project Name**: wasmbox - **Description**: 这是一个用wasm来开发网页 pc、移动 游戏的框架 是的，你没听错，这里要解决的关键问题是提供一致性的输入输出方法提供给网页与本地。 利用wasm来实现真正意义上的跨平台 - **Primary Language**: C - **License**: MulanPSL-2.0 - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 1 - **Forks**: 0 - **Created**: 2022-09-30 - **Last Updated**: 2022-10-06 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # WASMBOX ## 构建方法 新增工具 buildem.exe 执行 C:\git\wasmbox\wasm_example01> ../out/buildem.exe 将产生一个 buildem.bat 使用这个bat 构建wasm ## 序 WASMBOX 是使用wasm绕过js 直接开发图形化程序的框架 我承认，我是一个爱挖坑的人 这是我本年度最后一个坑，你就是打死我，我也再也不挖了。 而且这个坑是我尝试了各种跨平台思路之后的新坑，他将替代TTEngine TTLang最终也将会整合为wasmbox的周边 wasmbox 是跨平台的一个终极答案，目前0.00001 实现了最关键的一个技术演示 ## 论证 1.wasm为什么适合跨平台 wasm，火狐提出进入w3c的大名鼎鼎的webassembly标准。 我很长时间都在想：wasm看起来很美，但是他到底有什么用，终于经过了无数的时间，我想明白了。 wasm说到底是一个虚拟机，但是dotnet jvm python 都太复杂了，而lua则太简单了。 wasm刚好卡在了一个有趣的度上，c/c++ rust 可以编译为wasm，他是一个更接近机器语言的虚拟机（其实也没有那么接近，就一条没有longjmp就能玩死很多编译器，比如try catch机制就没办法编译到wasm） 但是不准jmp也就防止了溢出攻击。 我们不妨站远一点看问题，wasm是一个更接近机器语言的虚拟机，而且他可以防溢出攻击。那么wasm作为软件的存在形式，他是很合适的。 C语言是这个世界上使用最广泛的语言，C->wasm 保证了我们大部分的基础库都可以编译为wasm 由此一番推论，我们可知wasm 是跨平台最合适的方案，没有之一。 ## 论证 2.为什么浏览器api 是未来 wasm只是虚拟机，我们还需要大量的api才能支撑应用开发。 目前主流的跨平台方案，都有一个致命的问题 基于dotnet jvm 的，他们来不了web 基于浏览器的，封装为原生app性能不好。 但是浏览器有一个无法比拟的优势，有一个w3c这样强大的标准化组织在推动。 我对dom不感兴趣，不过webgl 作为一个绘图标准，他足够稳 webgl 你可以跑在各种各样的环境，pc 手机 微信 webgl webgl2 都已经非常稳定，将来还会有webgpu 基于webgl和将来的webgpu来做绘图，就一劳永逸的远离了无聊的渲染api之争。 懂行的同学可能会发出几个疑问 1.浏览器跨平台导致webgl跨平台，不代表你能跨平台啊 2.可是你没办法从原生c/c++调用webgl啊？ 这里经过我的灵光一现，想一想浏览器是怎么让webgl跨平台的？ 以chrome为例，google开发了angle项目，让dx11 vulkan opengl opengles 都来模拟运行 gles2 gles3. 然后浏览器的webgl 又是gles3的子集，底层v8再去调用angle的c接口。 所以这里其实我们已经拥有了c语言的全平台 gles3方案。 1.浏览器标准很稳定，很全面 2.浏览器chrome很强，而且开源，底层是c 3.我们可以借用浏览器开源的内容实现跨平台。 由此可证，从浏览器中找寻api，是一个很好的出路。 ## 论证 3.wasmbox的必要性 诚然，有一个简单的方案，直接集成一个浏览器，跑js可以同样开发图形化程序。 但是 wasm的优秀始终被js拖累，wasm提升的性能最终执行时还是需要通过js接口，kucha一下，又把抢回来的性能还了回去。 所以wasmbox 是提供一个 不通过js，让c/c++ 开发的wasm直接调用 c api的环境，这个环境，wasmer wasmtime 也已经提供了，我测试下来 wasmtime的报错更友好一点，先用wasmtime了。 我们所作的工作是基于 emscripten api 让你通过emscripten 开发的 wasm 程序，一行不改，不经过编译，直接二进制兼容，拿来就用，直接跑起来，行为和网页一模一样。 这和很多c/c++开发的引擎支持web的方法完全不一样，比如bgfx 他是针对wasm兼容再编译一次，自己抽象了各个平台不兼容的shader。 而wasmbox是你从头至尾只编译一次，得到一个wasm，用一样的shader，这个wasm即可以网页用，也可以本地执行。 # 我们做了什么 这是一个网站，他由 emsdk 开发，用c/c++ 写wasm ![](imgs/p0.PNG) 关键的wasm是t_O2.wasm 他初始化了webgl2，并clear了一个变化的蓝色 而这是一个c/c++ 开发的exe ![](imgs/p1.PNG) 他调用同一个t_O2.wasm,完完全全的同一个 得到了和网页一模一样的结果。 并且，没有集成浏览器，没有通过js。 彻头彻尾的c++ 与 wasm 这就是 wasmbox做的事儿。 我们使用的c++库只有 google angle 和 sdl2，这俩库都是跨平台的。 将来有空的时候，再build一份linux 一份macos 就可以让wasm只编译一次，用在所有地方 而且这个工作并不算很复杂，接下来就是通过一段时间的增加兼容api，让wasmbox能跑起来越来越复杂的wasm app，主要是game 和 engine 而且因为每个api可以单独测试，我有信心在下个月，让你们看到完全不同的Demo # 怎么测试这个程序 wasm_example01 是一个使用emsdk 开发的例子网页 你需要安装emsdk才能build它 可以参考这里 [https://www.cnblogs.com/crazylights/p/16538609.html](https://www.cnblogs.com/crazylights/p/16538609.html) 这里没有使用构建系统，直接用build.bat,emsdk自己的构建系统在windows上需要mingw，我不想把问题复杂化。 native_loader 是wasmbox本尊。使用vc和cmake 即可，目前只配置了windows。 依赖的库都直接提交在仓库中，如果想要自己编译angle也比较麻烦 可以参考这里 [https://www.cnblogs.com/crazylights/p/16666546.html](https://www.cnblogs.com/crazylights/p/16666546.html)