Cogs and Levers A blog full of technical stuff

OS Development Links

Over the past couple of months, I’ve compiled and refined a list of links that have been of assistance though my OS development journey.

LISP Experiments

I’ve always been interested in the mesmerising effect of browsing LISP style code. I wanted to make a blog post just to remember to take a look at it from time to time.

Installation in a debian-based world is as simple as

sudo apt-get install clisp

You’ll also be able to dress your code up inside of vim with Rainbow Parentheses

Just remember to take a look!

C Styles

A post about “Mustache templates” in C that I have come across has linked me through to two rather interesting articles about C programming styles.

Compound Literals

Anonymous Arrays

I’d previously been doing things very long-hand up until now.

State Management in Games

The title of this post does mention “Games”. In all honesty, with very minor modification you could change this implementation to suit any state requisition situation.

It’s the boring stuff that stops me half-way through developing a computer game. Building a menu, a title screen, a high-score chart.. you know, the stuff that takes you away from that big eye-candy feature that’s in the game.

Anyway, the implementation starts with a base class that manages some state. It’s a class that has provision to allow any derivatives of it to provide reaction code. The state manager will actually cause these “reactions” to occur. You’ll see this one shortly.

Here’s the class itself:

	
class state {
  public:
     state(void) : _finished(false) {
        std::cout << "constructed" << std::endl;
     }
 
     virtual ~state(void) {
        std::cout << "destructed" << std::endl;
     }
 
     virtual bool init(void) {
        std::cout << "initializing" << std::endl;
        return true;
     }
 
     virtual bool teardown(void) {
        std::cout << "tearing down" << std::endl;
        return true;
     }
 
     virtual void progress(void) { }
 
     const bool finished(void) { return _finished; }
     state* next(void) { return _next.get(); }
     state& next_state(void) { return *_next.get(); }
  protected:
     boost::shared_ptr<state> _next;
     bool  _finished;
};

Of course, this is all nice and abstract. It doesn’t really do anything. Here’s a simple derivative. Don’t expect too much, it really doesn’t do that much at all:

	
class first_state : public state {
  public:
     first_state(void) : state() { }
 
     virtual bool init(void) {
        return state::init();
     }
 
     virtual bool teardown(void) {
        return state::teardown();
     }
 
     virtual void progress(void) {
        std::cout << "progressing ..." << std::endl;
        _next.reset();
        _finished = true;
     }
};

Finally, we have the state machine. It is the kernel, the guy “in charge”. This will progress execution through the chain of states to ensure the story-board is presented to the user in such a way that they have a nice feeling of continuity throughout the game:

class state_machine {
  public:
     state_machine(void) { }
     state_machine(state *s) : _current(s) { }
     ~state_machine(void) { }
 
     void run(void) {
 
        if (_current)
           _current->init();
 
        while (_current) {
 
           _current->progress();
 
           if (_current->finished()) {
              _current->teardown();
              _current.reset(_current->next());
 
              if (_current) {
                 _current->init();
              }
           }
 
        }
 
     }
 
  private:
     boost::shared_ptr<state> _current;
 
};

To really make this of immediate use to a games programmer, I suggest the reader takes this code as an example and implements the following necessities:

Time management

Giving the programmer the ability to tell how long it was between frame renders or even being able to control the number of frames processed per second is a requirement. This is the heartbeat/lifeblood to giving your program the ability to exist in a human (or non-human) consistent time scale.

Eventing

Most media libraries define some sort of eventing to allow the library to interact with the hosting operating system. These interrupts or notion of “important incoming information” needs to be embraced into the state framework as one of the most important side-effects can come from external interation (keyboards, mouse, etc).

Enjoy.

Python and Relational Data Access

If there’s one job that I’m never keen on getting done, it’s the mind-numbing task of wiring up data access into my application. I’m a big fan of purely abstracted data objects just so the underlying data implementation can really be anything (within reason).

With all of the Flask development that I’m doing at the moment, it was hard to go past SQLAlchemy. Quite an old-school library to all the python-heads, but quite the lifesaver to me.

http://www.sqlalchemy.org/features.html