Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

render_vertex_array is lacking #242

Open
vuolen opened this issue Apr 18, 2016 · 4 comments
Open

render_vertex_array is lacking #242

vuolen opened this issue Apr 18, 2016 · 4 comments

Comments

@vuolen
Copy link
Contributor

vuolen commented Apr 18, 2016

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
Copy link
Owner

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
Copy link
Contributor Author

vuolen commented Apr 20, 2016

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
Copy link
Owner

iamgreaser commented Apr 20, 2016

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
Copy link
Collaborator

rakiru commented Apr 20, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants