The TextViewer class now just uses a vector of 32-bit line start points to represent its wrapped text. That saves another byte per line, or 64K in the previous example (taking the total mapping data down to 256K). Not as good as just storing the line lengths (that would reduce the mapping data to 64K), but a lot easier to code, and potentially a lot quicker if large scrolls are performed (it’s possible to jump from one end of those 65,536 lines of text to the other using the class’ methods, which would result in 65,536 loop iterations to work out where the target line started).
I took the opportunity to tidy up the code at the same time and split things out into separate functions, and it’s much simpler to follow the flow of the code now. Also, the wrapper code is now a one-pass algorithm instead of two-pass, which makes it a lot quicker.
I’ve changed a few other things, too. The TextWriter now just contains static methods, instead of needing to be instantiated. All of the classes now work with their font data in an improved Font class, and font pointers are passed through the hierarchy by the main Woopsi class (this is preparatory work for allowing developer-defined per-gadget fonts). I’ve removed the redundant 8-bit code from the Bitmap class.
There’s another optimisation in the TextWriter - it now bypasses any glyphs in the font that do not contain any visible pixels. To do so, the font’s constructor builds up a bitmap in which a set bit represents a visible glyph, and an unset bit represents an invisible glyph. The constructor loops through the pixels within each glyph, and if it detects a visible pixel, sets a bit in the bitmap. If it doesn’t find any visible pixels, the bit is left unset. As there are only 256 characters in the extended ASCII set, the bitmap only uses 32 bytes to represent the data.
When the TextWriter is told to write a character, it checks the relevant bit to see if it is set not. If not, it leaves an empty space and skips straight to the next character in the string. I got to do some more bit mangling - hurrah!
The Font class no longer needs to work with images that are 256x192 pixels; it can work with images up to 65,536x65,536, as long as its dimensions are multiples of the width and height of a glyph. The maximum font size is 256x256, which would mean each letter is slightly too large to fit on the DS’ screen.
One last change. The TextWriter now accepts a pointer to a bitmap in its draw functions instead of a screen number, so it is ready to be used in the SuperBitmap gadget.