lua-users home
lua-l archive

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



Being the author of one of the SDL/Lua bindings, I have something to say about this. Most of all, people on the list should know that SDL/Lua co-operation is _not_ this difficult, in general. :)

Now to business:

The SDL_Event is a bit special, and should actually be described more as a 'event buffer' than a real event. SDL_PollEvent and others update it as a reference, which makes making a direct C/Lua binding (either by tolua or otherwise) a bit hard.

LuaX SDL module (also used in LuaCheia) deals with it as userdata, and has metamethods for accessing the different union bits and pieces. This works fine, and is performancewise good. Could I ask you why you are making the gluing with tolua(++) and not using one of the ready interface modules there is?

Just trying to help..

yours, - asko


19.3.2004 kello 15:24, Chuck kirjoitti:

 Ariel Manzur wrote:

The problem IS that SDL_Event was binded as a struct ! And in the real code
(SDL is a C library) the management of the SDL_Event type was made with
implicit assertions about its "union nature". Now that it is binded as a
struct, the fields which would have been are not updated anymore !

I explain. SDL_Event structure is the following (in the original SDL.h)

/* General event structure */
typedef union {
        Uint8 type;
        SDL_ActiveEvent active;
        SDL_KeyboardEvent key;
 /* ... lots of events more */
} SDL_Event;

What you must know is that SDL_ActiveEvent and SDL_KeyboardEvent which are "typedef struct" both have a first field which is called "type" and which
is of type "Uint8".

So, in your code, when you have a SDL_Event "e", you can make this (and it
is done like this in hundreds of lines of code) :
if (e.type == SDL_KEYDOWN || e.type == SDL_KEYUP)
{
manage_key (e.key); // this function does something with the key event
}
else
{
  // go on with the tests
}

Of course, you can use "switch .. case" statements but its not the purpose
of the discussion here.

manage_key() will have to react to the fact that it is a key pressed or
released and so, it will look into SDL_KeyboardEvent.type field which is,
thanks to the "union system", the same as the SDL_Event.type field.

Am I clearer ? I know that when I don't explain it is hard to understand
me :p