Played Dune adventure for about 4 hours to completion. Things look ok. I'll try the other game (Albion) I had issue with and see what happens.
I don't know about those values. I've seen consistent weirdness with the logging of those CPU cycle related values. As for the early or late video lock, whatever causes it seems at least a lot less likely with the patch applied.
The most weird is that I'm guessing the patch was for those games when played on a win32 platform and the games with troubles on Mac are fine on win32.
Maybe someone else on Mac can double check the patch?
I just finished double checking it. I played Dune 2 for an hour and a half with zero issues (one mission - guess I'm a little slow). This patch definitely appears to resolve the issue.
Is there any chance we can get a rerelease of the OSX distribution with this patch applied? It applies cleanly to the dosbox 0.70 source code distribution.
As for the inconsistency between platforms - I would guess compiler differences are too blame. Apple uses it's own version of GCC IIRC and I assume that is what we are using as that is what comes with Apple's Dev tools. Perhaps the percision of certain datatypes differs between Apple's GCC and the slimmed down GCC environment used in MingW (or whatever you guys use to compile the win32 builds).
What's going on there? Those values are nonsense.
With the precision bug it also makes no sense that some games lock up earlier and some later.
Stack corruption ?
Those cycles=0 make little sense as well. (unlikely that they are always zero)
Is there any chance we can get a rerelease of the OSX distribution with this patch applied? It applies cleanly to the dosbox 0.70 source code distribution.
Depends on the rhoenie, but personally I think 0.71 is more likely to come out. There were some more small bugs that could use fixing.
on the logging
on 64 bit systems Bitu is 64 bit. printf %d with 64 bit gives those 2/4/8 000000h values.
the 64 bit might be why the macs are affected mainly. (core2duo is 64 bit)
I can't provocate any (significant) precision issues if the integer value
stays in the 32bit range, even if using Bit64u+float.
It DOES result in a precision loss in the range that is critical for the vret
timing if the integer value is about 10^3 times the maximal value of the
32bit unsigned integers, but that's not what PIC_Ticks should be.
So is this special to 64bit systems/gcc or something that can't be
reproduced on 32bit systems? Or is there an overflow/unsigned underflow
for the PIC_Ticks somewhere?
The conversion is indeed done differently on 32 bit and 64 architectures.
On ia32, adding a long int and a float is done as doubles internally.
On amd64, adding a long int and a float is done as floats internally.
(Tested with gcc 4.1 in linux.)
A double has 52 bits of precision, which is more than enough. A float has only 23 bits of precision, which is not sufficient, as Qbix showed above.
Er, a question... Does pic_ticks increase forever? If so, just say I play something for a really, really, really long time. Would this precision thing happen again?
