I was feeling bored the other day, so I decided to write something to fake a console output using SDL. Here's a screenshot:
And, what the hell, here's the lame source (with a project file for Visual Studio 2010):
http://files.spectere.net/projects/sdlconsole/sdlconsole-20100622.zipAnd, finally, here's a binary for people without development environments or who don't want to deal with the hassle of building it:
http://files.spectere.net/projects/sdlconsole/sdlconsole-20100622-bin.zipThe demo project is very simple. All you do is move the guy around the screen. There is no collision detection to speak of, and Mister Smiley will erase whatever he passed through. What a jerk.
Here are a few features that it has:
* Ability to manipulate the character set and palette.
* Can load character sets and palette files from
MegaZeux.
* Supports arbitrary screen sizes (i.e. 60x25, 130x60, whatever your little heart desires).
* Updates the screen immediately when the palette or character set is changed, just like an actual EGA/VGA display would.
* Generally works fairly well.
Here are a few little caveats:
* There is almost no error checking to speak of. Getting it to crash is trivial if you do certain things wrong.
* Character sizes are fixed. This is mainly due to laziness and a desire to get the sucker working.
* Some of the code is just nasty. I guess that's what happens when you only spend a few hours developing it and are mildly intoxicated while you do so, with the only objective being that I have something to show myself when I wake up the next morning (example: I abuse bit shifts at times and have a few borderline-unmaintainable lines, like so: "if((curChar.Row[y] & (1 << (CHAR_WIDTH - x - 1))) > 0)"). It does make sense, given what I'm doing, but it's ugly as sin.
* A ton of stuff is hard coded. I originally planned to support arbitrary character sizes, but I just decided to stick with an array of bitmasked rows for each character, since that's the format that MegaZeux character set dumps use.
*
There is almost no error checking to speak of. Go ahead, plot a character outside of the screen buffer. I triple dog dare you.
* It's about as optimized as a sloth's movement. Right now it uses an array of arrays to handle the screen buffer. I'm pretty sure I'd be better off with a single array. There's also a number of things that I could probably do to make the code more sane and quick. Meh, maybe later.
* Updating the palette or character set redraws the entire screen. If I continue to refine this, I'll probably have it scan the character and color maps and only update blocks that have changed. Due to its nature, it's rather slow at the moment.
* There is no support for updating lists of blocks (which would help with the above optimization idea). Unless you're updating the entire screen or a contiguous group of blocks, the program will basically lock the buffer, draw the character, unlock the buffer, and continue to repeat. The ability to give the program a list would remove the need to continually lock and unlock the buffer.
* Finally, I need to store and utilize the character set in a better way. What I'm doing right now just sucks.
That said, this is probably the most substantial C++ project that I've started. How sad is that?
