How do people feel about the idea of a permanent text-only screen mode, present no matter which other screen mode is being used?
I assume that the file menu is using direct pixeling to display the text, but if we use a 1bpp tiled mode, possibly with a colour map, it should have very little footprint and I assume would feel a lot smoother.
Each screen mode would have to render/blend the text buffer into the frame buffer before copying to the screen. Unless there’s lots of text being overwritten many times per frame, how would it be better?
No, it would be an either/or situation. Just set a bool and the render routine would render the tilemap OR it’s own native gfx. You know, like
if(textOnly==true){
// render text screen
}else{
// render normal screen
}The render routine would be very small, as would be the text tile map.
Ah, I see. It’s like having multiple modes, but one is text-only.
The text tile map could occupy the same space as the framebuffer, for zero memory overhead.
With a few modifications to PokittoLib, it can be implemented on top of tiled mode as a lib so as to not take flash space from those who don’t use it. I imagine it would be pretty fast, good for ascii-art games.
I don’t think the file browser would benefit much, the limiting factor there is SD card access.
EDIT: Have to do the math, the text tile map is not going to be that small, especially if it can have different colors.
26x22 array for the tiles map, same for colours, although, the colours could be limited to 4 or something, so pack multiple tile colours into a byte.
You want direct text and a graphics mode on the same screen?
More like have a text mode accessible no matter what screen mode is being used.
disable automatic screen refresh and you can use direct mode text and manually call the screen modes refresh wen you need it?
The problem with a “text mode accessible no matter what screen mode is being used” is that text is typically stored as bitmap data, so it’s going to be affected by the resolution.
You could use a vector font,
but that would be costly to use at runtime.
You could use a vector font but draw it to a bitmap at startup and then use that as a bitmap font,
but that’s going to have more memory overhead (vector drawing functions + bitmap drawing functions).
The fundamental issue is that every time you try to make any kind of graphics feature ‘graphics mode independent’,
there’s always going to be a cost for that.
Programming is inherantly requires making tradeoffs.
Speed, memory, easy of use - rarely are you allowed to keep all three.
You could have an interface that works regardless of graphics mode, but the most optimal solutions will require different implementations.
E.g. 4x8 font for 110x88 modes and 8x16 font for 220x176 modes.
(It may be possible to make the compiler do the vectorisation of the font at compile time,
but it would require a substantial amount of template voodoo.)
on this scale we just have a set of baked fonts in every size you need though i assume you always want to go with the full resolution screen for a graphics mode since you drawing directly to screen so more like
header/title , regular, cursive and bold font if you want to be fancy i guess
I would assume that the C64 font is already present for the current file loader?
Yea I think there a few fonts around from old gamebuino aswell
And might want to look at uc8lib (an Arduino library) they had a few fonts as well