The ground_texts in grund.cc, in experimental this is done with uint32 .I am not sure about the cleverness part ...
Do you mean you think of this as just a simple clean straightforward fix? Or that you were being too clever and it's still busted?
Ahh, I see - what is the advantage of uint64 here?
The change to uint64 allowed the removal of the 16M tile limit. i.e. Humungous maps are now possible to create, but good luck actually running them.
As you have just found an example of, and there might be more, 64-bit builds on Windows in limited to 32-bit adresse space anyway. The problem is that the OS doesn't know that, so all kinds of things might happen. And it seems that there has been put some effort into hiding these limitations, so they won't be easy to remove.
How are 64-bit builds on Windows limited to 32-bit address space? Or do you mean 64-bit builds of Simutrans (and not other programs) need to be limited to such to avoid nasty effects such as could result from value_t (and all the other hidden others).
I've been trying to convince James that Simutrans is simply not designed for 64-bit compilation, and doing so could quite likely be the source of all the desyncs on the Bridgewater server. Finding a 32-bit Linux server to test with seems an impossible task however. Locally I've run a 32-bit server with no desyncs, but then during that specific time my local 64-bit server wasn't giving desyncs either, which it had been before.
Everytime I turn around, I seem to find another area of Simutrans code that could cause problems when compiled 64-bit. Using MinGW64, Simutrans won't even compile due to the casting of pointers to long. Why MSVC is allowing this unsafe practice I don't know...
Until someone goes through the entire Simutrans code base with a fine comb, I think building it as 64-bit is asking for trouble.
First of all, the hand optimized assembly will not be used. Prissi claims this is critical to good performance, but unless this is for running Simutrans on older CPUs (which aren't 64-bit anyway), I'm not really convinced.
Of course you're the one who finds no benefit to the multithreaded drawing either - you must be running zoomed in on a postage stamp sized window!
The asm block in display_img_nc() is quite useful. Over 75% of the CPU time is typically spent in this routine. I don't see why the asm here is disabled for 64-bit builds, I see nothing wrong. The asm in display_fb_internal() on the otherhand is not good - running afoul alignment... And should you trigger the double whammy of USE_C and ALIGN_COPY like 64-bit builds are, then I swear you can watch the pixels be drawn one by one (GCC will *not* inline memcpy here, hence the function call overhead is huge. Replace memcpy with a simple while loop which the optimizer vectorizes to some nice SSE instructions, and you get an order of magnitude speedup).
The second issue, which is more convincing, is that the size of data structures change. Pointers will be twice as big, as will potentially longs.
Both Linux and OSX are using the LP64 model. Pointers and longs both 64 bits. Windows OTOH is using LLP64 - pointers 64 bit, but longs 32 bit. Hence the potential issues...