Currently, no. That limit is per gui scene. This number is matching the max number of bits for the render key (which is 10)
Will it be changed someday? It’s sad there is such restriction. Using node based GUI text assets like RichText or Defold-Printer is sometimes impossible with such limit
It’s certainly not an easy change to do, and it is unlikely we’ll look into this in the recent future.
Ok, so any tips what should I do to display large text, that exceeds this buffer, with one of the mentioned assets?
Are you actually displaying more than 1024 text nodes at a time?
In the case of RichText I guess there could be some kind of node reuse implemented. I would need to know more about how it is used first though.
Yes, actually, I tried now with Defold-Printer by @Insality to show a text that is pretty long, so I’m exceeding this buffer. I’ll try with RichText if it’s the same, but afaik they are both based on gui nodes that are cloned, so there should appear this problem too, right?
Yes, likely. RichText will split text into words and create one node per word. This could be optimized to use much fewer words, especially if there’s not that much markup in the text that is presented.
Oh, Defold-Printer splits text into single signs, therefore each of them can be animated. That’s why I reached the limit so fast and didn’t manage to do that with RichText And it’s all to have a fluid letter-by-letter appearing of text I’m thinking about another variation, that could be handled in that way: having a whole text, but displaying the text each iteration with more of the text revealed, so it would be on single node/label, something like (pseudo-lua-code):
for i =1,#text do
displayed_text = displayed_text .. text[i]
gui.set_text(node, displayed_text)
end
RichText defaults to splitting on a word level but you can also split a word into individual characters so that they can be animated one by one (wave animation for instance).
local chars = richtext.characters(word)
And to reveal more and more of a text you can use the truncate function:
richtext.truncate(words, length)
Yes, yes, I remember it Though, it is a bottle-neck for long text if it comes to this buffer actually
What do you mean by this? I didn’t really understand.
I am just still referring to my previous post here:
so it’s impossible to show a lot of cloned nodes (representing signs/letters), because of the error in the topic
I’d like to play around with this a bit and see if I can optimize node usage in RichText. Can you share the text and the setup with me? Or even better create a GitHub issue!
@Pawel, yea, you right. Defold-printer designed for short dialogs, so it will be hard to display a tons of text in one time.
Possibly, I need to create notice in library, to notify about this problem
Or add some “word” mode, as in Rich text, to create text nodes with several letters
Yes, I’m on my way
One solution for large text is really simple, as I wrote:
But now it’s checked code:
local dialog_node = gui.get_node("dialog_node")
local text = "HEY STRANGER, WHAT ARE YOU DOING HERE? etc"
local cursor = 1
local now = ""
local text_timer = timer.delay(0.03, true, function()
now = text:sub(1, cursor)
--print(now)
gui.set_text(dialog_node, now)
cursor = cursor + 1
if cursor == #text then
timer.cancel(text_timer)
end
end)
Just add text node to the gui. If the Pivot is set to west it will looks like adding a letter one by one. Else if set to center it will look like unwraping scroll And you can make anything with the text node. But, not with single letters, so the advantages of RichText and Defold-Printer tags are impossible here afaik.
I have another idea for large text for node based assets - If there is a lot of letter of the same vanilla style/font (without animations), you could wrap a bunch of letters in the single text node, like RichText’s word-based nodes, but even more words bundled together, is it clear?
Anyway, there is an Issue: https://github.com/britzl/defold-richtext/issues/34
I’ve released a new version of RichText where you can specify that words of the same style (size, font and color) should be combined into a single node to reduce node count. This is done on a per line basis, which theoretically allows you to have a text with a line count equal to the max node count of your gui.
A further and future improvement would be to add support for also combining multiple lines, but the current solution was fairly easy to implement.
Great! Thank you very much!
hi!
Okay, i’ve been working really hard here and I’ve come across the node buffer. I’d be curious to know if there’s any way of increasing it myself (As my game is 100% GUI at the moment, and ideally I’d have around 5040 nodes)
We have in our sprint for 1.2.166 to see if we can increase it.