Uhm... one thing...
Code:
function Swap32(x:word):word;
begin
result:=(Swap16(x and $ffff) shl 16) or Swap16((x and $ffff0000) shr 16);
end;
That doesn't make any sense. Shouldn't X be longword? Word and $FFFF0000 should always return zero on this. Also, if you are shifting right off a 32 bit integer by 16, there's no reason to do an AND on it.
I'd probably also hardcode the byte swaps -- the overhead of the function calls slows down each of these functions in turn.
Playing with checking ifdef cpui386 to add assembler optimized versions of your various routines...
Code:
{$ifdef cpui386}
function Swap16(x:word):word; assembler;
asm
mov ax,x
xchg ah,al { thankfully FPC/Delphi treat AX as the return value }
end;
{$else}
function Swap16(x:word):word;
begin
result:=(x shl 8) + (x shr 8);
end;
{$endif}
(also another case where the "and" is unnecessary due to the bit width and pascal's strict typecasting.)
also playing with making a TP7 back-port as I'm still churning out DOS games, and PNG support would be really handy there.
Bookmarks