That was very flexible, because you could do anything with OpenGL from Lua.
Code: Select all
function draw() gl.Color(1,0,0,1) gl.Vertex(0, 0, 0) gl.Vertex(1, 0, 0) gl.Vertex(1, 1, 0) gl.Vertex(0, 1, 0) end gl.BeginEnd(GL.QUADS, draw)
Also it was trivial to write a wrapper like this in Lua:
Spring-106 dropped OpenGL 3.
Code: Select all
DrawRectangle(x1, y1, x2, y2, color)
Now you need to create shaders and a vertex array and update it from Lua.
It is not flexible, because you cannot define vertex attributes from Lua, you have to select from available attributes and shoehorn them to your use case.
You have to know how many vertices you want to draw at most, because the vertex array has a fixed size. And the full vertex array is sent from Lua to C++ whenever you update it.
Writing the DrawRectangle wrapper is not trivial.
And it is not accessible for new widget creators: This is a lot of stuff to know for some dude who just wants to draw a rectangle on the screen to visualize where your units would do their square patrol.
So wrapping the OpenGL API in Lua worked great for OpenGL 3, not so much for OpenGL 4.
I am not complaining about the direction the engine development took, having seen 4-digit FPS early game with spring-106. I just think this part is broken and needs to be fixed.
I did try writing stuff on the Lua side to provide the old interface. It works, but it is a dirty hack. And the performance is not that great.
I think Spring should provide the draw functions that every game (and some widgets even) used to define, so widgets can draw with functions like Spring.GFX.DrawRectangle() and the engine sets up the shaders, manages a vertex buffer for the widget and does whatever neccessary to draw the rectangle. I know the engine does not know about different widgets, so the details still need some thought.
A handful of draw functions (or like 20) should cover most of the use cases.
Spring.GFX could be mostly independent of the graphics API, so the Lua side would need little or no update when someone does a Vulkan port of the engine.
It would be less flexible, but the OpenGL 4 API would still be there for fancy stuff.
Any comments on the technical aspect of this? This is just a request for feedback before I start any work on the engine.