In my global script there are several cases where I have accidentally set a char value to -1 (via function calls). This isn't caught at compile time, but it is causing me some heartache at runtime. It would appear (based on the illegal array indexes getting returned via error) that the char is converted from -1 to 255. I could easily change the value I use (as the greatest one I need is 29 so I could use 30 as my null value) but I wanted to know if this was known and/or report it. As a matter of fact, you can even explicitly declare a char with a negative value, however, I have just discovered a fun error when trying to display it:
---------------------------
Adventure Game Studio
---------------------------
An error has occured. Please contact the game author for support, as this
is likely to be a scripting error and not a bug in AGS.
(ACI version 2.70.856)
in Global script (line 173)
Error: Cannot display message with extended characters in SCI font
(Accented characters, for example the special French and German e/a/u/i letters cannot be used by default. You need to import a TTF font to do so).
---------------------------
OK
---------------------------
I used the negative char to index an array with an index of 5 (0 - 4), and got this error message:
---------------------------
Adventure Game Studio
---------------------------
An internal error has occured. Please note down the following information.
If the problem persists, contact Chris Jones.
(ACI version 2.70.856)
Error: run_text_script1: error -6 running function 'btnIconAbout_Click':
Error: Array index out of bounds (index: 255, bounds: 0..4)
in Global script (line 172)
---------------------------
OK
---------------------------
So, hope this helps...
The char data type can only store values 0-255. If you pass -1, it seems to get converted to 255. So the error messages are correct.
QuoteError: Cannot display message with extended characters in SCI font
SCI fonts only have ASCII characters 1 to 127 so trying to display ASCII code 255 doesn't work of course. Only TTF fonts support extended characters.
QuoteError: Array index out of bounds (index: 255, bounds: 0..4)
Obvious.
Do I understand correctly that you think the conversion is a bug and want AGS to abort the game if you try to assign a value to a variable that exceeds the bounds defined by its data type?
Quote from: strazer on Sat 23/04/2005 08:00:01Do I understand correctly that you think the conversion is a bug and want AGS to abort the game if you try to assign a value to a variable that exceeds the bounds defined by its data type?
I was just thinking that it should be caught as an error at compile time, as it could produce fatal errors...If this was set up intentionally then I guess you can just ignore this.
Sometimes people write scripts or code that expects numbers to "wrap" like that, they do in C/C++ and other languages. A char is just behaving like an 8 bit unsigned integer (unsigned char) in C as it is.
Although... you'd get warnings, such as about conversion from signed to unsigned numbers if you tried to assign an int returning function to an unsigned char I think, so perhaps it is confusing in AGS.
I revive this topic because I have a similar problem: I'm willing to store numbers into a string, sort of using its chars as 255-base bytes.
Anyway, the point is that if I set a char variables to a value higher than 127 and set an int variable passing the char variable as the value, whenever I try to display one or the other variable's value in a string with the %d expression, I get a negative value (positive value - 256).
Here is an example : int i = 0;
while (i < 256) {
char a = i;
// Intended positve values up to 127, then negative
Display("%d : %d", i, a);
i++;
}I tried to display it with a non-SCI font but it behaves the same.
Should I check for negative values whenever I handle a char variable as an int?
Quote from: Kitai on Sat 18/05/2013 17:53:10I tried to display it with a non-SCI font but it behaves the same. Should I check for negative values whenever I handle a char variable as an int?
Well, obviously, it does not depend on font. It is the nature of "char" type, it interprets the number as one from the -128/+127 range.
The solution would be to cast char to int (which has greater range) and add 256 if the char value is negative:
int fixed_value;
if (char_value >= 0)
fixed_value = char_value;
else
fixed_value = char_value + 256;
EDIT: err, wait a second... AGS manual states that char can be 0-255, so it is in fact "unsigned char". Hmm, I need to make a test...
Thanks CW, that's what I'll do. I'll replace my String.Chars[] uses by calls to a custom method executing the code you gave.
Wait. There's something really strange in this.
First of all, this was my mistake. In fact AGS really treats "char" as "unsigned char", meaning it stores numbers in the 0-255 range (this is stated in the manual).
Secondly, when I use your code I get all positive values all the time (0-255).
EDIT: I think I understand now.
This convertion problem arises only if you use String.Chars directly, like
Display("%d", String.Chars[0]);
If you do just this:
char c = String.Chars[0];
Display("%d", c);
You will get always positive value.
Quote from: Crimson Wizard on Sat 18/05/2013 18:28:42Secondly, when I use your code I get all positive values all the time (0-255).
Weird, I just copied and pasted my code again and ran it and it still prints negative numbers from 128 :undecided:
Quote from: Crimson Wizard on Sat 18/05/2013 18:28:42This convertion problem arises only if you use String.Chars directly, like
Well, I still get a negative value with :
String alpha = String.Format("%c",150);
char c = alpha.Chars[0];
Display("%d", c); // Prints -106
Interesting.
What AGS version do you use?
What are your "Backward Compatibility" settings (on the "General Settings" page)
I use AGS 3.3.0 beta.
My Backward Compatibility settings are the following (I omit the presumably irrelevant lines):
- Enfore new-style strings: True
- Enfore object-based scripting: True
- Left-to-right operator precedence: True
Quote from: Kitai on Sun 19/05/2013 11:57:37
I use AGS 3.3.0 beta.
It is a bug in 3.3.0 beta... :embarrassed:
I am going to look in this.
Sorry for inconvenience!
EDIT: It looks like I've already fixed that in our development version :)
We will release the update shortly anyway.