Fonts

As per-pixel access is deemed too bandwidth-intensive for SMP, I hereby purpose an alternative - fonts. This would be exposed via a hypothetical Font API, detailed below.

• Font.getFont()
• returns the string path to the current font.
• The default font would be in the rom directory somewhere - perhaps "rom/font"?
• Font.setFont(string path, boolean blocking)
• sets the current font on the current computer to the font file at path, returning a boolean representing if the font load was successful.
• This is only allowed to be executed once per second - additional calls will either return false (if not blocking), or sleep until the delay time is up (if blocking is true or nil).
• When it is executed, (either of these - dunno which would be better) {the screen will be cleared} {existing characters will be redrawn with the current font}.

Additionally, it would be nice to have a way of directly setting a font from a binary array, and an easy way of both reading a file into a binary array and writing a binary array into to a file. (The reason I did not include these is that they would either have to use a binary array (which would be rather memory-inefficient) or would have to use a bitset, and there is no bitset API currently.)

A font file is a flat 1-bit bitmap, of size 16wx14h characters, or 128wx112h pixels, stored in row-major L-R T-B order. This allows for every non-control character to be represented. Each font file is thus 1792 bytes, or 1.75kb. Ones represent the foreground color (white on normal computers), and zeroes represent the background color (black on normal computers). The character index starts at character 32 at the top-left, and extends in reading order (L-R then T-B)/>.

Note that this would allow basic 2x4 sub-pixel rendering while leaving room for the standard characters, assuming one had the proper font file and rendering code.

It wouldn't have issues with either rendering or data transfer, as (assuming font changes are limited to 1/s) there would be a maximum of 1.75kb/s/computer (+ packet overhead) of extra data transfer.

I don't know about fonts, but definitely adding additional character support, which has been discussed before.

I think this would be a pretty cool idea. And you've put some thought into it which is always a good thing.

Cranium, on 19 January 2013 - 08:59 AM said:

I don't know about fonts, but definitely adding additional character support, which has been discussed before.

Do you know what code page would be used?

iownall555, on 19 January 2013 - 02:02 PM said:

[…] you've put some thought into it which is always a good thing.

It is generally considered better than the alternative, yes…

Cranium, on 19 January 2013 - 08:59 AM said:

I don't know about fonts, but definitely adding additional character support, which has been discussed before.

Are you talking about using the full range of characters already available in the default Minecraft font? If so, was there any response from anyone official on it? Box drawing characters plus the new Advanced Computers/Monitors for color could make for loads of expressive programs. Not to mention the gradient glyphs adding limited color mixing for prettier pictures.

RestfulMonad, on 25 January 2013 - 05:53 AM said:

Are you talking about using the full range of characters already available in the default Minecraft font? If so, was there any response from anyone official on it? Box drawing characters plus the new Advanced Computers/Monitors for color could make for loads of expressive programs. Not to mention the gradient glyphs adding limited color mixing for prettier pictures.

I beleive it was stated that additional language character is planned, for those who have needs regarding their languages' keyboards. But beyond that, I don't know as we are looking into anything like you are talking about. I might be wrong, but that's what I got from that discussion.

It was a while back, but I mentioned here that I suspect the issue was with the call to ChatAllowedCharacters used to translate character values to texture coordinates. Not sure if the codebase around that sort of thing has changed recently, but that function strips out almost anything non-alphanumeric or punctuation from the characters it's given and replaces then with '?'. Quite nice for chat sanitation purposes but not so much for would-be artsy programs.

Writing a simple program that attempts to print character codes 0..255 on screen reveals a lot of question marks surrounding a thin band of letters. I'm not sure if there's a better translation function to call, but unlocking the full range of characters that come in the default Minecraft font sounds like an easy win in my humble and inexperienced opinion. :)/>

I'm all for supporting the 0-255 characters. Or even slightly less, with the 'unneeded' characters left out of it.

Just out of curiosity what characters you consider unneeded? :D/>
śćżźłęą per example ? :P/>

A problem with having font files stored in the filesystem of a CC computer would be supporting SMP. The font is a texture, so it's needed client side. While on SMP, the filesystem is mounted on the server side.

wojbie, on 25 January 2013 - 10:09 AM said:

Just out of curiosity what characters you consider unneeded? :D/>
śćżźłęą per example ? :P/>

♣♦♠♥ <–those types of symbols.

Cranium, on 25 January 2013 - 11:06 AM said:

wojbie, on 25 January 2013 - 10:09 AM said:

Just out of curiosity what characters you consider unneeded? :D/>
śćżźłęą per example ? :P/>

♣♦♠♥ <–those types of symbols.

That's unicode, right? I don't think it's in the extended ASCII set.

