[SPOILER] ADV Textbox sometimes interferes with screen overlay effects [SPOILER]

[drojf]

Sometimes in ADV mode, the textbox interferes with the red overlay. I've seen this reported a couple times before.

Will need to see if it's possible to fix this - if not, should list it as a known issue.

User said this:

just fixes itself by switching to window mode or switching to full screen
Seems like the red layer on screen it's not applying right to the text box area
actually that red becomes different when switching

Images are spoiler - click at your own risk:
textbox_clipping

This other image shows the red becoming lighter. Not sure if it really changes due to the switching, or if the script has that effect in there already
lighter_when_switching

[drojf]

I was about to open a new issue, but Github notified me that it already existed

A graphical glitch where the ADV textbox area wouldn't properly be displayed was reported with this screenshot:

Click to show spoiler image

This issue is still present on the current version of our ADV mod, and I had seen it occasionally before, but never looked into it. I think it occurs when there is both a DLL effect on the screen (eg rain) and also the mono 0 command is used (this command clears any active monochrome effect, such as having the screen all red color or all greyscale). You can view the bug with the following snippet (note I have added dllefe 1,1 as the first line to trigger the rain effect):

dllefe 1,1 ; < ADDED RAIN EFFECT HERE
langjp　黄金郷に飛び込んだ艦船が次々に砲門を開き、一斉にでたらめに滅茶苦茶に撃ち放つ。\
langen^The warships that had flown into the Golden Land opened their gun ports one after another, and then they all fired at once in a scattered mess of cannonballs.^\

bfly1 0
bg new_goas_eye2c,22

me2v 3,100
me3v 17,100

se1v 66,100
cbfly 0
bg white,8

mono 2
se1v 73,100
se2v 27,100
se3v 74,100

bg new_red_b,1
quakey 10,1200

bgcopy
mono 0
advsetwindow "-1"

;BUG OCCURS HERE
langjp　撃ち放たれる数百発の炸裂弾が、触れる物、触れる者全ての概念を否定し、木っ端微塵に打ち砕き、灼熱させて炎を噴き上げる。@
langen^The hundreds of explosive rounds they fired would negate the concept of any thing or person they touched, smashing them into little bits and setting them ablaze with flames.^@

Here is a video of how this looks in NVL mode: https://1drv.ms/v/s!Ar-lAVeetlqhgc4vYYK0xh_D80Mgsw?e=3LDaiD

It appears that NVL mode relies on the textbox draw area (different from the textbox size) being the size of the screen. This bug does not happen on the NVL version of the game because when the "textbox" is shown on the NVL version of the game, the whole screen is redrawn, instead of just a portion of it. I have seen other variants of this bug happen occasionally, but this one is particularly bad.

I deliberately made the textbox draw area smaller for ADV mode as it improved performance, so I was looking at other ways to fix the issue.

I found that if you insert a repaint or print 10, 300 (this is a 300ms fade - any effect which takes some time will also work) inside the mono command (after the monochrome effect is being disabled), it fixes the issue. The repaint option looks really bad as there is no transition time, so the 300ms fade is preferred.

The 'fixed' mono function is below (just added print 10, 300):

*mono

 getparam %Free1       ;モノクロ値を文字変数で取る

 notif %Free1 = off jumpf   ;OFFで無いならON処理へ

  mov %monoflg,off
  monocro off
  print 10, 300 ; 300ms Fade: Fixes ADV textbox glitch - this forces a repaint
 return

~

 if %Free1 = 1 mov %monoflg,1 : monocro #cccccc
 if %Free1 = 2 mov %monoflg,2 : monocro #ff4444

return

While this works, I'm not sure if it has any bad effects (it really shouldn't have any really bad effects as the print function just orders a transition/forces any undrawn graphics to appear). For this reason, I'll hold off on pushing the fix for a few days in case I think of something, or perhaps do some more testing.

[drojf]

After some more testing, it looks like this problem can occur due to other functions besides the mono function. It happens anywhere some graphics are cleared, but a proper screen refresh does not occur, immediately followed by text.

Graphical glitch:

dllefe 1,1 ; Rain
mono 0
; No refresh after the mono 0 command
langjp「どうして…？　もうすぐ雨が降ってくるよ。」\
langen:dwave 0, "voice\11\82000199.ogg":^"Why...?  It'll start raining soon."^\

No graphical glitch:

dllefe 1,1 ; Rain
mono 0
bg black,22 ; Refresh occurs here
; Screen has been refreshed
langjp「どうして…？　もうすぐ雨が降ってくるよ。」\
langen:dwave 0, "voice\11\82000199.ogg":^"Why...?  It'll start raining soon."^\

I also found that most of the time, the error was masked because there was already some function which caused a screen refresh afterwards. This could be from a background change (bg black,22), a print statement, even changing the name on the textbox causes a refresh - this explains why the problem isn't seen more often. Note that an 'instant print/instant show' (print 0) doesn't seem to fix the issue.

I ended up writing a script which scanned for bgcopy mono 0 and cbfly while rain was active, let it insert refresh commands, and then I manually went through and removed any unnecessary refresh commands. The changes can bee seen in b9fd07f

I ended up using print 62 as I saw it elsewhere in t he script. print 62 uses effect 62, which is defined as effect 62,10,200 (a 200ms fade).