OS Development Links
18 Nov 2012Over the past couple of months, I’ve compiled and refined a list of links that have been of assistance though my OS development journey.
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.
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!
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.
I’d previously been doing things very long-hand up until now.
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:
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.
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.
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.