However, it is only tonight that I have managed to get the display working, because the character generator logic in the VIC-IV would seize up when trying to display variable-width full-colour characters. I eventually tracked the bug down to the paint_ready flag never being cleared if the VIC-IV was asked to draw a one-pixel wide 256-colour character.
This came about because the logic previously assumed that there would always be a 2nd-to-last pixel in a character, which is clearly not true when a character is trimmed to be just a single pixel wide.
Now that I have that fixed, I can finally draw variable-width anti-aliased* fonts. The following two screen shots are of the same Unicode string being rendered using 10 point and 20 point versions of the same font. You can get an idea of the size of characters from the grid of junk at the bottom of each.
Again, the matrix-like tint is due to the colour-cube approximation of the VNC viewer I used to capture the image. The characters look pure white on the VGA display.
Obviously the 20 point version (top) looks nicer than the 10 point version. That said, to my wooden eye, they both look pretty decent. The kerning looks acceptable, and both ascenders and descenders on characters are drawing fine.
I haven't optimised the unicode printing routine code at all yet, so it is still fairly slow to draw. Nonetheless, I can draw those several words in well under a frame, as can be seen in the following screenshot where I set the border to white while the drawing happens:
I also need to get around to implementing variable height characters, so that there are no large blank regions between lines when the upper rows of pixels in the top-most row of characters of a font are unused.
The other thing I hope to work on soon is to update the little programme I wrote to display the unicode text so that it can access fonts located outside of the first 64KB of RAM. This will use the new 32-bit indirect zero-page addressing modes. Then I will be able to display text from different fonts on the same display.
Nice! How realistic/hard would be to allow different video mode for different parts of the screen? Not with video interrupts to re-program VIC, but also eg a rectangular area of the screen. It would be great for some kind of "windowing system" to use fast and nice hardware based proportional text mode within a graphical window :) When I was child (with C64) I also wanted to design (well without too much knowledge anyway ... just dreaming) a computer optimized for some GUI like environment where there is map for - let's say - 8*8 pixel block with a "window ID". And each window would have video memory. So even windows overlapping, apps can still just write within their video ram slice, and video controller with the window map is responsible what to display at what position, no problem that a window is covered by another etc. But I guess it's still a bit too much to implement, maybe not even worth to do it in hardware. Well, just a child dream it is :-D
ReplyDeleteHello,
DeleteI hadn't really thought about this before, but I think that by using "super text modes" you get what you are describing for free. If you fix the tiles that are being used for each window, all that the windowing system needs to do is to pick which window is being displayed at a particular location, and show the appropriate tile from the appropriate window. This would allow window positioning on any 8-pixel boundary. The variable-width characters could also be used to allow windows to be placed at any horizontal position on screen. Arbitrary vertical positioning would be more difficult, but I think that just being able to do arbitrary horizontal positioning and 8-pixel vertical placement resolution would still be pretty effective.
Paul.
Paul,
ReplyDeleteIt seems that drawing those three lines of text currently consumes more than a third of the raster time. How much improvement do you expect to see if the code was optimised? How much of the time is overhead and how much is used per line?
Daniel.
The code is completely unoptimised. OVer half of the time is wasted with a linear search for glyphs, which can be replaced with a lookup. I think that I can get it to 10% - 25% of what it currently uses without too much trouble, and less again with some careful thought.
Delete