MonkeyLua
Monkey Archive Forums/Monkey Projects/MonkeyLua
| ||
| So, I decided to port Lua to Monkey. A few weeks' worth of work (on and off) and we have an alpha quality demo for C++ targets. I've also done a simple wrapper for Mojo, so you can call Mojo commands from Lua. There's an example included. If you have problems setting it up, please post them here with the output of any compile errors. If you have bug reports or feature requests, please raise an issue on Google Code. MonkeyLua @ Google Code: http://code.google.com/p/monkeylua/ Lua: http://www.lua.org/ There's a download available, but if you want the bleeding-edge version you can just clone the repository (Mercurial). Update 18/02/2012: Thanks to the new reflection stuff in v54, you can now access fields of Monkey objects without any wrapping. local myimage = LoadImage('someimage.png')
print('image dimensions='..myimage.width..'x'..myimage.height) |
| ||
| Excellent work :) For me adding: #TEXT_FILES="*.txt|*.xml|*.json|*.lua" To the top of the test source files copies across the lua file to the data folder... eg: Strict #TEXT_FILES="*.txt|*.xml|*.json|*.lua" Import mojo Import monkeylua Import monkeylua.mojolua ...I've still got to copy the *.h to the build folder though, it'll be nice if Monkey would do that for you. |
| ||
| Also, luaL_dofile uses fopen directly to open lua files (ignoring the data directory prefix). This means that you either need to prefix your lua file with "data/", or use DoString and LoadString. Note that in the stdcpp target, you will need to manually import the "os" module to use LoadString. |
| ||
| YES! Awesome, i was thinking of doing the same thing. Ultimately you can write an engine in Monkey, and use Lua as the scripting language. Cool stuff. |
| ||
| Ultimately you can write an engine in Monkey... Yep, but I'd hazard against using a lot of Mojo graphics commands in Lua. There are of course overheads when using a lot of callbacks, and while it's pretty fast, don't go doing 1000 DrawText calls in Lua. I was getting about 40fps when the pure Monkey code was doing 60fps. All Monkey objects can be stored as Lua values, and you don't even need to keep a reference in your Monkey code. The built-in reference counter will do that for you to prevent Monkey GC'ing it. So as the example shows, you can indeed load and draw images directly in Lua without needing to store them in Monkey. Monkey objects are stored as a table with a single light userdata key called __pointer. The table is assigned a metatable that handles garbage collection and indexing of fields. Functions are stored the same way with the same metatable, but it has the __call metamethod implemented so that it will call the Monkey code. |
| ||
| @Samah... I think you read Adam's post wrong, even though you quoted it ;) Write an engine in Monkey and script it in Lua... |
| ||
| No, I read it as intended, but the line between engine and script is quite blurred. The mojolua test I've included is technically still a Monkey engine with a Lua script even though there are a lot of graphics commands on the Lua side. |
| ||
| Nah, I still think you read it wrong :P Anyway, heres some quick instructions to get it going: 1. Download the zip file from here: http://code.google.com/p/monkeylua/downloads/list 2. Extract the zip 3. Open MonkeyLua\src\mlmojo_test.monkey in Monk/JungleIDE 4. Add the following line: #TEXT_FILES="*.txt|*.xml|*.json|*.lua"as shown in post #2 5. Alter the LoadLua method so it looks like this: Method LoadLua:Void()
If state.DoFile("data\game.lua") <> LUA_OK Then Print state.ToString(-1)
End6. Compile for GLFW - you will get an error 7. Copy the header files (*.h) from the MonkeyLua\src\monkeylua\native\lua-5.2.0\src\ folder to your build folder (where the main.cpp is) 8. Recompile again, hopefully you will now have a Monkey game running :) 9. Play around with the game.lua file in the build/data folder (remember it will get deleted if you do a clean build) 10. Ten just because I didnt want to finish on nine :P |
| ||
| Holy moly, just what the doctor prescribed and I was lookign for. THANKS a ton and don't stop working on it. PLEASE!!! :-) |
| ||
| There's a lot to add still, so I have my work cut out for me. I might look at porting some of the Gems demos. I'd like to support more targets too, but the Lua implementations for most of the other targets are only 5.1. I was going to use a #LUA_VERSION preprocessor or similar to choose it, but I might have problems with reference counting. References are released by the __gc metamethod, and I believe they changed the way that works. |
| ||
| I'm currently working on a simple demo game to show how you might use MonkeyLua, but in the meantime, which target(s) would you like to see next? Android: Most likely needs the NDK. We'll see how I go. HTML5: This is actually possible! I could compile it with Emscripten, but it'll be a fairly large download... iOS: Hopefully this should already work, with some tweaking. I haven't tested it yet. XNA: No idea at the moment, sorry. Flash: I might be able to bind this to Alchemy, but I haven't looked at it yet. |
| ||
| i'd vote for android, ios, but I know you have a lot of work ahead. http://www.badlogicgames.com/wordpress/?p=943 http://xnacoding.blogspot.com/2010/07/how-to-lua-xna.html http://code.google.com/p/lua-alchemy/ |
| ||
| Update: Reflection! (see main post) |
| ||
| Wheres the full version of LeftLuaDead??? ;P |
| ||
| Samah, in regard to what therelvills stated... @Samah... I think you read Adam's post wrong, even though you quoted it ;) Write an engine in Monkey and script it in Lua. ...I think I know what he's trying to saying, and what you kind of noted in your own post about the expense of the graphics calls via Lua. I think your work is great, but over-extending Lua's job. I've still got to take a look at you implementation, because it is noteworthy and probably quite useful from the perspective I have, as follows... I think it would be more realistic to expose some prescribed Monkey data object, like a "Player" (and a way to create them), which Lua would simply inject attributes into; i.e., sprite, speed, perhaps physics attribs, etc. The particular Monkey application would maintain the full responsibility of general flow control and graphics. In this way you'd be writing Monkey code as simply that, and allowing for Lua to be responsible for simpler customization tasks. I just personally wouldn't want to learn Lua calls to what Monkey already provides. I'm very new to Monkey, but not new to programming, and you do have to be careful because the line can get blurred (as you stated in a post). I'm sure, yet, of what would be needed expose data/objects to both sides yet, because I'm new to Monkey. |
| ||
| Samah, great stuff and thank you! HTML5 and Android would be great. Does this support JIT Compiling? |
| ||
| @3Dski: @Samah... I think you read Adam's post wrong, even though you quoted it ;) Write an engine in Monkey and script it in Lua. Nope, I read it exactly as he meant it. You misunderstood my response. @3Dski: ...but over-extending Lua's job. Huh? I've basically ported the Lua interface directly to Monkey, so that you can do all the low level calls you need. Then I wrapped those calls in a nice interface so you don't need to worry about the low level stuff. @3Dski: I think it would be more realistic to expose some prescribed Monkey data object, like a "Player" (and a way to create them), which Lua would simply inject attributes into It already does this. The __index and __newindex metamethods on the monkey object metatable automatically do reflection magic to access your fields. @3Dski: I just personally wouldn't want to learn Lua calls to what Monkey already provides. I assume you're talking about mojolua. That module is there solely as an example of how to wrap Monkey functions so that you can use them in Lua. I'm not expecting you to actually write your entire graphics engine in Lua; the overhead would be monstrous. @Dima: HTML5 and Android would be great. HTML5 is a big ask. The real solution is to write the entire Lua VM in pure Monkey, but it's a huge task. As for Android, the fastest solution would be to just build the current codebase with the NDK and make some externed wrappers to the Lua API. I'm not sure I'll have time to look at it, as I have a lot of other projects to not finish. :) @Dima: Does this support JIT Compiling? No, sorry. :( |
| ||
| Considering that Lua and JS are both associative array languages, I wonder if it's possible to just translate one into the other. |
| ||
| Considering that Lua and JS are both associative array languages, I wonder if it's possible to just translate one into the other. Doubtful. The Lua VM is very different to the JavaScript one. The best solution I've seen so far is to compile the entire Lua source code to JS with LLVM and Emscripten. https://github.com/kripken/emscripten The resultant JS file is huge though, so it's not really a good choice for the web, imo. |
| ||
| XNA: No idea at the moment, sorry. There are some pure c# implementations of lua, that work even on wp7 and xbox360 without circumstances. Targeting the CLR could be more complicated than dynamic interpreting(Lua to CLR might need to be done in a content importer/processor on xbox..?). https://github.com/chkn/AluminumLua https://github.com/xebecnan/UniLua https://github.com/mlnlover11/SharpLua http://www.ppl-pilot.com/KopiLua.aspx |
| ||
| Yeah, already looked at all of those. Believe me, I've done my homework. :-) Tbh I'm more interested in getting Android working first. |
| ||
| @Dima & Samah ; Did you check : https://github.com/mherkender/lua.js ? |
| ||
| I have this 'small dream' to implement all Corona classes/functions in Monkey (which wouldn't be that hard tbh using the user modules) and then port over my Corona projects ; mixing and matching where I don't want to touch the Lua code or replace if the Lua interpreted code is too slow. |
| ||
| @frank: I've seen something similar to that before, but here's the kicker: __mode and __gc metamethods are not supported I need the __gc metamethod to handle reference counting. |
| ||
| With the danger of sounding like a noob (I can code in Lua but never used meta methods, at least not that I can remember); __gc is for garbage collection; would that not be handled by JS and in that case just ignorable? Or is that a weird thing to say? Also, going through your code; it seems you are not using it for the Java version either. It's used in Jill internally, but not by your glue/wrapping code? |
| ||
| would that not be handled by JS and in that case just ignorable? To keep it cross-platform, Monkey objects are stored in the host language and referred to via an array index. It was going to be too difficult to handle Monkey objects as full userdata, and either way, Monkey will GC it itself. The Java version in the repository is a work-in-progress. I've since ditched Jill in favour of just using the NDK. |
| ||
| Do you have any kind of roadmap? Just asking as I have a project coming up for Android which would really benefit from some scripting power! |
| ||
| How about now http://kripken.github.io/lua.vm.js/lua.vm.js.html :) |
   |