Kinda surprised seeing this here. I made this project 2 years ago and haven't updated it since. It was an interesting proof of concept, but I only took it far enough to run a couple of my games. The only takeaway was that I was really disappointed with the performance of native client OpenGL.
The modern version of Love supports OpenGL ES though so a rewrite like this isn't required, a better approach would just be to try to compile Love.
If you want to see more cool stuff I've done with Lua:
Hi Leafo I have tried to get in touch a couple of times. Question: Does Moonscript have coroutines ? In case it doesnt, is there a way to use Lua's coroutines together with Moonscript ? In case it does, could you point me to the syntax, couldnt find it in the docs.
Sorry, I can no longer edit my comment above. You just use Lua coroutines.
For people unfamiliar with Lua coroutines, there is no extra syntax for them. There are functions coroutine.create, coroutine.resume, and coroutine.yield. They do about what you'd expect them to do. If you're familiar with greenlet, the first function is greenlet() and the second two functions do the job of greenlet.switch().
There's a lot to like about Lua, especially when you compare its speed to that of reference Python or Ruby, but the weak typing makes me reluctant to try it for a larger project. I almost wish there was a TypeScript for Lua.
Technically, Lua is a strongly typed dynamic language: it's just that most things happen to be of a single "supertype" (the table).
If you need a more rigorous approach, Lua's integration with C is good enough that you can write the architectural bits in C/C++ and just use Lua for the long tail of behaviors, or go one bit better and use a language like Terra [1] that provides a C-like static language inline with your Lua code.
>Aroma implements parts of the LÖVE Lua API, so if you've got a game already written it’s easy to port.
>In the future Aroma hopes to implement the whole LÖVE API
Love has been growing quite a bit among small indie developers lately, so I'm glad they did this. I hope it doesn't take too long to fully implement it.
So Google Chrome is now the "portable" C/C++ runtime that developers are encouraged to code for? Why must native applications take a dependency on Google's web browser again?
It runs in a sandbox, so users don't have to trust the game developer as much and the game can run in a high security environment such as a Chromebook.
Of course it remains to be seen whether this is an interesting market, but the iPhone and Android app stores have done well with similar strategies.
The modern version of Love supports OpenGL ES though so a rewrite like this isn't required, a better approach would just be to try to compile Love.
If you want to see more cool stuff I've done with Lua:
Moonscript: http://moonscript.org
Lapis: http://leafo.net/lapis