6.12.2: Text Handling

[PyTom]

I'm starting work on Ren'Py 6.12.2. My first goal is to finish the long-delayed rewrite of the Text class. This is the displayable that shows text on the screen. The goal of the rewrite will be to support all but the most obscure functionality of Text, while improving quality and performance, and adding a range of new features.

Some of the additions I'm strongly considering are.

* Moving support for formatting variables into the Text class. Right now, substitutions take place in the say (and maybe menu) statement, and so they don't work in things like the screen language. I'd like to make substitutions part of Text itself, so that it works whenever Text is displayed. I'd also like to move from the old-style Python string formatting syntax to something inspired by the new one. Specifically, I'd like to reserve square brackets for string formatting. We'd go from:

Code: Select all

e "Hello, %(player)s. Here's the $%(payment).2f I owe you."

to:

Code: Select all

e "Hello, [player]. Here's the $[payment:.2f] I owe you."  

I believe the new syntax is better in many ways, especially because it's significantly easier to type.

* Reducing texture creation and transfer. Right now, when using the slow text feature, Ren'Py creates a new texture for each frame, and transfers that texture to the GPU. This can (and has been) causing speed problems when displaying walls of text in NVL-mode. My plan is that in 6.12.2, all the text will be rendered at once, and then the GPU (or software renderer) will be responsible for deciding what to display.

This could yield problems with slow-text mode when lines of text overlap vertically - but I think those layouts are rare, and so it won't be a burden in practice. (Evidence to the contrary, presented soon, could make me change to a different approach, one that is slower but doesn't have the potential problem.)

* More options for slow-text mode. Right now, we type out characters one at a time. In 6.12.2, I'm hoping to add a few more effects - having characters fade in, showing pixels instead of characters, having text fade in over the course of a few pixels. (Some effects may require GL rendering, falling back to less sophisticated effects if it's absent.)

* A mode where the text class oversamples text when Ren'Py is upscaling, so the text comes out sharp at the higher size. For example, if an 800x600 game is being displayed at 1024x768, Ren'Py will use a 28 pixel font instead of a 22 pixel one, with the end result being sharper text. (This may be optional or disabled in 6.12.2, as it may require changes to the GL renderer to make it visually appealing.)

* Support for a spacing text tag, a kerning text tag, and a kerning style property. The spacing text tag allows white space to be inserted into text, while kerning would control the space between characters. Does anyone have a good idea how the kerning controls in other programs work? Does it add pixels/points, or does it work on a percentage basis?

* Support for ruby/furigana, small text above the main text.

I'm also debating adding support for text with a vertical layout, although I'm leaning against it. It seems like it would ad a lot of complexity, but probably wouldn't be used much - even in languages were vertical layout is an option, VNs seem to mostly stick with horizontal layouts.

[jack_norton]

Good idea, especially because of:

* Reducing texture creation and transfer. Right now, when using the slow text feature, Ren'Py creates a new texture for each frame, and transfers that texture to the GPU. This can (and has been) causing speed problems when displaying walls of text in NVL-mode. My plan is that in 6.12.2, all the text will be rendered at once, and then the GPU (or software renderer) will be responsible for deciding what to display.

[redcat]

