Text limitations

[rmcode]

I'm working on a message log for one of my games and have a question about the Text objects. Do they have any limitations in terms of size or amount of text added?

I'd guess they take up more memory the more text you draw to them, but is there anything else to consider?

Also are there any downsides of colored text vs plain text once they it is "baked" to the Text object?
I'm sure the first the latter is added faster, but does it have any influence on the speed of the drawing afterwards?

If my message log only stores a history of - let's say 100 lines - would the Text objects be light enough to have a separate instance for each line or should I rather stuff everything into one instance and clear that every now and then?

tl:dr; Text - How does it work?

[dusoft]

I would recommend storing the messages in the log queue (list/array) and the using

Code: Select all

ipairs

function to iterate over and printing line by line.

I don't think that printing 100 lines has any impact on performance.

[rmcode]

Yeah that's what I'm doing atm, but I was talking about love.graphics.newText

[zorg]

I'd guess they take up more memory the more text you draw to them, but is there anything else to consider?

Video RAM, not RAM; nothing else comes to my mind atm.

Do they have any limitations in terms of size or amount of text added?

Certainly, although what that limit is, i don' t know, because you'd probably bump into the VRAM limit first, as above stated.

Also are there any downsides of colored text vs plain text once they are "baked" into the Text object?

Since you can't extract the string contents anyway, i don't think there are (might be wrong though).

I'm sure the latter is added faster, but does it have any influence on the speed of the drawing afterwards?

Parsing speed of the additional color tables should not have any noticeable impact, and after "baking", it's still just one draw operation to dump the whole TEXT-URE (see what i did there? ) onto the screen/a canvas.

If my message log only stores a history of - let's say 100 lines - would the Text objects be light enough to have a separate instance for each line, or should I rather stuff everything into one instance and clear that every now and then?

Good question; the answer, of course, depends on whether it's faster to recreate one text object with the contents of all 100 lines, when only one of them got modified, or drawing out a 100, where you'd only need to reuse the "oldest" ones when new message lines come in. I'd guess the latter is still more performant, but again, i might be wrong; test it out, that's a sure way to know for certain!

[Murii]

https://bitbucket.org/rude/love/src/7b5 ... ont.cpp-53

Every text is basically an image that contains the glyphs you are trying to draw. I haven't looked much but I think the max width and height a text can have is 128 (note this is the default size which perhaps is increased by creating a new texture so it can contain all the text you are writing).
The smart move is to create as few fonts as possible so the GPU calls are lowered. Also it does not matter if you change the color because love sends color data every frame.

Edit 1: Looks like love's dev team is smart and recreat the texture when it becomes full (both on X and Y)
https://bitbucket.org/rude/love/src/7b5 ... nt.cpp-260
https://bitbucket.org/rude/love/src/7b5 ... nt.cpp-268
So if your text is not very very big (note: be careful that font's size matters when it comes to taking up space!) I would just create a single font and end up having more performance. Anyway just be careful to not eat that much vram

[zorg]

https://bitbucket.org/rude/love/src/7b5 ... ont.cpp-53

Every text is basically an image that contains the glyphs you are trying to draw. I haven't looked much but I think the max width and height a text can have is 128 (note this is the default size which perhaps is increased by creating a new texture so it can contain all the text you are writing).
The smart move is to create as few fonts as possible so the GPU calls are lowered. Also it does not matter if you change the color because love sends color data every frame.

Edit 1: Looks like love's dev team is smart and recreat the texture when it becomes full (both on X and Y)
https://bitbucket.org/rude/love/src/7b5 ... nt.cpp-260
https://bitbucket.org/rude/love/src/7b5 ... nt.cpp-268
So if your text is not very very big (note: be careful that font's size matters when it comes to taking up space!) I would just create a single font and end up having more performance. Anyway just be careful to not eat that much vram

Fonts and Text objects are not the same thing. He was asking about the latter.

Note that the Font.cpp you linked to are the Font related stuff, and not the text object related ones:
https://bitbucket.org/rude/love/src/7b5 ... ext.cpp-61

As i said, there doesn't seem to be a memory limitation on text objects, besides system limits, which result in that call failing.

[rmcode]

Thanks for the info. You already helped me a lot.

I played around with it briefly while on commute today. When you add single lines to an object that "wraps" it doesn't take any of the other lines into account which leads to overlapping lines.

I guess the best approach would be to clear the object and then write all lines as a concatenated string to it?