[PATCH] WithinStarlaneJumps implementation

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Message
Author
tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: [PATCH] WithinStarlaneJumps implementation

#76 Post by tzlaine »

Geoff the Medio wrote:
Geoff the Medio wrote:I think there might be a problem with the present WithinhStarlaneJumps code.
In Universe::JumpDistance why is 1 subtracted from the number looked up in m_system_jumps? With it there, I get natives in the wrong places, and few elsewhere, and without it, things look correct...
To be honest, I don't know. It was there before, so I kept it. I wasn't sure why it was there, but it looked like the previous value was the same as the new one, and so the "- 1" should be preserved. Feel free to fix this if it's incorrect.

User avatar
cami
Space Dragon
Posts: 411
Joined: Tue Sep 20, 2011 10:32 pm
Location: Halle (Saale)

Re: [PATCH] WithinStarlaneJumps implementation

#77 Post by cami »

From Universe::WithinJumpsImpl, rev. 4280:
retval.second = retval.first.size() - 1; // number of jumps is number of systems in path minus one for the starting system
The original distance returned was the number of vertices on the path, minus one, which equals the number of edges on the path. If no path was found at all, -1 was returned.

I don't know what johnson_shortest_paths returns for inaccessible nodes, I suppose some very high value, which should be ok as well for now. However, if a path was found, it returns the edge weight sum along the path, which in our case equals the number of edges on the path. This is the correct distance and so I think we can safely remove the "-1" from JumpDistance().

update: additionally, the same computation has been performed in JumpsBetweenObjects(). Thus, the -1 has to be removed there as well!
Yesterday, we were still on the brink. Fortunately, today we have come one step further.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: [PATCH] WithinStarlaneJumps implementation

#78 Post by Geoff the Medio »

tzlaine wrote:
After a bit of googling, it appears that boost::serialization binary archives aren't portable between OSes. I switched to binary serialization a while ago to reduce the file sizes, but apparently that has broken cross-platform serialization...

I assume you both were running on Linux, though... I don't know if the portability issue would arise between different distros, although it seems plausible.
I wouldn't worry too much about this. For platforms with the same type-sizes (sizeof(some_type) is the same for both) and the same endiannesses, the save files should be portable. And they should even be portable across 32- vs. 64-bit systems, as long as we don't try to serialize longs.
Someone posted a bug report including a save file that I can't open the the latest SVN build with Boost 1.47 on Windows. So, I searched a bit more, and according to the boost 1.47 documentation, the issues with binary archive portability are presently related to floating point types. Are you sure portable binary serialization of FreeOrion saves should be working? It doesn't seem very reliable...

tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: [PATCH] WithinStarlaneJumps implementation

#79 Post by tzlaine »

Geoff the Medio wrote:
tzlaine wrote:
After a bit of googling, it appears that boost::serialization binary archives aren't portable between OSes. I switched to binary serialization a while ago to reduce the file sizes, but apparently that has broken cross-platform serialization...

I assume you both were running on Linux, though... I don't know if the portability issue would arise between different distros, although it seems plausible.
I wouldn't worry too much about this. For platforms with the same type-sizes (sizeof(some_type) is the same for both) and the same endiannesses, the save files should be portable. And they should even be portable across 32- vs. 64-bit systems, as long as we don't try to serialize longs.
Someone posted a bug report including a save file that I can't open the the latest SVN build with Boost 1.47 on Windows. So, I searched a bit more, and according to the boost 1.47 documentation, the issues with binary archive portability are presently related to floating point types. Are you sure portable binary serialization of FreeOrion saves should be working? It doesn't seem very reliable...
No, I'm not. Though why binary floating point representations should differ among the three platforms we support is a mystery to me. It may be a 64- vs. 32-bit build issue.

Post Reply