Alban, On 20 May 2008, at 18:29, Alban Bedel wrote: > I did some test and as I suspected the original VM use signed 16 bit. > For ex: > > int a; > a = 0x7000; > a = a*4/5; > > will give different result with the dott interpreter and scummvm > because 0x7000*4 overflow with 16 bits but not with 32. I'll submit a > patch for scummvm to correct this.
Nice. Now i know which type i should be using for variables for V6/V7. I take it the stack is also 16bit signed? > I also tested the arrays and it seems they are always signed 16 bits > too, no matter what type you use (yes, even the bit arrays). But I > think I will still keep the "proper" size in scvm. Wow. Now i think about it, i seem to recall reading a document which stated that the entire variable array used "words", so this more or less confirms it i guess. >> Doing a few sanity tests in my browser, i can see that... >> >> (-100 & 0xFFFF) > (100 & 0xFFFF) == true >> (100 & 0xFFFF) > (-100 & 0xFFFF) == false >> (-100 & 0xFFFF) == (100 & 0xFFFF) == true >> >> So logically speaking, blindly &'ing the value isn't sufficient as >> future comparisons will become invalid. Darn. > > You are right, what is needed is modulo 0x10000. The and trick only > work > with unsigned. As the VM can only load 16 bit values from the code you > only need to apply the modulo after ops that might overflow (+, -, *, > inc, dec). I think i'm going to have to play around with this a bit more, as i can't seem to reproduce normal signed 16bit integer overflow behaviour, even with these suggestions. Actually, i can't seem to find any code on the net which seems to handle this correctly without resorting to typecasting (which i can't do as there is no 16bit integer type in haXe). Guess i'll have to do more digging. Thanks again, ~ James _______________________________________________ ScummC-general mailing list [email protected] https://mail.gna.org/listinfo/scummc-general