Speaking about the Text display, I have silly request (if it's already discussed in the past, then just skip this post) :
It would be nice (although not really necessary) to have a built-in feature that allow you to add "mock-up dub" (simple beep/tick like what you find in Phoenix-Wright game) when Renpy is displaying slow text on the screen. Or better yet, a feature to detect the phonem in the text to choose the right pic for the lip-flap (like auto-lipsync plug-in in 3D animation software).

[PyTom]

The phoneme thing is a bit much, but having better support (or at least, a better interface) for annoying sound seems reasonable.

[rinrin]

better support (or at least, a better interface) for annoying sound seems reasonable.

Happy to hear that! Support for "annoying sound" is number one on my wishlist. Some examples:
Typewriter: a sound for each letter or each word or every x letters (I think the sound in Phoenix Wright (when time and place are displayed) is not 1 / letter (but it's also not 1 / word - not sure what their system is).
Animal Crossing style beeping: each letter is associated with a different beep so the result really sounds like speech, just not human speech. Very funny and cute.

[redcat]

@PyTom--> Thank you very much for considering my request! You really are the best! >_<

I need those "annoying sounds" to add more.. err... "personality" to each character (especially since I can't afford to hire several professional VAs). In my vision, different characters will have different tone/pitch, different volume, and even different speed of "speech" (regardless of the text speed setting). But of course you don't need to add a built-in "beep generator" inside Renpy if you think that would slow down the whole system. Just a support to play external sound file is good enough.


@rinrin--> Is there any game out there with the "Animal Crossing style" beeping? o_0 That must be very funny indeed. ^_^;;
Any links where I can download one? (or just name the title so I can google it).
I might need it for... err... reference...

[rinrin]

@rinrin--> Is there any game out there with the "Animal Crossing style" beeping?

None that I know of, except for various versions of actual Animal Crossing. Here's an example video of the Japanese version. I just discovered the English version doesn't sound nearly as good - probably because spelling is so different from pronunciation in English. Anyway, here's a video in "English" just for comparison. (I have Japanese ones for DS and Gamecube - never actually listened to an English version of the game until today).

Other games that use generated speech for characters (Giftpia and Chibi Robo come to mind) seem to be using a different system - I'm not sure about the actual formula, but it sounds more random (less tied to what the characters are actually saying).

[RayRayTea]

Correct me if I'm wrong, but Ren'Py does not offer any control over leading? I have looked in the demo and searched all the help files I could get my hands on, but it's not even mentioned anywhere.The reason why I'd like to see support for leading is because it can be of great help when designing interfaces and in some cases tweaking it can improve readability.

Also, speaking of text, I'd like to see better handling of packing fonts with the final game (not sure if this fits with the topic). As is, from what I was told the font is just packed together with the rest of the assets (with obfuscation on top, not encryption) - I think a better approach would be to handle it like pdfs or Flash do (embedding just a subset of font and converting it to a non-reversible form). The reason I want to see this is because using bmfonts is sometimes just an extra step and not very practical, for example the project I'm currently working on demanded a special font which I designed but I don't really feel like distributing it with the game. I know I can just rip my own font with "Bitmap Font Generator" but I'd like to avoid it.

[luminarious]

One approach would be to automatically convert all fonts at build time into bitmap fonts. Bit of work, sure, but game creators could then just copy to game folder all the fonts they intend to use and not worry about licences. Because the font files itself would never be bundled.

I see this as the better default, because good embeddable fonts are still the exception rather than the norm. It seems reasonable then for font-embedding to be a opt-in feature, rather than the norm.

[PyTom]

Trying to figure out the subsets of fonts to include probably isn't feasible - it's a complex task, and Ren'Py includes a ton of features that let you generate text. Trying to figure out all the text a game might make is likely an impossible problem. Also, I don't think the bitmat font exception is valid in the EU.

IIRC, we do have some control over leading, with the line_spacing style. But I'll look into better control of it when I can.

What might be a cool feature is the ability to texture a font - that is, use font text to modulate the alpha channel of an image.

[luminarious]

Trying to figure out the subsets of fonts to include probably isn't feasible - it's a complex task, and Ren'Py includes a ton of features that let you generate text. Trying to figure out all the text a game might make is likely an impossible problem. Also, I don't think the bitmat font exception is valid in the EU.

Anyone using English or any of the Latin-based European languages can get by with Latin + Latin Supplement Unicode Block. That eliminates about 80% of the problems. For the rest, in dev mode it could just throw a "character missing from font bitmap". Even better if it would include the block with the currently missing character in the bitmap, instead of throwing an error. Most people need good defaults and the rest need customizability, I'd go for something like this:

Code: Select all

Font DroidSans = Font(name="DroidSans.ttf", charset=["Latin", "Cyrillic"], size=[16, 24, 36])
Font DroidSans-bolditalic = Font(name="DroidSans-bolditalic.ttf", size=24, style=["bold", "italic"])
Font DroidPixel = Font(name="DroidSans-pixel.ttf", size=16, antialias=False)

True, you still need to acquire the font by legal means, if that's what you mean. But other than that, an image with some text is still just an image with some text and legal to distribute anywhere.

[Samidarenina]

PyTom, would you think about adding a text-speed tag? It would really make some things easier.

[PyTom]

Yes, I think text speed is something worth considering. Do we need an absolute text speed tag, or is relative text speed sufficient?

[backansi]

PyTom// Can we get both of them? If user only can give relative text speed and there are character objects or text UI each of them have various text speed, s/he might feel confusion to chose value to set same text speed.

Anyway, Is there a plan for vertical text?

[PyTom]

Anyway, Is there a plan for vertical text?

Right now, I'm leaning against supporting it. It seems like it would be a relatively large amount of work, and I'm not sure anyone would actually use it - aren't most languages either left-to-right or right-to-left nowadays, at least for the primary display of computer text?