Unicode capable font renderer about opencomputers HOT 11 CLOSED

There has been a short discussion about adding support for custom fonts on the IRC a few days back, which, if it ever makes it in, would probably also solve this issue. I'll dump the links that were mentioned for future reference for myself here.

• http://www.minecraftforum.net/topic/821163-api-custom-font-engine/
• http://pastie.org/private/int6z1x6zgri8ju74r59w

This would come with a rewrite of the whole monospace font renderer, I think, so it's something somewhere in the relatively distant future.

from opencomputers.

I've pushed what I have of an attempt at a unicode capable font renderer, but it's pretty broken still (chars are point mirrored), and most importantly, rendered chars look terrible. If someone wants to pick it up and work on it, that'd be great.

Here's how it works at the moment: the class linked above keeps track of N textures containing rendered chars, and keeps track of a map for looking up texture and uv coordinates by char. In a pre-rendering step, chars are checked to be in one of these textures. If a char is in no texture yet, it is rendered into the last one if there's still room, else a new texture is created. The rendering is done into a RenderBuffer and then copied into the actual texture. This is done before the main rendering step, to avoid these calls getting into a display list. In the main rendering step, textures are bound one after the other, rendering each character from the buffer to be rendered that is in the currently bound texture. This is to minimize texture rebinding, because that's sloooow.

To enable the dynamic font renderer change these lines.

I'm putting this on hold for a bit. Again, if someone else wants to look into this, that'd be great, but please let me know when you get started, to avoid redundant work, thanks!

from opencomputers.

On the topic of font rendering, would it be possible to create custom characters by using a table of bytes? An example would be:
{129, 129, 129, 129 (..continuing on until it's at the width of the character, I forgot the actual number) }

It would create a line at the top and bottom of the character, since 129 is {
1,
0,
0,
0,
0,
0,
0,
1 }

from opencomputers.

Yes, I've been thinking about user-definable 'glyphs' (similar to how there are now color palettes in 1.3), and it's an intriguing idea - but I feel it's going a little over-the-top for the screens. That would better be served in an extra component / via an addon, I think.

from opencomputers.

Bitwise acces in lua is a PAIN, so that wouldnt be fun either...

from opencomputers.

If you were to implement custom glyphs, here's some suggestions:

• Limit the glyph size to 8x8 pixels. Yes, it sounds small, but it is an ideal size for a custom glyph mode.
• Limit the color depth to 1. It's either on, or it's off. Want to colorize it? Use a Tier 2/3 GPU and monitor and change the color like you would do any other char!
• Store the image data as bits. Since each bit is a pixel, one byte is a row of 8 pixels. Since each glyph is 8 pixels tall, 8 bytes is a single glyph. Max limit of 256 glyphs times 8 bytes per glyph is a max image file size of 2KB! That should be small enough to quickly transmit in a packet over the internet in multiplayer.

This kind of goes with the old suggestion I had of a sprite-based display mode, since this is how old game consoles and computers did the graphics. Instead of manually drawing all the pixels, it used custom glyphs and rendered characters to the screen with those glyphs! That's why it's known as character graphics. ;) And sprites are just single characters that can have an arbitrary position on screen, rather than be fixed to the regular grid of characters.

Whew, finally feels good to get all that out there.

from opencomputers.

http://asie.pl/oc-unifont-code.zip

Due to the fact I could not get the OpenComputers workspace to work, this is my Unifont code contribution for OC. It supports the APIs I discussed yesterday with Sangar. Currently hardcoded to use the GNU Unifont, but this can be changed later once more formats are added.

Also, if someone were to hook a custom FontParser (good idea to consider for OC 1.4 API), they could technically create their own, custom character sets. Woo!

EDIT: Some legalese - I hereby license the OC Unifont code contribution under the same MIT license that OpenComputers is licensed on ( https://github.com/MightyPirates/OpenComputers/blob/master/LICENSE ), with a note that FontUtil.java is a port of code taken from the musl C library, also under the MIT license (embedded in the file).

from opencomputers.

I've added a setting to allow falling back to the old font renderer, for those that prefer it / want to use a custom texture font. The term should handle wide-chars fine when printing. So this is pretty much good to go, I'd say.

A wide-char aware term and text editor would be nice to have, but not immediately necessary IMHO (they might even be better served on a loot disk). So I'd say we can close this issue?

PS: a minor issue is that text in robots now has black borders left and right, due to the different aspect ratio of the chars. I'm not sure whether this annoys me enough to make the robot GUI dynamically resize based on the font size, yet...

from opencomputers.

Added the code to dynamically adjust the screen size in the robot GUI earlier, so I'd personally say this is "done" for now.

@asiekierka you mentioned you'd like to add support for compound fonts and custom character sizes in font files. Do you still plan on doing so, and would you like to track this via this issue? Otherwise I'd close this.

from opencomputers.

Close this for now, I am too busy working on my own mods.

from opencomputers.

All right.

from opencomputers.