iceball
iceball copied to clipboard
render_vertex_array is lacking
render_vertex_array
in src/gl/render.c
is not very flexible. Your options of modifying the model matrix are limited.
glScalef(scale,scale,scale); glRotatef(ry2*180.0f/M_PI, 0.0f, 1.0f, 0.0f); glRotatef(rx*180.0f/M_PI, 1.0f, 0.0f, 0.0f); glRotatef(ry*180.0f/M_PI, 0.0f, 1.0f, 0.0f);
As you can see you have no option to scale the matrix with different values in different axes. There is also no straightforward way to rotate the matrix in the z axis or in any arbitrary axis.
I suggest keeping this function for legacy reasons but making a new one with more parameters controlling the variables mentioned earlier. Also the most flexible way would be to allow us to push/pop and manipulate matrices from lua. This would be for really specific situations.
Also the most flexible way would be to allow us to push/pop and manipulate matrices from lua.
This is probably the best approach for it.
It also means that stuff like glUniformMatrix4f
or whatever it's called can finally be used from the Lua side.
I'm not sure if it would be best to implement a matrix userdata object or to just deal with the values directly. Voxycodone uses the former approach (it's basically an opaque interface to datenwolf's linmath.h). The code from there is rather incomplete at this stage, though, and I'm not sure if and when I'll get back into it.
Well the simplest solution would probably be to bind gl* functions straight to Lua.
Although my suggestion would be to use the userdata. This would eliminate the need to worry about the stack (maybe someone forgot to push/pop) and just use glLoadMatrix before rendering. Maybe have a new render_vertex_array function that takes a matrix as a parameter?
Edit for some thoughts: A good engine should allow for straight OpenGL calls. Then again engines are made for abstraction so we could have a matrix4 and vector2/3/4 helper functions purely in Lua. Your game might or might not need matrix math outside OpenGL's calls. Really the question is do we want to have matrix math packed straight into C or distribute it as a Lua file
Another argument for using userdata is that the matrix stack does not exist in GL 3 Core, nor does it exist in GLES 2.
Ideally we'd want it written in C. You'd probably want to ask rakiru if it needs a compatibility shim written in Lua, or if we should just tell people to upgrade their engine. Considering we have a small userbase it might just work better to skip on a backwards compat API, and if you really need backwards compat you can just detect the absence of the matrix library and have a fallback on a per-mod/game basis.
My opinion on compat shims is that if they're quick and easy to write, you may as well, but otherwise there's no point given the current userbase (or lack thereof).