BAh, I have no idea. I have had my brain thrown through a blender in the last few days after becoming moderator, managing the CCU server, and work. I need a weekend…. :P/>

Cranium, on 25 January 2013 - 11:23 AM said:

BAh, I have no idea. I have had my brain thrown through a blender in the last few days after becoming moderator, managing the CCU server, and work. I need a weekend…. :P/>

Well, you can have a weekend at 2000 posts. :P/>

MudkipTheEpic, on 25 January 2013 - 12:07 PM said:

Cranium, on 25 January 2013 - 11:23 AM said:

BAh, I have no idea. I have had my brain thrown through a blender in the last few days after becoming moderator, managing the CCU server, and work. I need a weekend…. :P/>

Well, you can have a weekend at 2000 posts. :P/>

And throw a kickass party…

Party in 4 more! Woo

Back on topic, since what I posted was totally wrong, the extended ASCII set(I did lookit up this time…..) would be great to have added to CC. Heck, I would settle for the lowly tilde ( ` ).

IIRC LuaJ has some problems with 8bit values in strings… We've had those problems with the http API, rednet and the fs API when not using binary mode. It just doesn't like strings of unsigned chars or something…

Well, since Dan said they are trying to move away from LuaJ, hopefully we can see an addition of more character support when that happens?

Orwell, on 25 January 2013 - 12:19 PM said:

IIRC LuaJ has some problems with 8bit values in strings… We've had those problems with the http API, rednet and the fs API when not using binary mode. It just doesn't like strings of unsigned chars or something…

That was my first guess, that it was discarding my characters at the Lua level. But I recall being able to craft a string containing non-alphanumeric characters and roundtrip them back to the right integers via string.byte and string.char. I do believe the root of the problem is the function ComputerCraft uses to map characters to texture coordinates in the default font: ChatAllowedCharacters. Last I checked MCP, that function specifically disallows all sorts of non-texty letters and shunts them to ?s.

Though the last I peeked at a decompilation of ComputerCraft was when I posted my first suggestion and there've been a lot of releases since.

RestfulMonad, on 25 January 2013 - 01:31 PM said:

Orwell, on 25 January 2013 - 12:19 PM said:

IIRC LuaJ has some problems with 8bit values in strings… We've had those problems with the http API, rednet and the fs API when not using binary mode. It just doesn't like strings of unsigned chars or something…

That was my first guess, that it was discarding my characters at the Lua level. But I recall being able to craft a string containing non-alphanumeric characters and roundtrip them back to the right integers via string.byte and string.char. I do believe the root of the problem is the function ComputerCraft uses to map characters to texture coordinates in the default font: ChatAllowedCharacters. Last I checked MCP, that function specifically disallows all sorts of non-texty letters and shunts them to ?s.

Though the last I peeked at a decompilation of ComputerCraft was when I posted my first suggestion and there've been a lot of releases since.

I'm not saying it's at Lua level. Also, I'm not denying there's a problem with the mapping on the MCP side. All I know is that there are some problems in LuaJ with passing strings and that this occurs throught the fs/http/rednet API. Normal string manipulations worked just fine for me as well.

If MCP explicitly shunts characters to ?'s using ChatAllowedCharacters, then it can't be a coincidence that this happens with displaying them in CC; you're probably right about your hunch then I'd say.

Orwell, on 25 January 2013 - 01:38 PM said:

All I know is that there are some problems in LuaJ with passing strings and that this occurs throught the fs/http/rednet API.

Are the workarounds in plain Lua inside the rom folder? I'm simply curious what had to be done at this point.

There are no workarounds as far as I know. :)/> I recently had to download a binary file through http and I ended up using base64 because it always cut of the 8 bit. Actually, it did even weirder stuff IIRC, but never contained values higher than 127. Try sending string.char(255) over rednet and see for yourself. :)/> I think it's still bugged. Some of the bugs in CC come from LuaJ and we just have to deal with them for now. :(/>

How about an API to be able to draw pixels on an individual basis? That way you could maybe form different fonts with hard work.

Aquilamo, on 30 January 2013 - 01:52 AM said:

How about an API to be able to draw pixels on an individual basis? That way you could maybe form different fonts with hard work.

graphics mode has been denied many times

Cranium, on 25 January 2013 - 12:16 PM said:

Back on topic, since what I posted was totally wrong, the extended ASCII set(I did lookit up this time…..) would be great to have added to CC. Heck, I would settle for the lowly tilde ( ` ).

thats called a grave accent
a tilde is a ~

Damn…. then I failed twice.

i call it a squiggly :D/>
so does cave story's key configuration

I think that CC need support this chars: ñ, á, é, í, ó, ú. You can write them in the computer gui but you cant download them with http api and they are a bit buggy. I'm trying to make localization to my OS and I can't because this.