XLua, MMF2 Extension

I'm currently working on something potentially nice ... which has to do with the MMFI object structure. But I'm holding back the details for now.

im guessing you don't want me to blow a load all over my monitors right

cool but i don't know how to work MMF2

oh it's not that good.

But it's full of delicious metatables and closures and has some serious implications for type safety and future object support.

http://hocuspocus.taloncrossing.com/rii/mmfi.zip

This is an experimental alternative to the existing MMF Interface (at least for objects). It's a much more object-oriented approach and IMO more natural to work with. Please experiment with it if you are interested in that sort of thing and offer feedback.

To use it, load the DLL, which will install a new global function: NewObject(objid)

Since it's separate from XLua right now you have to use the above function to explicitly instantiate new objects from existing exported IDs. In the future it may be more streamlined. Anyway that function will return a table represnting an object, and will contain embedded its pointer and fixed ID.

You can read and write most fields as if they were a normal lua table, rather than everything being a function call. Example:

This is the current API:

Read-only fields (all objects):
- fixed
- instance
- name
- type
- hotx
- hoty
- width
- height
- xleft
- xright
- ytop
- ybottom

Read/Writable fields (all objects):
- x
- y
- layer

Methods (all objects):
- destroy()

Read-only fields (active objects):
- zorder

Read/Writable fields (active objects):
- angle
- scalex
- scaley
- direction
- animationSet
- animationFrame
- visible
- flags*
- values*
- strings*

* these values are tables that let you access the subvalues directly by 0-based index

Methods (active objects):
- isAbove(obj2)
- isBelow(obj2)
- moveToFront()
- moveToBack()
- moveAbove(obj2)
- moveBelow(obj2)
- swapOrder(obj2)
- overlapsBG()
- overlapsObject(obj2)
- overlapsInstance(objtype)
- getOverlapping()


Like I said this is all an experiment to see how I can leverage more advanced aspects of Lua to produce a more natural model. It's still in flux and ultimately may go nowhere, or may only exist secondary to the existing API. Here's the way I see it right now:

Pros:
- Natural object model allows getting and setting most values directly
- Objects stay associated with a fixed ID and their internal pointer - you can manage objects directly instead of managing IDs
- Better safety (cannot accidently call MMFI functions on incompatible objects .. objects expose ONLY the values and functions that they are compatible with)
- Can associate additional associated data directly in object tables

Cons:
- A small amount of extra overhead for managing tables instead of flat IDs.
- Objects are actually proxy tables, that is they are really empty and cannot be iterated with pairs
- Can't selectively disable parts of the MMF Interface, since each object in essence controls its own access to the interface (cannot simply nil out functions)

tl;dr this post is for xgoff

This post has been edited by Retriever II on Oct 6 2009, 02:02 AM

yeah basically what i said in irc

clickteam's choice of variable names is inconsistent as hell so yeah i'd do things like stick x and y at the beginning instead of the end

but yeah apart from that it looks good i'll have to try it out later

LuaGL update: http://www.clickteam.com/epicenter/ubbthre...3152#Post163152

There is a significant API change, it is not directly compatible with existing code (the necessary changes are trivial but there are probably a lot of them in your code...)

**** yes

also yeah luagl looked not so great from a design standpoint; having to use strings like "QUADS" and stuff was kinda dumb from the get-go

lol now i just need to figure out how to get c libraries to compile correctly and not give me that "procedure could not be found" or w/e error

This post has been edited by Xgoff on Oct 22 2009, 08:57 PM

I'm having a bit of an odd problem (surprise!)
and it turned out to be my fault (surprise!)

:D

This post has been edited by Mecha the Slag on Oct 24 2009, 02:54 PM

a way to do type(var) in MMF2 would be neat. Either that, or "is variable string?", "is variable number?" etc

You can do inline function calls in expressions. You couldn't call type directly but you could call a function that calls type and returns its value.

That doesn't work, it always recognizes the parameter I send to the function as a string.

This post has been edited by Mecha the Slag on Nov 1 2009, 01:35 PM

uh i can't remember all of what you said about coroutines but:

function a() DoCall("MF_Say", "hi") end b = coroutine.wrap(a) b()

works in lua' but

function a() MF_Say("hi") end b = coroutine.wrap(a) b()

doesn't in xlua ('MF_say' changes the text of a string object)

in fact this seems to be the case for any MMF function you try calling from a coroutine

It either has to do with the way xlua manages the call stack, or it has to do luajit's workaround for coroutines. Do coroutines work if they don't call MMF functions?

yeah they seem fine outside of mmf

it'll throw a "attempt to resume a dead coroutine" error if you call b() twice

This post has been edited by Xgoff on Nov 1 2009, 02:22 PM

How do coroutines feel about c functions in general

according to the manual only coroutine.yield() can't be called while a c function is running

so i'm guessing they're fine with them

EDIT: i accidentally my verbs

This post has been edited by Xgoff on Nov 1 2009, 02:30 PM

What would you guys want included in a protocol to communicate between two lua states? It's something I've been planning to add for a while now and I've gotten some more interest on Clickteam.

Right now I'm thinking of being able to "export" functions to one or more states, which would allow them to be called by those states. It would be similar to calling functions in MMF, in that control transfers to the other state until it returns, leaving the prior state suspended. At a marginal performance overhead, this model should be very good for creating a sandbox.

Other than what I mentioned above though, are there other things you would consider useful or necessary in an inter-state communication protocol?

sharing object properties (position, variables etc) between states

Coroutines are now fixed (although I don't know if there are any hidden problems with coroutines and multiple levels of nesting). Updated build will be posted tomorrow with some other bug fixes.