Fonts

[Robin]

I agree with the first part of your phrase (everyone should pre-create fonts) but not with the second (except if they are too wasteful).

Perhaps I wasn't clear. I never meant to suggest it's okay if they are wasteful with resources, but merely that they would bring themselves in impossible situations anyway, with or without creating fonts.

It is also a problem of "unclear interface". Nothing in the name of the functions suggests that a new font is created. Tutorials use these functions but don't specify that. This confuses people. Not only people learning LÖVE, but also from the love core team.

True, this should be in the docs.

[qubodup]

I skipped thread, sorry for that!

Unicode support yay! Pyglet does it for example http://www.flickr.com/photos/qubodup/4282981539/

Don't forget to add RtL support (right to left) so I can type العربية the right way (hurr-hurr, I said "right"). Pyglet doesn't support RtL currently. and I'm obsessed with comparison.

[rude]

It is also a problem of "unclear interface". Nothing in the name of the functions suggests that a new font is created.

You're right. This shouldn't be documented, it should be changed.

[Odysseus]

Here is an idea about unicode support inspired by discussion in this topic. Instead of rasterizing the whole unicode font and sending it to GPU, text can be pre-rendered to some image, and then only this image could be sent to GPU. Pre-rendering itself could be not so fast, but once it is done the resulting image could be cached and then drawn at the speed of arbitrary image drawing.

To facilitate the reuse of pre-rendered image "printf" concept could be changed to "text box" concept. Thus, instead of

Code: Select all

love.graphics.setFont(filename, size);
love.graphics.draw("I LÖVE Unicode", 100, 100);

one would write something like

Code: Select all

tb = love.graphics.newTextBox("I LÖVE Unicode", filename, size);
love.graphics.draw(tb, 100, 100);

[Robin]

Here is an idea about unicode support inspired by discussion in this topic. Instead of rasterizing the whole unicode font and sending it to GPU, text can be pre-rendered to some image, and then only this image could be sent to GPU. Pre-rendering itself could be not so fast, but once it is done the resulting image could be cached and then drawn at the speed of arbitrary image drawing.

May works well with static text, but I think much of the text used in games will be dynamic anyway, which defeats the whole purpose of pre-rendering.

To facilitate the reuse of pre-rendered image "printf" concept could be changed to "text box" concept. Thus, instead of

Code: Select all

love.graphics.setFont(filename, size);
love.graphics.draw("I LÖVE Unicode", 100, 100);

one would write something like

Code: Select all

tb = love.graphics.newTextBox("I LÖVE Unicode", filename, size);
love.graphics.draw(tb, 100, 100);

I assume you meant love.graphics.print in both examples.

[kikito]

To facilitate the reuse of pre-rendered image "printf" concept could be changed to "text box" concept.

On its current state, text rendering is slow (or so others say; I haven't tested this myself) so any kind of caching would help. So I see some utility on having some sort of caching, specially if text rendering can't be done faster.

However, I don't like your proposed implementation (the "textbox"). I think it is too limited to text.

It would be better if we could render any draw function onto an imageData object (feature requested already) so one could do something like this:

Code: Select all

font = love.graphics.newFont(filename, size)
...
local text = "I LÖVE Unicode"
-- create an imageData as tall and wide as the text on the created font
local width, height = font:getWidth(text), font:getLineHeight()*font:getHeight()
local imageData = love.image.newImageData(width, height)
love.graphics.setFont(font)
imageData:print(text,0,0) -- Print the text on imageData
imageData:rectangle('line',0,0,width,height) -- This adds a rectangle. I could do more stuff here, like adding other sprites, etc
image = love.graphics.newImage(imageData)
...
love.graphics.draw(image, 100, 100)

This isn't possible right now since imageData only admits setPixel and pasting squared sections from other imageDatas.

[Odysseus]

I assume you meant love.graphics.print in both examples.

Yes, sorry for typos

May works well with static text, but I think much of the text used in games will be dynamic anyway, which defeats the whole purpose of pre-rendering.

As far as I understand from the thread mentioned above, caching is done anyway at GPU level. So the suggestion was actually to replace caching of 65000+ unicode character glyphs (which seems to be major showstopper to unicode support) with caching of much more limited number of pre-composed messages that use these glyphs.

However, I don't like your proposed implementation (the "textbox"). I think it is too limited to text.

Well, your suggested approach is more flexible and "textboxes" could be easily implemented on top of it in pure Lua, so I vote for it. The only additional feature request would be the ability to draw unicode text onto imageData.