Hello people!
Thanks for pointing out the problem.
To the BGRAbitmap maintainer(if this code really stems from BGRA code..) : Why? It is silly...
Please avoid calling it silly though. I am not comfortable with that.
I have just installed Lazarus 1.6 64bit. I am positively surprised that it handles nicely the fact that I have another version of Lazarus.
As Michl has said, the problem is that Abs cannot handle QWord.
To be more precise, I think that after subtracting a value to the QWord, it could be either a QWord or an Int64. The compiler considers it then to be an integer of undefined size and as Abs can take either 32-bit or 64-bit values, the compiler does not know what to use.
In all cases, it is easy to prevent this by adding an explicit type cast to NativeInt. Just did that on the repositories.
on a 64bit processor it is debatable if it simply should not be declared as longword, or cardinal, instead of the Native width of the processor. After all: it is just a 32bit calculation, also on a 64bit OS. I think it is wrong in this place to try to use a qword for the operation that is intended
So you say that because the calculation fits in a smaller size, you would follow the principle of storing it in a smaller variable?
I am following the principle that the computation is made using a 64-bit register, so I store the value with this precision to avoid conversions.
I am not sure what is faster here.
@Circular: can you read reply #3, plz? Because I am not sure YOU made that mistake.
Which mistake are you talking about?
Though this error and later issue with DoExecuteNormal in the bgrafilters.pas are easily corrected
Yes, I made a mistake regarding branching with 64-bit. I have fixed it on the repositories.
bgrascenetypes.pas(631,1) Error: Internal error 2012090607
Ah, that's a compiler error. I will try a fix that worked for somewhere else, to add {$OPTIMIZATION OFF} around it.
Please try using version from SVN or from Git and tell me if it works.
Regards