Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  


I honestly don't have anything of interest to talk about today, so I'm just going to ramble on about my code. Rah.

So I finished the SDL stuff to frisk around win32. Hooray for


! Now I won't have to worry about that until the next time my entire codebase deletes itself. At least I'm becoming proficient. Hur Hur Hur.

I did find out a queerness about SDL though which I found to be, err, facinating. If you create a fullscreen SDL video surface for OpenGL (with the SDL_OPENGL flag), then suddenly do an ungracious crash, SDL doesn't always reset the proper video mode. Which left me with a 300x300 screen for awhile (or something awkward like that, didn't actually measure it). Needless to say, it was a pain, and required a reboot to fix. Arrgh.

The next part (after init) that I wanted to get done is the event handling stuff. Now, I'm a huge fan of the Observer pattern (listener lists) for this, but in the old system I found myself constantly writing the exact same code for a couple of different events, which kind of ungratefully intertwined the event code with the GUI code. Which was very ungrateful.

This time around I decided to kind of factor it out. The first step, though, was a generic event handler with a bunch of events I'll be wanting to handle -

template < class EventType >
class EventListener {
virtual void onEvent( EventType e ) = 0;

template < class EventType >
class HandlerList {
typedef typename EventListener< EventType > Listener;
typedef typename std::vector< Listener* > ListenerList;
ListenerList _list;

void addListener( Listener* list ) {
_list.push_back( list ); }

void delListener( Listener* list ) {
ListenerList::iterator pos =
std::find( _list.begin(), _list.end(), list );
if ( pos != _list.end() )
_list.erase( pos );

virtual void raiseEvent( EventType e ) {
for ( ListenerList::iterator i = _list.begin();
i != _list.end(); ++i )
(*i)->onEvent( e );

Huzzah for templates? I think so. That'll save some time in the long run, and will make it a heck of a lot easier to, later on down the line, code in some really weird arbitrary events (like an OnChange event for a text box). In a lot of other GUI codez I've seen before all those buggers are hard-coded in, which makes me uehg.

Well, assuming my crap actually works. Which it often does not (YAY FOR NOT UNIT TESTING, WASHU!)

It gets really confusing when you inherit from multiple handlers and stuff, ie,

struct Rawr : HandlerList< KeyDownEvent >, HandlerList< KeyUpEvent > {..}

Because you have to do... weird things to specify exactly which function you want to call. Well, maybe not. Because the compiler should look up the proper overload based on the argument type. Hopefully.

In any case, I'm still feeling slightly fishy about the whole thing. I conceived it a couple months ago (???) and I remember finding problems with it. Granted, I was working outside at the time and was probably dehydrated, so I wasn't thinking straight.

Speaking of that, I could go for a popsicle right now...

Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!