28 replies to this topic

[The Lone Wolfling]

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-.

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.

[Cranium]

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

[iownall555]

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

[The Lone Wolfling]

 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...

[RestfulMonad]

 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.

[Cranium]

 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.

[RestfulMonad]

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.

[Cranium]

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

[Wojbie]

Just out of curiosity what characters you consider unneeded?
śćżźłęą per example ?

[Orwell]

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.

[Cranium]

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

Just out of curiosity what characters you consider unneeded?
śćżźłęą per example ?

♣♦♠♥ <--those types of symbols.

[Orwell]

 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?
śćżźłęą per example ?

♣♦♠♥ <--those types of symbols.

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

[Cranium]

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....

[MudkipTheEpic]

 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....

Well, you can have a weekend at 2000 posts.

[Orwell]

 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....

Well, you can have a weekend at 2000 posts.

And throw a kickass party...

[NeverCast]

Party in 4 more! Woo

[Cranium]

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 ( ` ).

[Orwell]

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...

[Cranium]

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?

[RestfulMonad]

 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.