swordlegend / recastnavigation

Automatically exported from code.google.com/p/recastnavigation
zlib License
0 stars 0 forks source link

R&D and 64-bit #53

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Mesh something in 64-bit or 32-bit
2. Load the mesh data in the opposite platform; 64-bit if you meshed as
32-bit, 32-bit if you meshed as 64-bit

What is the expected output? What do you see instead?
There should be no changes to the parsed data. Instead, if you mesh on
64-bit and load on 32-bit, everything after the header in the data will be
offset by 32 bytes. If you mesh in 32-bit then load on 64-bit, everything
after the header will be coming 32 bytes too early.

What version of the product are you using? On what operating system?
Revision 135 I believe (the newest as of a few days ago), Windows 7 64-bit

Please provide any additional information below.
http://dl.dropbox.com/u/4368377/Auto%20Saved%20Images/ejegpj2n.png <- that
is what happens if you mesh on 64-bit then load on 32-bit.
The fix is quite easy, just make a different struct in the files without
the pointers or include the pointer size in the data.

Original issue reported on code.google.com by Jakob.Bo...@gmail.com on 1 Mar 2010 at 4:42

GoogleCodeExporter commented 9 years ago
Oh yeah, it happens because a pointer in 64-bit is 8 bytes long, and only 4 
bytes
long in 32-bit. That means sizeof(dtMeshHeader) is going to be lower on 32-bit 
than
on 64-bit, as there are 8 pointers in the struct. That messes it up because 
that size
is used in the data generated by dtCreateNavMeshData to indicate the end of the 
header.

Original comment by Jakob.Bo...@gmail.com on 1 Mar 2010 at 10:10

GoogleCodeExporter commented 9 years ago
Pointers are now moved from dtMeshHeader to dtMeshTile, which should allow to 
use
same data on 32 and 64 bit platforms. 

Original comment by memono...@gmail.com on 2 Mar 2010 at 9:37