Page 2 of 2

Re: Aircraft in infinite loop

Posted: 11 Apr 2007, 18:19
by The Noid
Would it be possible to "just" do a global search&replace and change every instance of FRACT to float and MAKEFRACT to (float)? If I only change the moevDirection to float, we get an ugly mix of FRACT's and float's...

Re: Aircraft in infinite loop

Posted: 11 Apr 2007, 20:15
by DevUrandom
If you think that it is not a good idea to just change the move direction, but other variables too, then that's ok.

There are a few things you need to keep in mind when doing a global search&replace:
- Split the patches! One patch to change the code as it currently is into using floats and one patch to make the changes to the move direction.
- You are responsible for this patch (esp. the 1st of the 2) not breaking anything. Which means that you should
  a) have a look at the code to see where problems could arise and
  b) test the code thoroughly in at least campaign and skirmish mode
- You should have a look at networking, savegames and 64bit environments, because it is not 100% sure that the float of one environment is internally stored the same as the float in another environment. There is an IEEE standard, but afaik the C standard does not require that it is respected. My C-book says that the IEEE-754 standard is "often" used. Wikipedia says "nearly all modern CPUs follow this standard".

Re: Aircraft in infinite loop

Posted: 26 Apr 2007, 18:35
by The Noid
Here's a new version of my patch.
  • I changed the directions to float instead of FRACT.
  • Savegames are not changed, it saves the direction as int, as it used to, and converts them back to float on loading. So savegames are just as backwards (in)compatible as the rest of SVN.
  • I tested skirmish and campaign.
  • I've not tested netgames or 64 bit machines.
I didn't try to convert all of WZ from FRACT to float, that's a bit to big of a project for me at the moment :)

Re: Aircraft in infinite loop

Posted: 26 Apr 2007, 22:29
by kage
DevUrandom wrote: - You should have a look at networking, savegames and 64bit environments, because it is not 100% sure that the float of one environment is internally stored the same as the float in another environment. There is an IEEE standard, but afaik the C standard does not require that it is respected. My C-book says that the IEEE-754 standard is "often" used. Wikipedia says "nearly all modern CPUs follow this standard".
iirc, you need to be careful with gcc: there are switches that allow gcc and g++ to completely ignore the standard in order to gain speed enhancements where possible. i don't think any of the -O* switches will make it do this, but don't quote me on this. if c compilers follow the standard as allowed by the c spec, then float should be 32-bit and double should be 64-bit, but handling doubles would be somewhat slow on 32-bit platforms...

Re: Aircraft in infinite loop

Posted: 27 Apr 2007, 12:32
by DevUrandom
Applied with modifications in r1184/r1185