Suggestion for dynamic, custom events

I saw it on the wishlist and thought up this approach:
Use the current SDL_UserEvent structure alongside this function:

Code:

/**

  • \brief Registers a new type of user event*
  • \return 1 if registering the event is successful, otherwise 0.
  • \param type Contains the value of the new type, chosen by SDL, if registration of the new event type is successful.
    /
    extern DECLSPEC SDL_bool SDLCALL SDL_RegisterUserEvent(Uint8
    type);

A companion library for SDL 1.3 that passes information through user events (such as a simplistic asynchronous I/O lib) might use it like this:
“SDL_Companion.h”

Code:

#include <SDL.h>
extern Uint8 SDL_COMPANION_EVENTTYPE;

int SDL_Companion_Init(Uint32 flags);

“SDL_Companion.c”

Code:

#include “SDL_Companion.h”

Uint8 SDL_COMPANION_EVENTTYPE = 0;

int SDL_Companion_Init(Uint32 flags)
{
if(SDL_RegisterUserEvent(&SDL_COMPANION_EVENTTYPE))
return 1;
return 0;
}

A case of SDL_RegisterUserEvent failing would be if 7 types of user events (24 (SDL_USEREVENT) -> 31 (SDL_NUMEVENTS-1)) already exist.
This method prevents an SDL-based application from being broken by multiple SDL-based dependencies trying to claim the same user event type (let’s say, SDL_USER_EVENT); assuming it’s actually used.
It doesn’t do anything to the internal state of anything else in SDL. It’s implementation can be as simple as a checked increment of a Uint8:

Code:

Uint8 next_EventType = SDL_USEREVENT;
DECLSPEC SDL_bool SDLCALL SDL_RegisterUserEvent(Uint8* type)
{
if(next_EventType == SDL_NUMEVENTS) return SDL_FALSE;
type = next_EventType++;
return SDL_TRUE;
}

Well there’s some things to nitpick about here, but they aren’t
relevant to the basic idea. I say write a patch!On Tue, Mar 2, 2010 at 9:11 PM, nfries88 wrote:

I saw it on the wishlist and thought up this approach:
Use the current SDL_UserEvent structure alongside this function:

Code:

/**
?* \brief Registers a new type of user event
?*
?* \return 1 if registering the event is successful, otherwise 0.
?*
?* \param type Contains the value of the new type, chosen by SDL, if registration of the new event type is successful.
?/
extern DECLSPEC SDL_bool SDLCALL SDL_RegisterUserEvent(Uint8
type);

A companion library for SDL 1.3 that passes information through user events (such as a simplistic asynchronous I/O lib) might use it like this:
“SDL_Companion.h”

Code:

#include
extern Uint8 SDL_COMPANION_EVENTTYPE;

int SDL_Companion_Init(Uint32 flags);

“SDL_Companion.c”

Code:

#include “SDL_Companion.h”

Uint8 SDL_COMPANION_EVENTTYPE = 0;

int SDL_Companion_Init(Uint32 flags)
{
? ? ?if(SDL_RegisterUserEvent(&SDL_COMPANION_EVENTTYPE))
? ? ? ? ? return 1;
? ? ?return 0;
}

A case of SDL_RegisterUserEvent failing would be if 7 types of user events (24 (SDL_USEREVENT) -> 31 (SDL_NUMEVENTS-1)) already exist.
This method prevents an SDL-based application from being broken by multiple SDL-based dependencies trying to claim the same user event type (let’s say, SDL_USER_EVENT); assuming it’s actually used.
It doesn’t do anything to the internal state of anything else in SDL. It’s implementation can be as simple as a checked increment of a Uint8:

Code:

Uint8 next_EventType = SDL_USEREVENT;
DECLSPEC SDL_bool SDLCALL SDL_RegisterUserEvent(Uint8* type)
{
? ? ?if(next_EventType == SDL_NUMEVENTS) return SDL_FALSE;
? ? ?type = next_EventType++;
? ? ?return SDL_TRUE;
}


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


http://codebad.com/

Donny Viszneki wrote:

Well there’s some things to nitpick about here, but they aren’t
relevant to the basic idea. I say write a patch!

Maybe your nitpickings will help with writing the patch. Or is it more with my examples of the use than the actual idea or example implementation?

I’m also not sure if that implementation is the “SDL way” to do it. I’m still not very familiar with the internals of SDL.
I’m also wondering if anyone has any better ideas for it.

Donny Viszneki wrote:

Well there’s some things to nitpick about here, but they aren’t
relevant to the basic idea. I say write a patch!

Maybe your nitpickings will help with writing the patch. Or is it more with
my examples of the use than the actual idea or example implementation?

Yes, it was the example use, like using the CPP macro naming convention
(ALL_CAPS) for a variable: the common use of the SDL_Event::type field is a
switch() statement, and you can’t use a variable as a switch case!

I’m also not sure if that implementation is the “SDL way” to do it. I’m
still not very familiar with the internals of SDL.
I’m also wondering if anyone has any better ideas for it.

The only thing I might tweak is having SDL print out an error message if it
overflows the custom event space.On Tue, Mar 2, 2010 at 9:59 PM, nfries88 wrote:


http://codebad.com/

Donny Viszneki wrote:

Yes, it was the example use, like using the CPP macro naming convention (ALL_CAPS) for a variable: the common use of the SDL_Event::type field is a switch() statement, and you can’t use a variable as a switch case!

Well, the macro naming convention was to add the feeling without it actually being a macro.
I don’t see a reliable way for this to be a constant using my implementation, period, so these values can’t be used in a switch statement anyway.
?

The only thing I might tweak is having SDL print out an error message if it overflows the custom event space.

SDL_SetError(“Failed to register user event: Too many user event types registered.”);

Is “register” really the right word for it anyway? Maybe “reserve” or “request” would be better (since there’s no sort of coercion here, just assignment of a value that could theoretically be ignored)?

Oh, and does this actually accomplish what’s on the wishlist? I might have misunderstood.

nfries88 wrote:

I saw it on the wishlist and thought up this approach:
Use the current SDL_UserEvent structure alongside this function:

A case of SDL_RegisterUserEvent failing would be if 7 types of user
events (24 (SDL_USEREVENT) -> 31 (SDL_NUMEVENTS-1)) already exist.
This method prevents an SDL-based application from being broken by
multiple SDL-based dependencies trying to claim the same user event type
(let’s say, SDL_USER_EVENT); assuming it’s actually used.
It doesn’t do anything to the internal state of anything else in SDL.
It’s implementation can be as simple as a checked increment of a Uint8:

That’s almost how SDL++ does it. SDL++'s event vector keeps track of a counter.
When a programmer instantiates a new event type, the vector is populated at the
counter index and the counter is incremented by one. The difference between your
scheme and SDL++'s scheme is that counter is strictly mapping SDL_UserEvent’s
code field to array indexes. The ‘type’ field is always kept at SDL_USEREVENT.

CE