Replies: 4 comments 3 replies
-
I think only CCharGenerator has to be changed. The different provided fonts do
not need to be changed, because any font storage can be seen and defined as a
simple byte stream. One can use rFont.width in
CCharGenerator::CCharGenerator() to set a new member variable
m_nBytesPerPixelLine as:
m_nBytesPerPixelLine = (rFont.width + 7) / 8;
In CCharGenerator::GetPixelLine() a switch() statement can be used for the
different values of m_nBytesPerPixelLine (1, 2, 3 or 4) to return the font data
in the right format.
Of course the definition of TPixelLine has to be changed to:
typedef u32 TPixelLine;
I don't know, if this description is clear enough. If not, I can also provide
the modified code for CCharGenerator.
|
Beta Was this translation helpful? Give feedback.
-
Forgot to mention: On Raspberry Pi 1-4 and Zero (2) you can set nearly any wanted display resolution, for example 640*570 using |
Beta Was this translation helpful? Give feedback.
-
The class |
Beta Was this translation helpful? Give feedback.
-
Thanks! That's working nicely. Regarding using a resolution like 640x570. The monitor I'm using has a native resolution of 1024x768. When you use a lower resolution for the frame buffer the fonts are distorted a little so it doesn't look as nice as a higher resolution font with the frame buffer using the native resolution. If I was using a modern high resolution display I think setting the frame buffer to 640x570 would make more sense as it would still look nice and there wouldn't be the performance penalty of rendering so many pixels. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, I'd like to use the CScreenDevice class with a 12x24 or a 16x32 font.
My goal is to use the 12x24 font on a 1024x768 monitor to get a console close to 80x30 or use a 16x32 font where the resolution is greater than 1024x768.
I don't believe CCharGenerator will support this because each row in the font_data array is 8 bits wide (char).
I could use the width and height doubling for the 16x32 font, but doubling a 6x12 font will produce a low quality font compared with a native 12x24 font.
I think the easy fix would be to change the fonts to use a u16 or u32 for storing font_data.
An alternative would be to allow passing a custom CharGenerator class to CScreenDevice.
Have I missed a better solution?
If there is interest, I can try and submit a pull request changing the font storage to u16 or u32?
Beta Was this translation helpful? Give feedback.
All reactions