The problem with development blogs that try to keep up to date is that a lot of the posts tend to be nothing more than the changelog with comments. That’s the problem with this blog, anyway, so I apologise for regurgitating the changelog. It’s useful for me, though, plus it lets me add emphasis to changes that will break all of your code, such as the latest font changes.
Back to the latest SVN changes. The Font class now accepts const u16* bitmap data instead of plain old u16*, so the const-ness of PAGfx data no longer has to be cast away.
The SuperBitmap class has two new functions - “newBitmapGraphicsPort()” creates a GraphicsPort object that can write to the SuperBitmap’s buffer. Might be handy for something, but I’m not going to delete the existing SuperBitmap drawing routines as they’ll be much faster (they don’t run through the clipping routines). It’s got a “drawBitmap()” function too, which will blit a bitmap (or portion thereof) to the buffer.
At the moment, the SuperBitmap can either be passed an existing bitmap in its constructor to use as its buffer, or it can create one itself. This is mainly to enable the use of PAGfx bitmaps as images. However, the big problem with this is that the SuperBitmap can’t write to the PAGfx bitmaps - they are arrays of constants. The drawing functions don’t check to see if they’re trying to draw over consts, which will probably cause unpredictable things to happen.
There are two solutions to this - either make the drawing functions check if the bitmap is internal (u16) or external (const u16) before trying to draw anything. The other alternative, now that the drawBitmap() function is done, is to strip out the whole external bitmap concept and make the SuperBitmap always create a new image. Uses more memory (96K for a full-screen bitmap), but makes more sense.
And while I think about it, I should have renamed the “Gradient” gadget to “CopperList”. Heh.
Also, I can update the TextWriter class to output in a specific colour by doing something like this:
u16 oldColour = Font->getColour(); font->setColour(newColour); drawText(text); font->setColour(oldColour);
And another idea. I already scan each glyph in a font when it is constructed to see whether or not that glyph contains any non-transparent pixels. It would be trivial to extend that function so that it spots empty columns in a glyph, and stores the number of populated columns. If I know the number of populated columns in a glyph, I can have non-fixed width fonts. I could even scrap the current method of storing the populated/unpopulated information, and rely solely on the width - if the width is 0, I can just ignore that glyph (and assume its width is the nominal width of the font for text size calculations).