Dice rolls skewed

[Displacer]

While checking something in PST, I ran through the dice rolling code. The rolls are very slightly skewed towards the high side. It has to do with how assembly code deals with numbers. Assembly usually starts counting at zero instead of one. When a dice roll is requested it takes the needed dice, for this example we'll use 1D10, generates a random number between 1 and 10 then converts it to 0-9. Now this conversion should take place no matter what, but the engine only does the conversion if the result comes back a 10. The net result is its actually rolling 1D11 and only subtracting 1 if it comes back 11.

 

I don't think this is a bug, I think its a trade off. Subtraction uses a lot of CPU power, so by only doing the subtraction when absolutely necessary you get a slight speed increase, but at the expense of a slight reduction of accuracy. Now considering how many dice rolls there are in a D&D game this probably adds up to a significant increase in speed which when the game came out was probably necessary. I don't know if this is done with all IE games, but it is done with PST.

[Taimon]

That sounds odd. Subtraction is a rather cheap operation (doesn't get much cheaper than that) and since the IE is written in a "high level language" programmers usually don't care about those kinds of "optimization". The correct result is more important in those cases.

 

Now, in the BG2:ToB executable there is a function that does a "modified random roll". Prototype is like this:

int rand_mod(int range, int mod)

It calls the standard rand function with the range argument and adjusts the result (imul range; sar 0x0F), so that the random number is between 0 and range-1 and adds the modifier afterwards. After that, it checks if the value is still inside the [0; range-1] interval and adjusts the value if not.

 

Your description reminded me of that function, that's why I brought it up. I could be wrong of course, since I haven't looked at the PS:T executable at all.

[Displacer]

Yea, I went through it again. I'm used to seeing a random die roll just calling rand, and using an AND with the needed result, then adding any pluses. This thing is convoluted, it calls rand and divides the result by 100 then appears to do a modulo on that to get the die range (lots of idiv). It then adds any pluses and subtracts 1 if it goes over the original die size, which I assume is because its called with a original plus so it has to reconvert it to the 0 - n range as opposed to 1 - n. Cripes why can't programmers take reverse engineers into account, we have feelings too!

 

At any rate it works fine and my first analysis was incorrect...

[Taimon]

Cripes why can't programmers take reverse engineers into account, we have feelings too!

Because then it would be too easy, would it not?

[igi]

No action to be taken; moving to the archives.