Using LuaGL with LÖVE

[pekka]

I'm referring to this library here: http://luagl.sourceforge.net/

Since LÖVE is implemented on top of a GL context opened by the SDL library, you can use OpenGL commands and functions directly in a LÖVE program and draw to the LÖVE window. To get access to the OpenGL API, you need to require some library that allows it, because LÖVE doesn't let you do it. LuaGL is one such library.

This very simple example program draws a Gouraud shaded multicolor triangle on the screen. Its structure should be familiar to everyone who knows a little bit of (the old-style) OpenGL.

Code: Select all

require 'luagl'

function love.update() love.timer.sleep(10) end

function love.draw()
	gl.Begin(gl.TRIANGLES)
	gl.Color(255, 0, 0)
	gl.Vertex(20, 20)
	gl.Color(0, 255, 0)
	gl.Vertex(400, 120)
	gl.Color(0, 0, 255)
	gl.Vertex(20, 220)
	gl.End()
end

The tricky bit is making the require line do what you want. On my Linux computer, the steps to achieve this were quite simple, and they should be adaptable for you too. Here is what I did.

I downloaded a compiled package for Linux. Inside the archive are shared object files that contain the Lua modules. I put the luagl.so file into a directory that is in LUA_PATH and after that the require command just worked.

There are some caveats to doing this:

The code you write like this IS NOT PORTABLE as a LÖVE game, because it requires an external library that must be appropriate for each computer the game is to be run on. You will have hard time distributing your game!

The way LÖVE creates the OpenGL context is not appropriate for all kinds of things you can do with OpenGL proper. You might have to live without some functionality. The coordinate system is not suitable for 3D perspective projections (LÖVE is 2D) and there probably is no depth buffer, so you will have hard time drawing 3D shapes.

Combining OpenGL calls and traditional LÖVE drawing is, ahem, complicated. You might have the stuff you draw not appear when you do this. I'll see if I can work out the rules and see whether making your own love.run helps with this.

Perhaps a future version of LÖVE can support creating different kinds of GL contexts via conf.lua, so we can sneak in some happy 3D stuff with an external library (even though it is naughty)? You know, I might just write up a proposal for this for the issue tracker real soon now. We'll see what comes out of it.

Still, it might be fun to play around with this. Please share your tips for getting LuaGL to work on other OSes. I'll close with a tiny screenshot of the triangle the program draws.

It's a colorful triangle!

triangle-shot.png (7.17 KiB) Viewed 6925 times

[thelinx]

This could probably be made a whole lot easier once LÖVE gets love.window, so love.graphics isn't tied to a window.

[bartbes]

Ehm.. why?

[Taehl]

Honestly, I'm not too thrilled by this. I like Love being made* specifically for 2D - there are too many engines and tools which overextend themselves, and end up half-assing all of it. There are plenty of other engines out there which are built from the ground-up for 3D, which I could use if that's what I wanted.

* That was completely unintentional phrasing

[Luiji]

If one wanted a 3-D engine, it might be better to create a new game engine that simply follows the concepts behind LOVE. Such an engine would preferably have concepts like OGRE, in which you declare a tree here as supposed to polygons here.

I would personally prefer that LOVE stops at love., meaning that any type of functionality should be defined by LOVE, not external libraries etc.

[pekka]

(Oh, BTW, I wrote something badly in my original message. You can obviously set up your own coordinate systems with OpenGL ops just fine.)

First a facetious reply. Then a serious one.

Well, if this possibility of using external libraries bugs you so much, you will just have to lobby for sandboxing the Lua runtime properly in future versions of LÖVE You might also find it helpful to make the devs stop distributing the source, because people who know C++ might change it to suit their own uses

Right. That's over with.

To correct some mistaken assumptions by people, I apparently need to write it out that I am not advocating mandatory inclusion of LuaGL for everyone, all the time, but just pointing out that it is possible to use it easily. I am also not advocating writing a 3D engine. If you want one that uses a language broadly similar to Lua, there is one called Panda3D. Check it out. It's great, even though it uses Python.

I merely suggested that you could make the full capabilities of OpenGL available via LÖVE for those who might want to use them. All it takes is allowing some features of OpenGL be enabled when LÖVE starts that might not be useful in LÖVE itself, but can be used via external libraries. You won't be enabling these things in your conf.lua, if you don't want to use them, and nothing at all will change for you. You could even enable them by default and nothing would be affected in code that doesn't use them.

Specifically, I am talking about the SDL GL attributes named SDL_GL_DEPTH_SIZE and SDL_GL_STENCIL_SIZE. And you know, stenciling has plenty of uses in 2D graphics too, such as creating arbitrary clipping regions.

I was also thinking of looking at how to incorporate Cairo graphics into LÖVE, but for fear of upsetting people even more, I guess I won't be talking about it here then

[Luiji]

1-up on Cairo capabilities, but as an official Löve feature.

Using external libraries only frowned upon by the community because it is not the best aproach to Löve game programming.

[bartbes]

We don't do censoring here (ehm.. well, <censored>), so write about cairo as much as you want, within bounds.

@Luiji:
Haven't you learned the love philosophy? It's all about providing the tools, but not providing everything, we're not game maker.

[Luiji]

Well, with love.physics, I've constantly doubted that you guys really believe in that.

Back to topic, so what can you actually do with LuaGL that is so special that it is worth more work for end users?

[Jasoco]

What's Cairo?

It's either the codename for Windows NT4.0 during its Beta stages, a font face from the class Mac OS days that was like WingDings in that it was symbols or a vector graphics library.