LoginLogin
Nintendo shutting down 3DS + Wii U online services, see our post

CHRVEC_2

Root / Submissions / [.]

MZ952Created:
Download:53KK33LY
Version:Size:
DRAWTEXT StartX, StartY, EndX, EndY, Text string, Color code Fills a rectangular space with vector-drawn text. (Not quite the same as GPUTCHR, which uses scale factors as arguments.) The new key contains the DEF block for drawing text, the vector data of the default font, and the algorithm used to create the vector data. You can use the algorithm to create your own font data to use with this. You can italicize, strike, and underline by introducing [I/]...[/I], [S/]...[/S], and [U/]...[/U] within your text. Example, DRAWTEXT 5,5,60,10,"[U/]Hello, world![/U]",#WHITE. You can also use any combination of strikes, italics, and underlines: DRAWTEXT 5,5,150,10,"[I/][S/][U/]Striked Underlined Italics![U/][/S][/I]",#WHITE. Compared to version 1, version 2 uses an entirely different algorithm to vectorize the text. It draws using a lot less lines and the data loaded into the slot is a lot more compact. It covers all characters up to CHR 65535 and occupies ~0.3 MB.

Instructions:

Running CHRVEC_2 produces the example. You can copy the def block to your own code, but just remember to bring along the global variable CHRVECSLOT and its associated code, as well as CHRVEC.DAT (or your own created .DAT file) to your project folder. Changing CHRVECSLOT changes what slot the data is loaded into.

Replying to:snail_
Could it be possible to tweak the generator to take a font GRP of any size? Primarily I want to try generating a font using the BIG 16x16 font (theoretically it would be higher quality) but all of my hacking of the generator just produces broken output. Clearly both the generator and the draw function rely on the font source being an 8x8 bitmap, which is unexpected.
Yeah, I'm definitely considering that, variable M x N font size is what I'd like. I've considered writing a whole set of functions in the past that redefined SB's font definitions, externally of course. So, for example, you could proceed linearly with CHR$(I) and never run into a CHR$(1) kind of blank character. I don't understand the logic behind how SmileBASIC assembled their font table, but it all seems so damn needless to me. Anyway, yeah, I don't like being constrained by SB's wonky setup and this CHRVEC thing I made a while ago was a step in that direction. Also, if the thing worked, would you mind making a key to the generated BIG font? (Or does there exist somewhere on this site the GRP BIG font page?)

Replying to:snail_
Could it be possible to tweak the generator to take a font GRP of any size? Primarily I want to try generating a font using the BIG 16x16 font (theoretically it would be higher quality) but all of my hacking of the generator just produces broken output. Clearly both the generator and the draw function rely on the font source being an 8x8 bitmap, which is unexpected.
The CHR$(1)s are just what happens when a unicode character doesn't have an associated glyph in the font (which is actually U+FFFD � REPLACEMENT CHARACTER.) The character encoding is 16 bits (65536 codepoints) but a GRP can only hold 4096 8x8 cells so they just had to shove it all in somehow. Pretty much every undefined character in SB is some weird unicode character they didn't have room for, or a nonprinting/control character.

Replying to:snail_
Could it be possible to tweak the generator to take a font GRP of any size? Primarily I want to try generating a font using the BIG 16x16 font (theoretically it would be higher quality) but all of my hacking of the generator just produces broken output. Clearly both the generator and the draw function rely on the font source being an 8x8 bitmap, which is unexpected.
Oh that makes sense. Guess I just needed it explained a certain way, haha. Ah well, my point is still that a custom font definition template could be made for custom characters, i.e., not every character needs to be some constant N x N square, but variably M x N, and we could store and use a lot more than 4096 characters in a DATA list. This is a while down the road though because I have no ambition to make it yet. Maybe when SB4 rolls around...