Reading weapon->Step doesn't work as expected — Quarantined Bugs

Saffith 13 Jan 2010, 02:09

If I run this:

ffc script test
{
  void run()
  {
    eweapon wpn=Screen->CreateEWeapon(31);
    wpn->Step=200;
    Trace(wpn->Step);
  }
}

The number in allegro.log is -3.1616. Setting more properties, waiting a frame or two, nothing seems to make it 200.

pkmnfrk 19 Jan 2010, 13:41

Oh, how did I miss this?

Confirmed, indirectly. At one point, I was doing something like:

wpn->Step *= 1.5;

And the weapon started moving slowly backwards! This would be why.

pkmnfrk 25 Jan 2010, 12:52

This has something to do with how fixeds get cast to float... I'm going to do some more investigation this afternoon, but I appear to have worked around it by inserting a cast to int, but that's wrong (since it's not an int!)

Edit: Question. Is ->Step always supposed to be an integer (to ZScript)? Or, might it return 175.5 (meaning, an internal step of 1.755)?

Gleeok 25 Jan 2010, 13:41

pkmnfrk wrote:
Edit: Question. Is ->Step always supposed to be an integer (to ZScript)? Or, might it return 175.5 (meaning, an internal step of 1.755)?

I don't see why you'd want to truncate it. ie: w->step += w->Step * 0.0017; Would be bad.

pkmnfrk 25 Jan 2010, 14:02

Gleeok wrote:I don't see why you'd want to truncate it. ie: w->step += w->Step * 0.0017; Would be bad.

Well, the difference would be whether I can work around it, or whether I need to muck around in the eldrich horrors that are C++'s casting rules -_-'''

pkmnfrk 25 Jan 2010, 23:24

This is fixed. For the curious, here's how it was going down:

<nerd>

As we know, the Step is multiplied by 100 for consumption by ZScript (I'm not sure why, but I bet there was a compelling reason). Further, it's multiplied by another 10,000 to turn it into a ZScript fixed point number. In all, it's multiplied by 1,000,000 from its original value.

Problem is, a fixed point number, as used internally, is capped at 32767 (and decimal places), and so was wrapping around.

By inserting some strategic casts, I was able to convert the number FROM a fixed point into a float, where it can be safely multiplied to whatever value we so choose.

</nerd>

Closer inspection of other values would be warranted.

_L_ 26 Jan 2010, 05:32

pkmnfrk wrote:
As we know, the Step is multiplied by 100 for consumption by ZScript (I'm not sure why, but I bet there was a compelling reason).

In the engine, enemy sprites' Step values (50, 100 etc.) are divided by 100 to get the actual number of pixels traveled per frame (which is a float). The ZScript value is multiplied by 100 so that it matches up with the Enemy Editor value that the users see. I think.

pkmnfrk 26 Jan 2010, 17:41

_L_ wrote:In the engine, enemy sprites' Step values (50, 100 etc.) are divided by 100 to get the actual number of pixels traveled per frame (which is a float). The ZScript value is multiplied by 100 so that it matches up with the Enemy Editor value that the users see. I think.

Ah, yes, that makes sense. 'Sides, it's too late to change it again :P