Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 34

Thread: BeRoPNG - A very tiny but complete PNG loader

  1. #21
    Quote Originally Posted by deathshadow View Post
    Code:
    function Swap32(x:word):word;
    begin
     result:=(Swap16(x and $ffff) shl 16) or Swap16((x and $ffff0000) shr 16);
    end;
    BeRoPNG should be portable and small (even at source code level) at the same time, so that it should containing no or only few inline assembler parts, but a good optimizing compiler with inline-support and good code peephole replace templates should optimize this with "bswap eax" on x86-32 and x86-64 (what Delphi&FPC does it not yet, but some C/C++ compilers. My big hope for this is the LLVM backend for FPC). The "and $ffff0000" is just for that it's more readable, the compiler will optimizing it out, but that is something you should know (as you probably already do).

  2. #22
    Quote Originally Posted by paul_nicholls View Post
    Any ideas?

    cheers,
    Paul
    Just remove DataSize:longword; and the DataEnd checks from BeRoPNG (change "while (pansichar(DataPtr)+11)<pansichar(DataEnd) do begin
    " to "while true do begin" and so on, but without this it's a security leak then. :-)

  3. #23
    Quote Originally Posted by BeRo View Post
    Just remove DataSize:longword; and the DataEnd checks from BeRoPNG (change "while (pansichar(DataPtr)+11)<pansichar(DataEnd) do begin
    " to "while true do begin" and so on, but without this it's a security leak then. :-)
    Thanks I think I might just leave it then haha

    cheers,
    Paul

  4. #24
    Still, you're swap32 function should be longword, not word, no?

    word and $FFFF0000 === 0 -- ALWAYS
    word shl 16 === 0 -- ALWAYS.

    So in effect:

    result:=(Swap16(x and $ffff) shl 16) or Swap16((x and $ffff0000) shr 16);

    is the same thing as saying

    result:=0;

    Which means on big-endian systems when your swap function is called, you'll get nothing but zero.

    Also, you're sending zero to your swap16 function...

    Code:
    function Swap32(x:longword):longword;
    begin
     result:=(Swap16(x and $ffff) shl 16) or Swap16(x shr 16);
    end;
    Is what you should have there. What you have right now won't work... Thankfully it's only called on big endian systems -- and you've probably only tested little endian.

    It may also need typecasting forced, since swap16 returns word, not longword meaning that shl 16 could STILL result in zero.
    Last edited by deathshadow; 27-08-2011 at 08:28 PM.
    The accessibility of a website from time to time must be refreshed with the blood of designers and owners. It is its natural manure

  5. #25
    Quote Originally Posted by deathshadow View Post
    word and $FFFF0000 === 0 -- ALWAYS
    word shl 16 === 0 -- ALWAYS.
    Sorry, you're wrong. See my code again:

    Code:
    function Swap32(x:word):word;
    begin
     result:=(Swap16(x and $ffff) shl 16) or Swap16((x and $ffff0000) shr 16);
    end;
    The first swap16 call gets "x and $ffff", and the result of it will shifted 16 bits to left, which's correct.
    The second swap16 call gets "(x and $ffff0000) shr 16" or short "x shr 16", and the result of it will not shifted because it was already shifted 16 bits to right, which's also correct.

    I guess, you had simply overlook the correct nested levels of the (...) blocks in my code.
    Last edited by BeRo; 31-08-2011 at 09:46 AM.

  6. #26
    Forgot about this thread... but:

    function Swap32(x:word):word;

    word is 16 bit unsigned... can only contain 0..$FFFF -- therein:

    x and $ffff returns X

    x and $ffff0000 returns 0, always...

    since $FFFF is the highest number WORD can contain, $0000FFFF and $FFFF0000 == 0, ALWAYS. X in your function CANNOT hold a value that would return anything but zero on that second AND.... EVER.

    See what I'm saying? for that function to work X would have to be DWORD and/or Longint... 32 bit... not 16 bit which is what WORD is.
    Last edited by deathshadow; 25-09-2011 at 12:05 PM.
    The accessibility of a website from time to time must be refreshed with the blood of designers and owners. It is its natural manure

  7. #27
    Quote Originally Posted by deathshadow View Post
    See what I'm saying? for that function to work X would have to be DWORD and/or Longint... 32 bit... not 16 bit which is what WORD is.
    Yeah, I know (see the rest of the code), but this is unimportant, since this is 1. just a typo error in the typedef in the functiondef paramdef header (which's quick fixable) and 2. unused on little-endian systems

  8. #28
    I've uploaded a new pure pascal version under the same url http://rootserver.rosseaux.net/stuff/BeRoPNG.pas , which's a bit faster and also compatible to Delphi XE3 & XE4 now.

    And the other http://rootserver.rosseaux.net/stuff...oidSpecial.pas variant fallbacks to cpng (a wrapper unit to the on ARM Android faster c-based libpng implementation, which's a bit for Android's own libpng.so modified png.pas from FPC, so you do need http://rootserver.rosseaux.net/stuff/cpng.pas ), if you're building for the Android target, otherwise the pure pascal code part will be used, if you're building for other targets than Android.

  9. #29
    I tried the pure pas version in freepascal, works nicely I'd add a comment that ImageData is a PPNGPixel for clarity, not that it mattered much.

  10. #30
    I feintly remembered reading long time ago, that FPC PNG would have some non-free licence. But now that i tried to find information, i found nothing. All FPC graphics seem to be of same modifiedLGPL that all the other code. But is FPC implementation heavier than this? Maybe it's coming at the cost of supporting more formats, i don't know. I went through all PNG related source files i could find, and there were none licence differences.

Page 3 of 4 FirstFirst 1234 LastLast

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •