Hey, neat. I discovered that Verge will crash if it tries to PrintCenter a string that is larger than 254 characters. I crashes every time, with every string over the maximum length. It however does not express this problem for PrintString or PrintRight of font 0, nor does it crash when you use a font other than 0. Just thought I'd let you guys know. I can't quite figure out what's causing it from a glance at vid_sysfont.cpp

What about all the ... args that you're now ignoring? Are they never used?

Er... that wasn't useless garbage though. The ... and va_* etc. stuff means that it could take in-string variable replacements like printf().

Of course, if it never got used (which I imagine it didn't, since the VC PrintCenter() doesn't have any such parameters (and, with easy string concatenation, it doesn't need them)) then it's probably not necessary to have them in there.

On the topic of fixing this correctly, I believe there are MSDN examples that illustrate how to do so with the secure versions of vsprintf, etc. There is a method which returns exactly how many characters will be needed to accommodate the final representation, etc.

The provided examples allocate and free a buffer of the necessary size within each call to whatever method is performing the variable argument handling. I'm not sure whether this would be acceptable in V3 or not, as custom rendering loops are going to be calling multiple PrintStrings or whatever string rendering methods, which ultimately end up calling these methods with variable argument handling. Allocating and unallocating tons of tiny chunks of memory every frame is probably not a Good Idea.

At any rate, I'd leave that to testing to determine first. If it did turn out to be an issue, my vote would be for a global stack of dynamically growing buffers. Maybe a stack of STL strings would work, I don't know. Each buffer on the stack would only grow as necessary, and the stack would allow for recursive calls or calls chaining between a few separate methods which all happen to make use of variable argument management. This would be the ideal "no limits" solution.

Perhaps a much easier route would simply be to make these local internal buffers 4K or 8K or some other ridiculously large value that is unlikely to be exhausted for 99% of string manipulations. Detection for exhaustion would still need to be present, and exhaustion would simply cause truncation of the result. Not an ideal no limits solution, but a pretty practical one that would require a whole helluva lot less code and time to test.