Framebuffer Console Requirements

So far, at least 4 different people have written framebuffer console libraries, and suggested that I merge them into psl1ght.

I've rejected all of them, not because they were bad but, mostly because they were all inflexible with fixed size fonts and wouldn't meet peoples future needs.
Rather than contentiously rejecting framebuffer libraries as everybody and their dog writes them, I thought I should explain my requirements and the reasoning behind them here.

It must not have any dependencies on psl1ght.
If psl1ght ever gets ported to another platform, or I just need a framebuffer console for a pc game I'm making, the library has absolutely no reason to complain. Also, if the library directly calls flip, tries to initialize the rsx or manage memory then its just going to get in the way when things change down the track (for example, rsx support)
Dependencies on external libraries are fine, but if they are bulky, developers might be reluctant to use your library.

No fixed font sizes.
I want to be able to read my debugging into from my couch on my 1080p screen, it would be really nice if the console library dynamically scales the text, but allowing the developer to select the font size at compile time would be enough. Using libfreetype (from ps3libraries) would make this really easy, but I'm not going to make it an requirement.

Flexible console and render target(s).
The developer shouldn't be limited to the size of their screen (or a small console centered in the middle), they should be able to specify the width/height of the console to be anything along with the format of the framebuffer supporting it. This will include the pixel format and line stride (number of pixels to skip at the end of each line.) This will allow the developer to have their own graphics on the screen, and a console taking up (for example) just half of the screen. Also, when the rsx is working, the developer will probably want to render the console to a texture (which might be 8bit grayscale, 16bit color format or 32bit color with alpha) which gets rendered to the screen later.

Double buffering.
Who knows how many buffers the developer will be using, the ps3 supports upto 8. The framebuffer library shouldn't care, and just take a memory address of the buffer to render to each time the render function is called.

No global variables.
The console library should be flexible enough so that developer will be able to multiple consoles running at once. This means that each call to the console library will start with a struct containing the state of that console.

Transparency.
The developer will probably want to write debugging text over what they have already written on the screen. The console library should allow the developer to select a transparent background or foreground color which will cause the console library to not touch those pixels. Related to this, the console library should never clear the buffer before it writes in it, if the developer wants the buffer cleared, they can call the clear function themselves.
Optionally, the console library might support alpha transparency, which would look cool.

Reading from the framebuffer.
The console shouldn't read the contents of the framebuffer, because reading from the rsx memory (where the framebuffer may or may not be) is extremely slow.
There is an exception to this for alpha blending, where you are allowed to assume that the developer is rendering to the main memory (or doesn't care about speed) if they are using this option.

Non-Scrolling text.
The library should may it easy to render a single line of non scrolling text onto the screen, for example a fps counter. I don't really want to have to setup a console and link with ncurses to get this feature.

These requirements will allow for maximum flexibility and future proofing, especially with rsx support coming.
If your library meets the requirements (or is very close to meeting the requirements), I'll be happy to merge it into psl1ght.

-- Scott Mansell (aka phire, phiren, phirenz)