[SOLVED] Clipped text with Yanfly's Message Core and TAA_BookMenu
Preserved forum archive. This topic stores the original first post and locally mirrored RPG Maker Web attachments when available. It is posted by the BMMPlay archive account, not by the original creator.
Original Source
- Original title: [SOLVED] Clipped text with Yanfly's Message Core and TAA_BookMenu
- Original author: taaspider
- Original date: January 23, 2020
- Source thread: https://forums.rpgmakerweb.com/threads/solved-clipped-text-with-yanflys-message-core-and-taa_bookmenu.117565/
- Source forum path: Game Development Engines > RPG Maker Javascript Plugins > Javascript/Plugin Support
Summary
Okay, I've been going over the code on my own for quite some time already and found no clues, so I decided that now would be a good time to ask for help... I'm investigating a bug reported for my plugin, TAA_BookMenu, which appears only when using Yanfly's Message Core WordWrap feature: { "lightbox_close": "Close",
Archived First Post
Okay, I've been going over the code on my own for quite some time already and found no clues, so I decided that now would be a good time to ask for help...
I'm investigating a bug reported for my plugin, TAA_BookMenu, which appears only when using Yanfly's Message Core WordWrap feature:
You can reproduce the issue with the Demo project, just include Yanfly's plugin, pick a long book text (like the one in the example above), remove all manual line breaks and activate Yanfly's wordwrap function (either forcing it for all texts in the plugin parameters or by adding the tag <WordWrap> at the beginning of the book text).
I've been turning the code upside down (both mine and Yanfly's), but haven't been able to find any threads to start unraveling this thing.
I would appreciate if anyone could help me out here!
EDIT: Ok, it took me a while but I figured out what was going on (issue is fixed on TAA_BookMenu v1.4.0 or above). If anyone else stumble into this post trying to fix a similar issue, here's a short technical explanation in the spoiler tag below.
I'm investigating a bug reported for my plugin, TAA_BookMenu, which appears only when using Yanfly's Message Core WordWrap feature:
You can reproduce the issue with the Demo project, just include Yanfly's plugin, pick a long book text (like the one in the example above), remove all manual line breaks and activate Yanfly's wordwrap function (either forcing it for all texts in the plugin parameters or by adding the tag <WordWrap> at the beginning of the book text).
I've been turning the code upside down (both mine and Yanfly's), but haven't been able to find any threads to start unraveling this thing.
I would appreciate if anyone could help me out here!
EDIT: Ok, it took me a while but I figured out what was going on (issue is fixed on TAA_BookMenu v1.4.0 or above). If anyone else stumble into this post trying to fix a similar issue, here's a short technical explanation in the spoiler tag below.
After a bit of debugging, I started thinking the issue would be a bug in PIXI. That worried me, because if I were right fixing it would be quite complicated. But after digging deeper I found out that it was related to PIXI, but was being caused by my own code, and then I started to see the solution.
So, to draw the text in a window we first have to create the contents object, and for that we have to determine its dimensions (width and height). Without wordwrap that's an easy task. Width is the same as the window (minus padding) and height can be calculated with an Window_Base function called calcTextHeight. But when using wordwrap, the real text height is determined at the text drawing phase, as each character is draw individually to check whether the whole word will fit in the available width or not.
Artificially incrementing the height variable works (like multiplying it by a high number, like 10 or 100), but you risk creating a contents object so big that it exceeds the WebGL maximum allowed memory (which value depends on your GPU). The result is a black square where the text should be when you try to load the text.
I couldn't find a way to automatically fix that for both wordwrap and non-wordwrap users alike, so I included a parameter to enable or disable the fix, which consists on trying to "guess" the text height beforehand. To do that, the code counts the number of characters on the text and divide by the window width, resulting in a rough estimate to how many lines it may require. However, the dev can still force linebreaks, so I also count how many of them I can find in the text and add that to the number of lines. The resulting number is multiplied by the line height. And there you go, a rough estimate as how big your text will get.
At the end, I compare the result from calcTextHeight to this number, and choose the higher one as the contents height.
If you create a huge wall of text you can still stumble into the black square issue, but I have run tests with up to 102 lines, still good. Considering the plugin's expected use, that is already a crazy high number. If you need to go bigger than that I strongly advise you to break your text into smaller bits!
So, to draw the text in a window we first have to create the contents object, and for that we have to determine its dimensions (width and height). Without wordwrap that's an easy task. Width is the same as the window (minus padding) and height can be calculated with an Window_Base function called calcTextHeight. But when using wordwrap, the real text height is determined at the text drawing phase, as each character is draw individually to check whether the whole word will fit in the available width or not.
Artificially incrementing the height variable works (like multiplying it by a high number, like 10 or 100), but you risk creating a contents object so big that it exceeds the WebGL maximum allowed memory (which value depends on your GPU). The result is a black square where the text should be when you try to load the text.
I couldn't find a way to automatically fix that for both wordwrap and non-wordwrap users alike, so I included a parameter to enable or disable the fix, which consists on trying to "guess" the text height beforehand. To do that, the code counts the number of characters on the text and divide by the window width, resulting in a rough estimate to how many lines it may require. However, the dev can still force linebreaks, so I also count how many of them I can find in the text and add that to the number of lines. The resulting number is multiplied by the line height. And there you go, a rough estimate as how big your text will get.
At the end, I compare the result from calcTextHeight to this number, and choose the higher one as the contents height.
If you create a huge wall of text you can still stumble into the black square issue, but I have run tests with up to 102 lines, still good. Considering the plugin's expected use, that is already a crazy high number. If you need to go bigger than that I strongly advise you to break your text into smaller bits!
Downloads / Referenced Files
Log in to download
Log in, then follow the RPG Maker Developers Group to see these download links.
Log in to downloadCreator Claims / Removal
If you are the original creator and want this listing reassigned, edited, or removed, join BMMPlay and contact the moderators with proof that matches the original RPG Maker Web profile, linked GitHub, itch.io page, or another public creator identity.
Replies (0)
No replies yet.
Topic Summary
Loading summary...