iamgreaser / iceball

Open-source rewrite of the VOXLAP version of Ace of Spades.
http://iceball.build
GNU General Public License v3.0
113 stars 32 forks source link

render_vertex_array is lacking #242

Open vuolen opened 8 years ago

vuolen commented 8 years ago

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.

iamgreaser commented 8 years ago

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.

vuolen commented 8 years ago

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

iamgreaser commented 8 years ago

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.

rakiru commented 8 years ago

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).