I think I'll also publish a second key on this page to the program I used to generate the data, so other fonts and stuff can be used with this.
Or just update the key instead.
Why don't you store the data in an actual DAT file?
What I would do is create 3 arrays:
DATA#[] holds all the data
START%[char] is the position in DATA% where that character's data starts
LENGTH%[char] is the length of the data for that character
(start/length could be a 2D array)
(and you could probably multiply all the coordinates by 8, so you can store them as integers instead of floats)
Replying to:
12Me21Why don't you store the data in an actual DAT file?
What I would do is create 3 arrays:
DATA#[] holds all the data
START%[char] is the position in DATA% where that character's data starts
LENGTH%[char] is the length of the data for that character
(start/length could be a 2D array)
(and you could probably multiply all the coordinates by 8, so you can store them as integers instead of floats)
Because loading the DAT file would take up a lot of space. I think it's like 2M bytes or something. For my purposes, it's extremely impractical. I need every byte of RAM I can get. I guess if you need every PRG slot you can get, you could DIM a bunch of arrays and load them all in the right order. Instead of restoring at a label, the routine could just read the VAR directly. Should be simple to fix if you need it.
Replying to:12Me21Why don't you store the data in an actual DAT file?
What I would do is create 3 arrays:
DATA#[] holds all the data
START%[char] is the position in DATA% where that character's data starts
LENGTH%[char] is the length of the data for that character
(start/length could be a 2D array)
(and you could probably multiply all the coordinates by 8, so you can store them as integers instead of floats)
Hmm. Yeah, that could be done. LENGTH% is redundant because the length can be the first value off the stack, which it is. But, because it's impossible to figure out the graphical length of a string of characters (without observing it after the fact), LENGTH% maybe could store the unit length of each character, which you would then add up and multiply by the scale factor to get the graphical length, which would be useful for doing things like fitting the text inside text boxes.
Edit: the function could maybe even use that info to backtrack and fill an x,y,u,v space with text. Might be more useful.
Replying to:12Me21Why don't you store the data in an actual DAT file?
What I would do is create 3 arrays:
DATA#[] holds all the data
START%[char] is the position in DATA% where that character's data starts
LENGTH%[char] is the length of the data for that character
(start/length could be a 2D array)
(and you could probably multiply all the coordinates by 8, so you can store them as integers instead of floats)
(the reason for storing LENGTH% separately is so you can use an integer array and save space)
If you really want to save space, you could store each value using 6 bits or something (they seem to all be multiples of 1/8, from 0 to 7.75), by multiplying them by 8 (giving a range of 0 to 62)
You could also fit the data on one of the graphics pages, probably
Replying to:12Me21Why don't you store the data in an actual DAT file?
What I would do is create 3 arrays:
DATA#[] holds all the data
START%[char] is the position in DATA% where that character's data starts
LENGTH%[char] is the length of the data for that character
(start/length could be a 2D array)
(and you could probably multiply all the coordinates by 8, so you can store them as integers instead of floats)
Ooh yeah, but saving space is only half the problem, really. It's also a trade of fast recall. Restoring at labels and accessing VARs is quick enough, but you also want to access and draw the information relatively quickly. Doing clever bit manipulation takes time, and bitwise operations seem notoriously slow. Also, yeah, the 1/8 thing was handy, but it really doesn't need to be that way. The integer part of the value stores the Y component, and the fractional part the X (X=FracPart*8). Could make them two separate values or just Y*8+X the thing and do X=N MOD 8, Y=N DIV 8. Might actually be faster too, idk. But if you're going the array route, it would be better to DIM an integer array.
Replying to:12Me21Why don't you store the data in an actual DAT file?
What I would do is create 3 arrays:
DATA#[] holds all the data
START%[char] is the position in DATA% where that character's data starts
LENGTH%[char] is the length of the data for that character
(start/length could be a 2D array)
(and you could probably multiply all the coordinates by 8, so you can store them as integers instead of floats)
How do you think the data will fit on the graphics page? GSPOIT calls don't seem too slow.
Replying to:12Me21Why don't you store the data in an actual DAT file?
What I would do is create 3 arrays:
DATA#[] holds all the data
START%[char] is the position in DATA% where that character's data starts
LENGTH%[char] is the length of the data for that character
(start/length could be a 2D array)
(and you could probably multiply all the coordinates by 8, so you can store them as integers instead of floats)
I'm sure it's faster to use bitwise operations than it is to calculate the integer/fractional parts of a number.
You could use RGBREAD to split an integer into 4 bytes, then split each of those into X and Y
(this would use only ~0.2MB of RAM)
Replying to:12Me21Why don't you store the data in an actual DAT file?
What I would do is create 3 arrays:
DATA#[] holds all the data
START%[char] is the position in DATA% where that character's data starts
LENGTH%[char] is the length of the data for that character
(start/length could be a 2D array)
(and you could probably multiply all the coordinates by 8, so you can store them as integers instead of floats)
How do you store it on the graphics page though? The graphics page doesn't care for the alpha channel unless it's 255. I admit I don't know much about the whole color conversion stuff, but it seems that storing on the graphics page is a bit lossy. It stores what looks like 5? bits for each channel, instead of 8. RGBREAD handles the whole 8 bits though, so it seems like a color conversion thing.
I'm actually interested in learning this because it opens a door I really hadn't considered. I mean, 512x512 and like what, 6 pages. Holy crap. If I could make a function that could manipulate data on the graphics pages at decent speeds, that would be super useful.
I think this is the longest I've ever seen it take for a program to compile in SB (~7 seconds!)
Replying to:
MZ952I think I'll also publish a second key on this page to the program I used to generate the data, so other fonts and stuff can be used with this.
Or just update the key instead.
I take it your vectorizing algorithm was to make straight strokes between adjacent pixels and connect the segments where it's more efficient?
Replying to:MZ952I think I'll also publish a second key on this page to the program I used to generate the data, so other fonts and stuff can be used with this.
Or just update the key instead.
Yeah basically. But, it didn't connect all adjacent segments, because sometimes that would make certain characters appear wonky. I think I let it connect segments up until a junction or something.
Edit: oh wait, this one might be the set without the condensing. I think my reasoning was that by condensing I was losing detail on upscaled text. Huh. I see now that there are only a few edge cases to correct for. I might be back with an update.
Replying to:12Me21I think this is the longest I've ever seen it take for a program to compile in SB (~7 seconds!)
Wdym? Are you running the O3DS? Takes negligible time for N3DS.
Replying to:12Me21I think this is the longest I've ever seen it take for a program to compile in SB (~7 seconds!)
On n3ds it's a lot less (still extremely long, though)
Replying to:12Me21I think this is the longest I've ever seen it take for a program to compile in SB (~7 seconds!)
Yeah, but it's only a one and done sort of thing. I'm surprised it's so long on the O3DS though. Reminds me that I need to do some O3DS testing on my stuff.
There's an typo in the code. I'll update the key later, but if you want to fix it, replace all instances of "1:CHR1" with "1:@CHR1".
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.
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.
Hmm yeah, this would be great. Some things will have to be modified to use BIG font, mainly how the data is encoded. The drawing function can pretty much stay as it is. What I think I'll have to do is introduce a flag for either 8x8 or 16x16 font. I'll be back with an updated key.
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.
Okay, DF43EKD
Let me know if it actually works. I expect things like underlining and striking to be wonky, I'll have to fix those.
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.
For potential future-proofing of whatever weird font or SB implementation there is, you should just store a number in the font that says what the source font width is. It is definitely possible to load a font of a variable size (I managed it in my edit) but I didn't understand the algorithm enough to fix it lol
