XLua extention beta

[Retriever2]

Well, I don't think I can hook the actual destroy object action, but I can release the association if you try to use MMFI functions on a destroyed object.

[Dynasoft]

In ValueAdd (which pairs objects to a map of "unlimited" extra alterable values), I have the following code to free the memory I was using for objects which have been destroyed:

// ----------------
// HandleRunObject
// ----------------
// Called (if you want) each loop, this routine makes the object live
// 
short WINAPI DLLExport HandleRunObject(LPRDATA rdPtr)
{
	variable_map::iterator i = rdPtr->pVariableMap->begin();

	for ( i; i != rdPtr->pVariableMap->end(); )
	{
		if (i->first->hoFlags & HOF_DESTROYED)
		{
			i = rdPtr->pVariableMap->erase(i);
		}
		else
		{
			i++;
		}
	}

	// Will be called next loop	
	return 0;
}

Hope it helps.

EDIT: Of course because ValueAdd is only accessed from MMF, the functions can never be called on a destroyed object. For your Lua binding you're going to have to check the destroyed flag yourself in every call as well. You'd also need something like the above because an LPRO isn't valid past the end of the frame if it has been destroyed, and you could get crashes.

The alternative is to use "Fixed Values", which combine a unique ID (frame number (i.e. time) I think) and the object's index in the object list (which can be reused). You can use this to get an object out of the list and check to see if it is the same one you bound to. I think you'd still need to check the destroyed flag in each call, you just wouldn't need to run a loop like the above every frame.

[Retriever2]

A potentially large loop at FPS times per second is something I'd rather avoid. Global state does present a potential for crashing, but a single call to reset exports before jumping to a new frame mitigates that.

I've updated the XLua object again: http://hocuspocus.taloncrossing.com/rii/xlua-dist.zip

This includes an action to free individual exports, which ideally you would do immediately prior to destroying the object.

This also includes ramped up support for loading and embedding external C Modules. The included opengl example demonstrates this (the opengl support has changed since the release earlier this week).

Existing precompiled Lua C modules aren't compatible with XLua, but I've included xlua.lib inside the zip file now. Rebuilding against that library will create a compatible C module.

[nivram]

Hi Retriever2. Where would I put the LIB file?

Marv

[Retriever2]

The lib file has no place in the typical MMF directory structure, and you can safely ignore it. It's there for C/C++ developers who want to write their own C Modules for Lua (or rebuild existing C Modules). One of the more useful ones that I've tested, for example, is LuaSocket.

[Stephen]

I am pretty sure you just extract the files to your MMF2 directory, Marv, but I could be wrong...

Edit: Yep. Don't mind me.
Retriever2, did you get my PM?

stephen1980

[James]

Well, I don't think I can hook the actual destroy object action, but I can release the association if you try to use MMFI functions on a destroyed object.

Right -

The HOF_DESTROYED flag is set when the object is going to be freed at the end of the frame loop. You can check for that in HandleRunObject, and if it's set, remove the object from the interface and don't use the LPRO again.

[nivram]

Thanks for the info Retriever2 and Steven1980.

Marv

[Atom]

Thanks

Just curious i notice that with the examples there is a folder with dll's in. Are these required to be placed with anything made in MMF and Xlua to run? or just for used for MMF only and not required when a exe is made?

[Looki]

Actually, you'd have to distribute them with your programs, but you can use MMF's binary data functions to store them in your EXE.