Navi - a message library (6/11 demo)

[Robin]

a flag that is set when initializing whether to use canvases or not, or just have it check if canvas is supported itself.

My library already has the former, and it's not hard to implement the latter.

[litearc]

@Robin: do you have a 0.8.0 version of your library? The latest download in your thread doesn't work for me.

If Robin's library already does this without Canvases, it would be a better option since it can also do images and different fonts. If not, I think it'd be easier for me to add those features into mine and have an "instant show" option than to coordinate on a project together.

But as a side note, I don't think it's trivial to extend a simple formatted-text print function to a message function in an efficient way without using Canvas. If such a print function is incorporated into the core lib, it'd be interesting to see how fast a message function built on top of it performs.

[Jasoco]

@Robin: do you have a 0.8.0 version of your library? The latest download in your thread doesn't work for me.

If Robin's library already does this without Canvases, it would be a better option since it can also do images and different fonts. If not, I think it'd be easier for me to add those features into mine and have an "instant show" option than to coordinate on a project together.

But as a side note, I don't think it's trivial to extend a simple formatted-text print function to a message function in an efficient way without using Canvas. If such a print function is incorporated into the core lib, it'd be interesting to see how fast a message function built on top of it performs.

Actually yours has a typing in feature while Robin's doesn't. All you'd need is a "setup" call and then an "update" that would type the text in, and you already have it. Robin's just has more fonts and images. If the two of your projects were merged together you'd have one hell of a system.

Yours already does it, we'd just be handling it ourselves instead of using the message function parts. We'd just need certain information returned to us like "is message finished typing" that can return true or false to decide whether to procede to the next or set the speed really high to make it finish faster. I mean, I can write a great text typing library if I want, but it wouldn't have the different colored text which is why we're all so interested in these libraries. The more the better. Especially if it supports different fonts (So you could have an italics font and normal font or a bold font as well as different colors.) and images inline. (The images could be icons of keys you need to press to do certain things like you see all the time in Nintendo tutorials. "Press [A] to jump! Try it, Mario!"... Actually, on second thought, that could also be done with a separate image font if you use one that has all the keys you use for controlling in a font where they're set up to look like keyboard keys.)

[Robin]

@Robin: do you have a 0.8.0 version of your library? The latest download in your thread doesn't work for me.

You know what? I'll update it right now. It'll be not much work, and then we could look for areas in which we could cooperate.

EDIT: updated version at https://github.com/gvx/richtext. Computers without Canvas support are supported, only there is a weird wrapping bug which needs investigating.

[Ref]

Rolling along really fast.
litearc's code appears robust and stable.
In my brief test (MessageBoxes.love) I added the boolen variable message.completed.
Adding a font change ability would be very easy - the adding of another code flag.
I appreciate the desire to keep the code at the lowest common denominator - for compatibility with inferior equipment at the expense of creativity.
My comment regarding the use of canvases was related to a specific application where I wanted the ability to DYNAMICALLY display characters (typewriter mode) over a DYNAMICALLY changing background which was frame rate challenged. litearc's code was just too slow considering that what he is doing is as follows:

adds line breaks to character string
frame one: creates a filled rectangle
frame two: create a filled rectangle
analyzes format info for character 1
draws character 1
frame three: creates a filled rectangle
analyses format info for character 1
draws character 1
analyzes format info for character two
draws character 2
etc
After all characters are displayed but the window remains open:
creates a filled rectangle
analyzes formating info for each character and draws each character
This is done each frame!
The use of a canvas would be much more efficient but would really only needed if a typewriter display of characters over a continuously changing background is desired.

The addition of the capability to change font size on an individual word or line bases would require a new way to determine message height and line spacing.
Changing the font size for the entire message box is quite easy, already done in MessageBoxes.love

In its present form, litearc's code is quite useable!

[litearc]

@Robin: Cool, thanks! I'm going to check this out - see what I can learn from your code. I'll also look at the text-wrapping thing. It'd be great if this one last thing can be worked out since so many people seem to want a library like this.

adds line breaks to character string
frame one: creates a filled rectangle
frame two: create a filled rectangle
analyzes format info for character 1
draws character 1
frame three: creates a filled rectangle
analyses format info for character 1
draws character 1
analyzes format info for character two
draws character 2

Hm? It doesn't do any analyzing during the drawing. All that is done in the initialization. There may be a initial delay when the message info is being parsed out but it should be smooth during runtime.

Also, a quick update: Message box animations and scrolling text now work. For those who've been looking at the code, I had to make large changes to the "play" function. It now supports messages that span multiple boxes without the need for "getms", which was kind of a hack anyway.

[Ref]

Sorry that the term 'analyze' didn't convey what I was getting at.
Let me just point out that in the function _msg:play there are 13 'end's - so some tests are being performed on each character every frame.
Question: Why the special math.round function when math.floor works just fine? (Just curious) :>)

[Robin]

(By the way, I just pushed a fix for two weird bugs and a stupid bug.)

[Elena5]

@Robin: Are you eager to add the same specificities as in litearc's message system, that is to say, letter by letter messages, handle inputs and thus a stack based message system, long message splitting into multiple boxes, maybe menu choice, and most importantly a demo? I think these kind of things are pretty standard in video games.

I would be interested if you could reproduce litearc's demo (at least some parts) with richtext.

Yes, I prefer two separate projects that do the same thing. :p

[Robin]

Not really, since the scope of my project is different, leading to differences in design and implementation. However, what I could do is make RT more flexible, so that others can easily implement all those features on top of it.