Hi everybody,
- For the wish list: A more compact representation of fixed-width fonts. A font definition has a pointer for every character. If the characters have a fixed with, and are contiguous, the pointer table is a waste. And as I have a font with nearly 20,000 characters, then I'm simply not allowed to have 20,000x4 bytes of wasted space. I use a font representation without pointer table, wich I could submit if you find it useful.
- I'm started using the Win32 driver from Peter Gerwinski. I'm very pleased with it (thanks Peter). But I'm having some problems with the colors: when I do a bitblt from the screen to memory and then back to screen some colors are lost. Perhaps it's a problem with the palette, I don't know, I'm working on it right now.
- The frame driver I've written (I call it ram4n, for 'non-planar') is not an improvement over the standard ram4 driver. Both of them use 4 bits to represent a pixel, but they are different in the physical organization of those 4 bits. -The standard driver has 4 planes (R G B and bright, if I'm not wrong), and a pixel has one bit in each of the planes. For example, to know a pixel's color, you have to read one byte for plane, pick the bit you are interested in, and then reassemble the 4 bits in a GrColor variable. This is a very nonintuitive and slow way of manipulating pixels. It's advantage is that tha VGA hardware is structured that way, and then pixel manipulation becomes very quick (for a video context, not for an in-memory context). - My ram4n driver has only one plane, and the 4 bits of a pixel are contiguous, that is, in every byte there are 2 pixels. To manipulate a pixel you read a byte, change the upper or lower 4 bits, and write it back to memory. Although this organization is unusual in PCs, I've seen it in other graphics systems that are not VGA. In fact I use it in a PowerPC 823.
And that's all. Sorry for the verbosity :-)
Greetings,
Josu