Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Yes

1 (14.3%)

No

6 (85.7%)

Total Members Voted: 7

[Baughn]

It would simplify things (especially for modders) if I don't have to support this, so only answer yes if this is something you're actually using, okay?

As usual, even a single "yes" is going to make me work to keep it in. Which will probably mean less time for other features, but I'll get to those eventually.

[Baughn]

I should note that as one of the features likely to get pushed off is runtime switching of fonts, I might just end up implementing separate windowed/fullscreen fonts via *that*. So it's not the end of the world.

[Still Standing]

You realise by saying a single Yes vote will make you do it means somebody was going to Vote yes just because you said it.  People are like that.

But no, I use the same Ironhand font for both.

[Baughn]

..you know, this would just be *too* inconvenient.

I'm already overhauling the entire texture system so I'll just add the ability to switch 'em at runtime. That should do it.

[MaDeR Levap]

I am interested why same settings for PRINT_MODE have so various effects on various computers? Is OpenGL standard that screwed up? Or manufacturers do sloppy work? Or you code is buggy? Or all of this at once?

[Baughn]

All of the above. Let's see..

- 2D: No opengl, works everywhere.
- Standard: Standards-compliant opengl. Works everywhere that has a working opengl driver, which is not in fact everywhere. Pretty fast, actually, but people seem to want the last micron of speed, so..
- VBO: A slight improvement on standard, still compliant, but using newer methods. Works less often.
- Frame-buffer: Partial-printing implementation using newer extensions. Often breaks due to driver issues.
- Accum-buffer: Partial-printing implementation using very old methods. Usually slow.
- Partial: Partial-printing using undefined behaviour. Usually breaks.

[carebear]

It wouldn't hurt to have it, but it's not something I would use myself. If it means other things get done later, I'd rather see that those other things get done now.

[Fedor]

Nice initiative, Baughn!

I don't have a preference on the question you framed, but I am hoping for the ability to use bitmapped fonts as well as truetype ones.  Making truetype fonts involves a fair bit of knowhow and some software; making bitmapped fonts is much more approachable.  Also, while there are a lot of DF-optimized bitmapped fonts already in existence in tilesets, we're starting at zero with truetype.

[Baughn]

Sure. It's using the freetype2 renderer, which supports a variety of bitmap fonts as well as truetype.

[Untelligent]

Partial works perfectly for me, but only when I have Aero turned on, which I've heard takes up a significant amount of resources, so I don't know if it's actually optimal for me. Ah well.

[Thief^]

Sure. It's using the freetype2 renderer, which supports a variety of bitmap fonts as well as truetype.

Will we be able to just use a separate tileset file too? Many tilesets are available as both a "with accented characters" and "with object pictures" download already, so it would be good to just be able to specify both files and have both accents in text and levers etc that look like levers etc.

[Baughn]

Yes, that's pretty much the entire point.

[Thief^]

That's awesome then. I'd thought from what you'd said so far that it would only support using actual font files (ttf etc) for the text, not a 2nd DF bmp/png.

[Baughn]

Well, it doesn't support 2D DF tilesets, at least unless I write code to do that. Which I might.

It does support bitmap fonts, even without that, but although freetype2 supports a lot of bitmap font formats, "DF tileset" isn't one of them.