Advice on designing a generic event system

[Void Mapper]

I've been working on a simple 2D game library and I'm torn between the following two approaches for handling events.
SFML style

Code: Select all

Event event;
while(window.getEvents(&event)
{
     switch(event.type)
     {
         
     }
}

GLUT style

Code: Select all

void mouseDown(Button);
void keyDown(unsigned char);
void windowClosed(void);

window.mouseBtnDown = &mouseDown;
window.keyDown = &keyDown;
window.close = &windowClosed;

I'm currently leaning towards the GLUT approach because it seems like it would be much more efficient than the SFML approach. Are there any advantages to using a SFML style or disadvantages to using a GLUT style?

[avansc]

They really are the same thing, glut just wraps the loop in glutmainloop or whatever it is called, I would recommend not using glut or sfml, and just doing it in the os.

the os will most likely have a loop where you process all the events.

[Void Mapper]

They really are the same thing, glut just wraps the loop in glutmainloop or whatever it is called, I would recommend not using glut or sfml, and just doing it in the os.

the os will most likely have a loop where you process all the events.

SFML creates it own separate queue for events, I doubt glut does that. Although I'm not currently planning to make the library multi platform (mainly because I only have a windows machine) I'd still like it to be an option. Also, message handling can be a pain in windows sometimes. One of the things I wanted to do with the library was to make it simpler.

[avansc]

How do you plan on getting events?

[Ginto8]

In order to really understand how SFML does it vs GLUT requires some more digging. I personally have gutted SFML's windowing code (for linux at least) in my pursuit to understand XLib. Basically what SFML has in the background is "handlers" that take system generated events, act upon them in some way, then decide whether to convert it to an sf::Event and pump it in to the queue. GLUT has user-provided handlers (and just user provided handlers).

[Void Mapper]

In order to really understand how SFML does it vs GLUT requires some more digging. I personally have gutted SFML's windowing code (for linux at least) in my pursuit to understand XLib. Basically what SFML has in the background is "handlers" that take system generated events, act upon them in some way, then decide whether to convert it to an sf::Event and pump it in to the queue. GLUT has user-provided handlers (and just user provided handlers).

I've looked through SFML's windowing code for windows. I decided to look through it after I finished the current version of the windowing system I have in my library. I wanted to see how SFML did it because I wasn't happy with the way mine turned out and I was hoping to get an idea of how to make it better. The main difference between mine and SFML's is that mine doesn't create its own queue. Every time a window's getEvents function is called it calls either GetMessage or PeekMessage. Then it converts the message it gets into an Event. Then the function returns whatever the call to Get/PeekMessage returned.

The main problem I have with my current system is how it handles messages that are sent to the window procedure rather than the message queue. At that point what I have to do is post a user message to queue so I can turn it into an event. I have to do this when the user moves, resizes, or closes the window.