Aircraft in infinite loop

Our old place to report Bugs, it's not used anymore. To report bugs, please read this topic.
The Noid
Rookie
Rookie
Posts: 21
Joined: 09 Mar 2007, 12:14

Re: Aircraft in infinite loop

Post 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...
User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: Aircraft in infinite loop

Post 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".
The Noid
Rookie
Rookie
Posts: 21
Joined: 09 Mar 2007, 12:14

Re: Aircraft in infinite loop

Post 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 :)
Attachments

[The extension has been deactivated and can no longer be displayed.]

User avatar
kage
Regular
Regular
Posts: 751
Joined: 05 Dec 2006, 21:45

Re: Aircraft in infinite loop

Post 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...
User avatar
DevUrandom
Regular
Regular
Posts: 1690
Joined: 31 Jul 2006, 23:14

Re: Aircraft in infinite loop

Post by DevUrandom »

Applied with modifications in r1184/r1185
Locked