Hey guys,
I managed to port gmLua to Game Maker 8.1 using GMAPI 0.0.7. I'd like to share it with all of you: gmLua81!!Please note: You should NOT use this DLL with Game Maker 8.0 or less. It is ONLY compatible with 8.1.In other news…Lua Framework TeaserI'm still working on my lua framework project. It'll allow you to develop awesome User Interfaces for your game maker projects with minimal impact on performance as opposed to scripting it all in GM. The best part? You can embed your scripts in a DLL so that no one can touchie! I'm still working on it, but I plan to have a sample project ready in the next few weeks as well.- DF81
GML itself still calculates internal collision for any and all objects in Game Maker regardless of whether you tell it to or not. By eliminating that bottleneck, you've only got rendering (calling GM functions from Lua) done using GML - everything else is done in Lua.
Rendering in GML is easy, probably not the best solution, but it's easy enough to wrap for. I've currently got my same lua engine running in an XNA framework as well, but it just doesn't look as good since I just started learning it and can't do everything that I've already done in GML.And I haven't wrapped the engine to C++ or straight C# because my talents lie in engine design - I'm absolutely horrible at OpenGL / Graphics / Rendering. GML does the stuff that I'm bad at, which I like. Find me someone to build a graphics engine in either of those languages and I'll wrap my engine to it. :]
Then get a graphics library like SDL/SFML/something to do the rendering for you…
Collisions in GM are actually pretty fast anyways when comparing brute force. There's obviously a difference if you're taking advantage of some kind of space-partitioning system like grids, quad/octtrees, k-dtrees, etc though...but if I were to go to the effort of doing that in lua, I'd just fucking use C/C++ instead for that, since you'd get a speed boost over Lua and you wouldn't be coupled to Game Maker for just a portion of the code, which is dumb.Just how many objects are you having with collisions though? 500,000?My framework in GML had about 300 objects rendering at once. My engine itself made use of a powerful child/parent/dependency point referencing system that was scripted in GM and handled those calculations differently for each object type that I had. [Some objects were just reference points while others handled displaying tooltip information, etc.] It was slow. It was slow because calculations in GML are noticeably slow when compared to everything else. It was slow because converting anything to a string is slow. Hell, it's faster to call the Lua DLL to convert strings for you! That's how silly it is! This of a long list of number values that you want to display to the screen. If you send that list to Lua, perform your string conversion there, and then return it, you'd save yourself a good portion of the time that it would have taken to perform that conversion in GML even if the content of the string you were converting to a string was already a string.
The primary difference between my approach then and my active one today is that I have eliminated my reliance on Game Maker's collision detection, event handling, string calculation (which actually turned out to be the slowest section of the original engine), and its silly restriction of room size and its effect on framerate. With my engine now, all I use GML for is loading in my Lua file, registering the draw functions, and linking 1 Object's events with the Event Handling system I have built in Lua.Sure, I could have taken the time to completely rewrite my game engine in C++ or C#, but I already had a game engine. I had already taken the time to painstakingly rewrite it all in straight Lua and I didn't feel like taking away all of the (pretty neat) subclass inheriting logic. With classes as I've developed them in my Lua framework, you can change everything about how a class interacts with the engine - from the collision detection (Self Only, Children Only, Both, None), to the drawing (Draw, DrawChildren, DrawOverlay), to its point referencing methods (TOP/TOPLEFT/CENTER/MIDPOINT/RIGHT/BOTTOMRIGHT, etc.) and how each of those points align to each other… I could go on.Needless to say, I wanted to be able to cross-platform my engine between development IDEs and I've already done so. Currently, I've got a Wrapper for GM 8.0, 8.1, and XNA. XNA, believe it or not, is slower when it comes to rendering. (Though, then again, I've only just started learning XNA and am most likely not using it like I should be.)Seems like iOS has a Lua engine called Corona… I think I may just have to wrap my engine for that too. Heh.
Alright, but I still think it's retarded to be using GM with Lua for that and not just C/C++ with Lua.
Tell you what, Rob. I'll use all programming languages that support Lua. C/C++ will be next on my list after I get XNA working 100% like it should.
So I heard Brainfuck supports Lua…
Let's do it!