• entries
    383
  • comments
    1075
  • views
    352268

Updating my Kernel

Sign in to follow this  
Trapper Zoid

48 views

I've got the unit tests of the signals running under both Windows XP and Mac OS X. I installed Code::Blocks on the MacBook Pro so that I'd be using the same IDE on both machines and the projects files are (mildly) compatible. I've still had to use separate project files for both systems as the directory locations of key libraries are different, and after a directory reorganisation both now cause Code::Blocks to whinge about malformed directory locations for some reason, but they compile and run without warnings which is the main thing. Stopping Code::Blocks throwing a hissy fit at run-time can wait.

For my next task I've decided to skip ahead a bit and design the kernel, otherwise known as the game loop. With the signal code in place this isn't that difficult to code; it really is just a loop that keeps sending signals until it gets told to quit. The main decision that needs to be made is how these modules will interface with each other using signals.

After sketching things out on paper, I can't help thinking that the best method for doing this is to define the signal interfaces outside of the class they "belong" to as signal objects out in global space. My initial thoughts on that proposal is my inbuilt reaction that globals are evil nasty things that should be avoided at all costs unless they are unavoidable. But all other solutions I can think of are either as convoluted as all hell or are globals in disguise (like singletons). The point is that with this architecture the signals are the main interface with core modules like the kernel and many different modules may need to connect up to it, and I might as well make the interface the signal itself rather than wrapping it up with pretty functions just to pretend it isn't global. Of course, all the signals will be contained within namespaces so it's not as if they'll be trampling all over the code base.

Now I just have to decide on a naming strategy for signals. I'm usually not a fan of code warts because I feel they make names harder for humans to parse, but in this case I might need something to signify that this is a signal. Maybe something like sig_KernelUpdate? Although I'm not sure about the "KernelUpdate" part...
Sign in to follow this  


0 Comments


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