Display large numbers in torquescript?

#21 Ok, a few more changes fixes this situation, but there might easily be other places I've missed that still use 32 bit values and therewore would have similar problems. Perhaps Ben can sanity-scan this if he's got the time:

in consoleInternal.h around 153:

U[b]64[/b] ival;  // doubles as strlen when type = -1
         F[b]64[/b] fval;

in consoleInternal.h around 168:

F[b]64[/b] getFloatValue()

in consoleInternal.h around 206:

void setFloatValue(F[b]64[/b] val)

in consoleInternal.h around 211:

ival = static_cast<U[b]64[/b]>(val);

And one small change back in consoleTypes.cc around 142:

dSprintf(returnBuffer, 256, "%.9g", *((F[b]64[/b] *) dptr) );

(in addition to the .9 precision change before).


This fixes up both stored and immediate values as far as my extremely brief testing has shown, but be careful if you use this, I could have easily broken something else that I didn't catch. I realize this is now in 1.4 but I've no idea how soon 1.4 will be rolled into T2D.

#22 It worked perfectly! I was so happy to see that, thanks for sharing it Luke!

#23 Ah, very good sleuthing, Luke. I'll fold this stuff in for sure. Thank you!

#24 It does mess up gamma on 1.2 Ben.

#25 What?

#26 Well one side-effect I've seen so far is the values in prefs.cs are getting saved out to higher precision values (e.g. channelVolume1 = 0.800000012). But worse than that is peppered through the prefs.cs file are a bunch of strings in place of new lines that look like "(null)". They're not in place of a value, just the newline:

$pref::Audio::environmentEnabled = 0;(null)$pref::Audio::forceMaxDistanceUpdate = 0;(null)$pref::Audio::masterVolume = "1";

Very strange. These stop showing up with an unmodified version (and even the first attempt above) so it has something to do with the most recent precision fixes. Going to try to determine why now...

#27 Ok, the unsigned int that got changed in a few places from U32 to U64 is causing the (null) problem (and I assume the gamma was getting screwed up by that) so if you revert the following two lines:

U64 ival;  // doubles as strlen when type = -1
...
ival = static_cast<U64>(val);

so they're back to U32 again, it fixes the output problem. I'm a bit concerned though that something might try to use the ival value someplace instead of fval and lose the extended precision, however I've done a bit of regression testing for our original goal and it seems to be ok. Just something to keep an eye out for. This stuff is low-level enough that side-effects are likely to pop up in weird places. :)

#28 Nope, gamma is still screwed.

What happens is that the screen gets very bright/dark when I start the application, and then when I kill it.. it doesn't revert back to the original gamma setting.

#29 I'm not in a position to upgrade to 1.4 from 1.3 just yet. Has anyone tested this further? I'm seeing some bogus numbers coming out in the prefs file for floats.

#30 In the end I kept seeing oddities such as you describe, and/or bad math in calculations. Instead, I adjusted my implementation to only need up to 9,999,999 and reduced the precision of the format from %.9g to %.7g and all of these problems went away.

#31 If you need to do some simple script additions you can use this function. It would be pretty easy to add more for other operations:

ConsoleFunction( MathAdd, const char*, 3, 3, "Add 2 large numbers" )
{
   U32 v1 = dAtoi(argv[1]);
   U32 v2 = dAtoi(argv[2]);

   U32 res = v1 + v2;
   char* ret = Con::getReturnBuffer(64);
   dSprintf(ret, sizeof(ret), "%i", res);

   return ret;
}

#32 I had this issue and I used the above for all my math function and it worked great. Thanks for the post

#33 Glad it helped you. Here is the full function list:

ConsoleFunction( MathAdd, const char*, 3, 3, "Add 2 large numbers" )
{
   S32 v1 = dAtoi(argv[1]);
   S32 v2 = dAtoi(argv[2]);

   S32 res = v1 + v2;
   char* ret = Con::getReturnBuffer(64);
   dSprintf(ret, 64, "%i", res);

   return ret;
}

ConsoleFunction( MathSub, const char*, 3, 3, "Subtract 2 large numbers" )
{
   S32 v1 = dAtoi(argv[1]);
   S32 v2 = dAtoi(argv[2]);

   S32 res = v1 - v2;
   char* ret = Con::getReturnBuffer(64);
   dSprintf(ret, 64, "%i", res);

   return ret;
}

ConsoleFunction( MathMul, const char*, 3, 3, "Multiply 2 large numbers" )
{
   S32 v1 = dAtoi(argv[1]);
   S32 v2 = dAtoi(argv[2]);

   S32 res = v1 * v2;
   char* ret = Con::getReturnBuffer(64);
   dSprintf(ret, 64, "%i", res);

   return ret;
}

ConsoleFunction( MathDiv, const char*, 3, 3, "Divide 2 large numbers" )
{
   S32 v1 = dAtoi(argv[1]);
   S32 v2 = dAtoi(argv[2]);

   S32 res = v1 / v2;
   char* ret = Con::getReturnBuffer(64);
   dSprintf(ret, 64, "%i", res);

   return ret;
}

#34 Should I be expecting to see this issue still present in TGE 1.5.2? It's there still. :-O

#35 I don't believe it was ever added back into HEAD.

#36 As long as it's fixed in Torque 2!

#37

Quote:
TorqueScript simply rarely needs to deal with large numbers, so I don't think it was something anyone ever tested. :)

I play games where my score goes into the millions a LOT, so I don't see how you can say this...

Are we going to see added support for larger numbers in future builds of Torque? (TGB, TGE, TGEA, the whole works needs this!)