Built-in Math Objects

[bjornbytes]

I've found the lack of a math library to be really painful. It seems that > 90% of projects end up bringing in a maf/cpml, so it makes sense to just provide it directly. Thoughts:

• Will other APIs (graphics) accept/return vectors? Will they also support individual numeric parameters? How much does this impact API complexity/performance? It would be annoying to have to unpack vectors any time you wanted to use them, especially because you can't easily pass multiple sets of multiple return values to a function in Lua.
• If possible, the implementation should use a pool of objects or some other technique to try avoid GC issues, and the API should encourage object reuse (e.g. reusing input vector as the result of an operation).
• It would be cool to support swizzling and other glsl-like stuff to make the transition between Lua and glsl less intense.
• LuaJIT structs can be used for improved performance, but for wasm we would probably just use Lua tables.
• It would be cool if vectors were table-like, so you can read or assign v.x. Function calls like v:setX() would be pretty heavy and annoying to work with.
• There isn't really a place to write Lua code for modules yet, so that system will need to be designed.

[bjornbytes]

A proof of concept can be found in the math branch.

[bjornbytes]

A potential plan:

• Add vectors to lovr.math, written in Lua. Uses LuaJIT/Lua tables (cpml/maf style).
• Add an API for temporary vector pools in lovr.math, but make it optional. Maybe lovr.math uses them behind the scenes but you can create your own if you want to optimize further.
  • This needs more thought.
• Maintain two sets of bindings for lovr.graphics and lovr.headset (how bad can it be). Primitives accept numbers and tables/vectors as arguments. The LuaJIT version of the bindings are written in Lua and unpack their vectors into numbers and FFI those into lovrGraphics. The C bindings are written in C and support both numbers and tables in the case where LuaJIT isn't available.
  • Alternatively the bindings could be written exclusively in C and use hacks to access the FFI structs. This is 5x slower due to metatable lookups but is negligible overall.
  • Alternatively the bindings written in Lua could be written on top of the existing Lua bindings and just translate vectors into numbers.
  • Is there overhead in having 3 API layers instead of 2?