Source Code Project Mantis - FSSCP
View Issue Details
0002891FSSCPscriptingpublic2013-06-08 12:222014-06-13 04:35
Assigned Tom_m 
PlatformOSWindows 7OS Version
Product Version3.7.0 RC2 
Target VersionFixed in Version3.7.2 RC3 
Summary0002891: gr.drawString text box height irregular
Descriptiongr.drawString has five arguments: (string, x1, y1, x2, y2).
x1 and y1 correctly control where the top left hand corner is placed, and x2 correctly controls the the position of the right hand border of the text box.
However, the effect of y2 on the text box height seems highly irregular - at very small differences between y1 and y2 chunks of the string are carved off an unpredictable fashion, and larger (but can still be fairly small) differences appear to have no effect on the string.
Steps To ReproduceComplete test mod is attached, with in-mission instructions.
Observe how as you lower the text box height (shown visually as a rectangle with the same coordinates), nothing happens until you get very close to a height of 0, where very small steps can cause large chunks of the string to disappear.
Additional InformationDecreasing the text box width too low to show the string causes a debug error; presumably to explain to the modder what's happened to their string. No such error observed when the height gets too low.
TagsNo tags attached.
Attached Files7z drawStringtest.7z (2,380) 2013-06-08 12:22
patch mantis2891.patch (1,847) 2014-06-12 11:19

2013-06-22 15:39   
I have a patch which fixes the describes issue. I have no idea what the original code was supposed to do but I hope that I got the intended behavior right.
I also fixed another bug which caused the text to skip one line right at the beginning of the text.
2013-06-22 16:04   
Would fixing that second bug cause all uses of drawString up until now to be shifted up a line?
2013-06-22 16:07   
No, only the ones that are using the string bounding mechanism.
2013-06-22 20:18   
I see you had issues with lowercase min() and resorted to std::min(), after undef'ing min

Can you not instead use our macro MIN() - note capitalisation - instead and not have to undef?
2013-06-23 02:41   
I would suggest that we simply define NOMINMAX ( for windows builds which would suppress the definition of these macros. These definitions have caused nothing but issues and aren't used anywhere in the code so removing them seems to be the way to go.

What do you think about that approach?
2014-06-12 11:19   
New patch attached which applies cleanly to current trunk.
2014-06-13 04:35   
Fix committed to trunk@10796.

Issue History
2013-06-08 12:22FelixJimNew Issue
2013-06-08 12:22FelixJimFile Added: drawStringtest.7z
2013-06-22 15:39m_mNote Added: 0015137
2013-06-22 15:39m_mAssigned To => m_m
2013-06-22 15:39m_mStatusnew => code review
2013-06-22 15:40m_mFile Added: mantis2891.patch
2013-06-22 16:04FelixJimNote Added: 0015138
2013-06-22 16:07m_mNote Added: 0015139
2013-06-22 20:18Echelon9Note Added: 0015141
2013-06-23 02:41m_mNote Added: 0015142
2014-06-12 11:19m_mFile Deleted: mantis2891.patch
2014-06-12 11:19m_mFile Added: mantis2891.patch
2014-06-12 11:19m_mNote Added: 0015846
2014-06-13 04:35m_mNote Added: 0015854
2014-06-13 04:35m_mStatuscode review => resolved
2014-06-13 04:35m_mFixed in Version => 3.7.2 RC3
2014-06-13 04:35m_mResolutionopen => fixed