Hello Andrew, hello all,
in Delphi, my real world most used programming language, there is the data type currency:
A number stored as an 8-byte, two's complement integer, scaled by 10,000 to give a fixed-point number with 15 digits to the left of the decimal point and 4 digits to the right. This representation provides a range of 922337203685477.5807 to -922337203685477.5808. That is useful for calculations involving money, or for any fixed-point calculation where accuracy is particularly important.
Initially (inherited from TORCS) the data type used (tdble) was defined to be a custom data type. This was to be able to switch between float and double easily by just changing one line of code. It would be a nice test to just define it as data type currency and have an integer math without additional code changes needed ;-).
(But AFAIK this is not used consequently in SD and the robots).
Just to throw my 2 cents in, I know of only one game that overcame the issue W-D raises here - different results on different machines/OSes/chipsets due to floating point or double precision arithmetic. That game was an old Bungie title called Myth (they released it between Marathon and Halo) which had an ingenious method of calculating everything with integers. It was so effective that multiplayer just needed the player commands to be sent across the network along with an occasional random-number check to make sure all players were in sync, hence it could support games of up to 16 players using 56k modems back in 1997.
This isn't much use to SD unfortunately, as I imagine there's no way the entire physics and collision engines could be re-written to use integer math, but I thought it worth mentioning anyway :)
From: Wolf-Dieter Beelitz <email@example.com>
To: 'Kristóf Kály-Kullai' <firstname.lastname@example.org>; email@example.com
Sent: Sunday, 30 September 2012 6:30 PM
Subject: Re: [Speed-dreams-devel] Network test today
Hello Kristóf, hello all,
if you have a look to the reported results from the TORCS endurance world
champion ships you can see how large the differences are between different
hardware (all use the same code and the same setups).
There are two result sets to compare. One is the result of the qualifying.
Here only one car is driving. TORCS uses a new rule this year and this means
that a car may not hit the barrier while qualification. At street-1 my team
Los Lobos (Lobo Malo, Lupo Bianco) drove well on my system, but hit the
barrier in the second and third lap at Bernhard's system and in all laps at
Daniel's system initially resulting in being last starter (Therefore Daniel
reduced the speed scale factor about 2% and made my team work well on his
>From the past we know about many cases where Andrew and I got exactly the
same result for qualifying cause we both used a windows system with the same
chipset. But the race results always differ.
SD and TORCS get different results on different hardware. One thing may be,
that the calculation is done with float not double precision. But I assume
the differences would be present on double precision as well.
Therefore I guess, that we need some sort of position/force synchronization
between the systems in network mode.
I assume, we will not need it for each time step (500 Hz) or robot call
(50Hz), but maybe we can use a three step approach, one step only commands
are send, second step (may be each 5th step) position is added and each 10th
the third step sending position and forces.
The direction of the synchronization does matter as well. I assume using a
multi master scheme would be best, where each system is the master for the
car that the human player is driving on it while the slave for all the other
cars. If additional robots are used, the server could be the master for
these cars. For most connections downstream is faster than upstream. Sending
the details for the own car only but receiving the details for all cars
would match this for all the clients, only the server should have fast
upstream as well.
May be the steps can be adjusted based on the quality of the network
connection as well (fast connection more data, slower connection less data
but larger corrections).
And one more thing: I want to be spectator! Means we should have additional
non driving clients allowed, only receiving data.
This would allow racing stewards for future championships as well as real
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Speed-dreams-devel mailing list