|
|
|
|
|
by nikki93
1785 days ago
|
|
Love does work through wasm in the pure C++ approach, have been using it on a project for a bit now. It's definitely better that way vs. also using Lua since you can't use LuaJIT and vanilla Lua running in wasm esp. with a GC isn't geat perf-wise. Agreed re: C API -- would definitely need a wrapper there. The C++ API is also a bit less ergonomic in some ways than the Lua one (particularly how images are initialized) but also more in others (type checking and autocomplete is great). Lovr (topic of this post) uses LuaJIT's C FFI actually with a C API internally so it's more in that direction, FWIW. What does "library-driven approach" mean in raylib's case and how is it different from Love's approach? In both cases I just have a CMake project that builds my application to either a native executable (including mobile in Love) or web, with all dependencies vendored, calling functions and using types from either API. I do think raylib's C API fits this well and with the least impedance mismatch, having used all of them -- Love in Lua, Love in C++ and raylib in C -- extensively. eg. you can directly manage and render vertex buffers in raylib and go down to the 'rlgl' level, in constrast I found Love's default image rendering to have perf issues in web (it uses buffer orphaning) and I had to do something more manual with Love's meshes. |
|