Drawing from Lua could be better in Spring-106

Drawing from Lua could be better in Spring-106

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Post Reply
CommanderSpice
Posts: 26
Joined: 29 Jun 2011, 13:14

Drawing from Lua could be better in Spring-106

Post by CommanderSpice »

In spring-105 we used the fixed function pipeline of OpenGL more or less directly:

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)
That was very flexible, because you could do anything with OpenGL from Lua.
Also it was trivial to write a wrapper like this in Lua:

Code: Select all

DrawRectangle(x1, y1, x2, y2, color)
Spring-106 dropped OpenGL 3.

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.
CommanderSpice
Posts: 26
Joined: 29 Jun 2011, 13:14

Re: Drawing from Lua could be better in Spring-106

Post by CommanderSpice »

Pull request is here https://github.com/spring/spring/pull/581.
I settled for Spring.Draw.Lines, Spring.Draw.Triangle, Spring.Draw.Rectangle. Encountering several BA widgets that did their own bevels and radii each, Spring.Draw.Rectangle has parameters for that when drawing to screen. Also borders are probably useful there.
raaar
Metal Factions Developer
Posts: 1050
Joined: 20 Feb 2010, 12:17

Re: Drawing from Lua could be better in Spring-106

Post by raaar »

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

The key here is that the engine should provide an interface with functions to generate basic UI components : draw rectangles with some border,color,texture configuration and drawing fonts.

There could be an extra ID parameter that's passed to help the engine figure out which calls can be "bundled together" for more efficiency.

Although I'll end up using BAR105 engine, thanks for doing this work. It'd be nice if both engines converged to use the same interface.
Post Reply

Return to “Engine”