[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Enigma-devel] 2 types of world::Object

From: Ronald Lamprecht
Subject: Re: [Enigma-devel] 2 types of world::Object
Date: Wed, 22 Mar 2006 23:06:15 +0100
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)


Tacvek wrote:
Enigma appears to expose two different kinds of world::Object to Lua.
One is the type that things in Lua.cc deal with. The userdata of this type is tagged. A generic object of this type can be created in Lua using enigma.MakeObject("name"). A few of the other functions in Lua.cc can create this type of object. All of the functions will happily deal with it.

True - they use the tag generated in lua.cc l.788:
    // Create a new tag for world::Object objects
    object_tag = lua_newtag(L);

The other type of world::Object is the one dealt with the functions made accessable via tolua. The userdta of this type lacks tags. A generic object of this type can be created in lua using world.MakeObject. While most fuctions will accept objects of this type, functions in Lua.cc will not.

The tolua v4 generates tags for them, too: lua-enigma.cc
            Object* toluaI_ret = (Object*)  MakeObject(kind);

But it is indeed another tag. And MakeFloor has again another tag,...

The easiest way to proccede is to eliminate the first type of world::object. The downside of this is that it would not be possible to verify if a userdata passed to a function is really a world::Object. However, it turns out that only the functions in lua.cc are doing this anyway. The other functions don't check type.

I did not find any function in the tolua part that has an argument of object type that would have to be checked. I guess tolua would check the tag if necessary.

If the typecheking on those functions in lua.cc is too important to scrap, then it looks to me like some major arcitectural changes would be required to support versions of Lua >4. Otherwise, I can drop the type checking, and convert the remaining Lua.cc functions that are callable from lua into tolua functions, and move them into an appoprate source file.

Indeed I would prefer a common access method. But I hope it is possible to use the tag mechnism mentioned above. Daniel what is your opinion?

(It looks to be just plain luck that the way the code worked out, no objects of the none-tagged variety ever need to be passed to a lua.cc function.)

Is there any level that uses the tolua generated MakeObject,MakeFloor,... calls? They would indeed cause trouble!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]