2 options for Windows PNG support

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Blue Baron
    Adept
    • Apr 2011
    • 103

    2 options for Windows PNG support

    Hi I have writen two pairs of functions to read png files in Windows. The first pair uses DirectX 9. The second pair uses libPNG. Both pairs work the same way, by reading the data and putting the images into a GDI bitmap. Both files are attached to this post. I have used the DX9 version in both Z+ 0.3.3 and V 3.2.0. I have used the PNG version only in V 3.2.0. I have posted the first function of the DX9 version in another thread (Angband 64x64 pixel tiles), but that version does not load the display mask from an alpha channel in the file.

    To use add the function prototypes somewhere, like in readdib.h or above init_graphics() in main-win.c:
    extern BOOL ReadDIB_DX9(HWND, LPSTR, DIBINIT *);

    extern BOOL ReadDIB2_DX9(HWND, LPSTR, DIBINIT *, DIBINIT *);
    or :

    extern BOOL ReadDIB_PNG(HWND, LPSTR, DIBINIT *);

    extern BOOL ReadDIB2_PNG(HWND, LPSTR, DIBINIT *, DIBINIT *);


    Then in init_graphics() in main-win.c change the section between /* Load the bitmap or quit */ and /* Activate a palette */ with:
    /* Load the bitmap or quit */

    if (mask)

    {
    if (!ReadDIB_DX9(data[0].w, buf, &infGraph))
    {
    plog_fmt("Cannot read bitmap file '%s'", name);
    return (FALSE);
    }



    /* Access the mask file */

    path_build(buf, sizeof(buf), ANGBAND_DIR_XTRA_GRAF, mask);



    /* Load the bitmap or quit */

    if (!ReadDIB_DX9(data[0].w, buf, &infMask))

    {

    plog_fmt("Cannot read bitmap file '%s'", buf);

    return (FALSE);

    }

    }

    else

    {

    if (!ReadDIB2_DX9(data[0].w, buf, &infGraph, &infMask))

    {

    plog_fmt("Cannot read bitmap file '%s'", name);

    return (FALSE);

    }

    }

    /* Save the new sizes */
    infGraph.CellWidth = wid;
    infGraph.CellHeight = hgt;

    /* Activate a palette */
    Or replace DX9 with PNG in the 3 function calls above.

    Of course you need to have the right headers in your include path and link against the right libraries.
    For DX9 the libraries are d3d9.lib and d3dx9.lib. For the PNG version the library is libpng.lib, libpng15.lib, or whatever you named it when you built it.

    If you want to replace ReadDIB() entirely (after testing this alot), remember that FreeDIB() in readdib.c is still needed.

    These functions are hacks, but they work for me, and may work for you until something better comes along.
    Attached Files
  • takkaria
    Veteran
    • Apr 2007
    • 1951

    #2
    Hey, thanks a lot, we've been wanting to be able to load PNG files on Windows for about four years! One of us will work on getting these integrated sometime soon I think for the ease of cross-compiling, we'll probably be going for libpng, and maybe shipping libpng with the source so it's easier to compile.
    takkaria whispers something about options. -more-

    Comment

    • Shockbolt
      Knight
      • Jan 2011
      • 635

      #3
      Any progress on the PNG matter?
      http://www.rpgartkits.com/
      Fantasy art kits for personal and commercial use. Commercial use requires a Developer license, also available through my website.

      Comment

      • d_m
        Angband Devteam member
        • Aug 2008
        • 1517

        #4
        Originally posted by Shockbolt
        Any progress on the PNG matter?
        I am working on building using the Blue Baron's PNG patch... made a tiny bit complicated by the fact that I am cross building under Linux.

        I'll report back here with any progress I make.
        linux->xterm->screen->pmacs

        Comment

        • Blue Baron
          Adept
          • Apr 2011
          • 103

          #5
          Originally posted by d_m
          I am working on building using the Blue Baron's PNG patch... made a tiny bit complicated by the fact that I am cross building under Linux.

          I'll report back here with any progress I make.
          If I can help, please let me know. But I use VC 6 to compile on Windows, and do not have a development environment on my Linux computer.

          Comment

          • d_m
            Angband Devteam member
            • Aug 2008
            • 1517

            #6
            Originally posted by Blue Baron
            If I can help, please let me know. But I use VC 6 to compile on Windows, and do not have a development environment on my Linux computer.
            Thanks! I will definitely ask you questions once I figure out how to get minw to play with libpng.

            At this point I can:

            1. Dynamically link libpng/zlib. Things compile fine but crash horribly at runtime. This is probably not what we want to do.

            2. Staticallly link libpng/zlib. Things compile fine but the linker explodes. I am trying to figure out how to tell mingw where to find the libraries. For some reason -L/path/to/libpng/lib is not working... either that or CFLAGS are not being used.

            If there are any mingw experts out there who have a good idea how to get this working, I would be thrilled to hear ideas!

            EDIT: I got the "statically linked" version to compile, but it also crashes while looking for a DLL, so clearly it's not really very static at all.
            Last edited by d_m; May 7, 2011, 07:41.
            linux->xterm->screen->pmacs

            Comment

            • d_m
              Angband Devteam member
              • Aug 2008
              • 1517

              #7
              OK, I have a version of angband.exe running which uses Blue Baron's code to enable PNG support. It requires me to have zlib1.dll and libpng12.dll just hanging out in the same directory as angband.exe.... maybe this is OK?

              Windows folks... do you know if the "current directory" gets searched for DLLs when you launch an EXE? Is there some other way a program can say "hey, windows, you should check directory XYZ for DLL files"?
              linux->xterm->screen->pmacs

              Comment

              • myshkin
                Angband Devteam member
                • Apr 2007
                • 334

                #8
                Originally posted by d_m
                Windows folks... do you know if the "current directory" gets searched for DLLs when you launch an EXE? Is there some other way a program can say "hey, windows, you should check directory XYZ for DLL files"?
                Not a Windows person, so take it with a grain of salt, but the DLL search path does include the "current directory". See MSDN (Search Path Used by Windows to Locate a DLL and DLL Search Order) for more details. I am not entirely sure whether there are any variations among different Windows versions here, nor what happens if an incompatible version of zlib or libpng is already loaded. Sounds like substantial progress, though.

                Comment

                • Blue Baron
                  Adept
                  • Apr 2011
                  • 103

                  #9
                  myshkin posted the search order when the DLL's are loaded at load time. AFIK, the way to specify a DLL in a sub directory for most windows is to write a wrapper for the functions and load the dll and get the function pointers manually, after the program has started running. In this case you would not link against a .lib, but write another .c file to load the dll and get the function pointers and compile that into the program.

                  I think if you want to statically link with libpng, the library needs to be compiled such that no DLL's are made. (This is what I did.)

                  Edit: The first link myshkin posted has a explanation of ways of linking with a DLL. So I guess which do you want to do?
                  1. Link Implicitly (use .dll and .lib)
                  2. Link Explicitly (use .dll and ignore .lib)
                  3. Link Statically (use .lib with .dll never built)
                  Last edited by Blue Baron; May 8, 2011, 14:58.

                  Comment

                  • zaimoni
                    Knight
                    • Apr 2007
                    • 590

                    #10
                    Originally posted by d_m
                    OK, I have a version of angband.exe running which uses Blue Baron's code to enable PNG support. It requires me to have zlib1.dll and libpng12.dll just hanging out in the same directory as angband.exe.... maybe this is OK?
                    If that's all you can pull off, yes.

                    On Windows I just build both libpng and zlib as static-only; then there's no DLL issue to look for.

                    Originally posted by d_m
                    Windows folks... do you know if the "current directory" gets searched for DLLs when you launch an EXE?
                    By default, yes. There are Microsoft-provided tools for overriding this, but they don't ship with the operating system (as of Win7 or earlier).
                    Zaiband: end the "I shouldn't have survived that" experience. V3.0.6 fork on Hg.
                    Zaiband 3.0.10 ETA Mar. 7 2011 (Yes, schedule slipped. Latest testing indicates not enough assert() calls to allow release.)
                    Z.C++: pre-alpha C/C++ compiler system (usable preprocessor). Also on Hg. Z.C++ 0.0.10 ETA December 31 2011

                    Comment

                    • d_m
                      Angband Devteam member
                      • Aug 2008
                      • 1517

                      #11
                      So, since there are some pretty knowledgeable Windows devs here, I will take advantage!

                      I've been using libraries/includes which I got from the gnuwin32 site because I couldn't figure out how to cross-build libpng/zlib for windows. The packages I've been using are:


                      libpng-1.2.37-bin.zip
                      libpng-1.2.37-lib.zip

                      Zlib: general purpose data compression / decompression library

                      zlib-1.2.3-bin.zip
                      zlib-1.2.3-lib.zip

                      The -lib archives contain everything except actual DLL files, which are contained in the -bin archives.

                      I can't seem to link correctly against any of the provided libraries (either .a or .lib) using mingw's ld, even when passing -static to everything. I can build with the .a files but angband.exe still looks for (and lacks) the DLLs at runtime.

                      I am willing to just ship DLLs if necessary (and have make install copy them into place) but it would be great to link statically, since people seem to think it should work. If someone could tell me which files in which archives to use (and maybe even which mingw command(s) to run) that would be amazing.

                      Thanks!
                      linux->xterm->screen->pmacs

                      Comment

                      • Timo Pietilä
                        Prophet
                        • Apr 2007
                        • 4096

                        #12
                        Originally posted by d_m
                        So, since there are some pretty knowledgeable Windows devs here, I will take advantage!
                        I'm not sure there are Windows devs here, at least that has been given me as reason why that whole term window flickering when there is flickering monster nearby haven't been fixed yet. It is a major bug, because it renders animate_flicker unusable and slows game down to slow 286 -feel.

                        Comment

                        • zaimoni
                          Knight
                          • Apr 2007
                          • 590

                          #13
                          Originally posted by d_m
                          I can't seem to link correctly against any of the provided libraries (either .a or .lib) using mingw's ld, even when passing -static to everything. I can build with the .a files but angband.exe still looks for (and lacks) the DLLs at runtime.
                          *.lib will fail (that's for MSVC).

                          Native MingW32 pure-static build of zlib 1.2.5 works for all MingW32 versions tested here. (3.4.5, 4.2.1, 4.3.3, 4.4.1, 4.5.2).

                          libpng will not build natively on MingW32 4.4.x or higher; the highest version I can build libpng 1.0.x/1.2.x/1.4.x natively is MingW32 4.3.3. MingW32 4.4.x and higher generate illegal assembly.

                          I use --disable-shared --enable-static for ./configure on both zlib and libpng.

                          Edit Above comments are for building from source tarballs.
                          Zaiband: end the "I shouldn't have survived that" experience. V3.0.6 fork on Hg.
                          Zaiband 3.0.10 ETA Mar. 7 2011 (Yes, schedule slipped. Latest testing indicates not enough assert() calls to allow release.)
                          Z.C++: pre-alpha C/C++ compiler system (usable preprocessor). Also on Hg. Z.C++ 0.0.10 ETA December 31 2011

                          Comment

                          • Spacebux
                            Adept
                            • Apr 2009
                            • 231

                            #14
                            I still don't have a good grasp on the in's and out's of the Pref/ directory file contents.

                            Up to 3.2.0, I could grab any nightly or version, and play with a screen like: http://angband.oook.cz/screen-show.php?id=1925

                            Now, with the string of nightlies post 3.2.0, I cannot get my screen to display such.

                            I have tried uncommenting the first few lines in font.prf:
                            ## F:50:0x01:0x23
                            ## F:51:0x01:0x23
                            ## F:52:0x01:0x23
                            ## F:53:0x01:0x23

                            However, while that does remove the graphic blocks of wall to nice '#' symbols again, it also removes all color from the fonts, as well. And people here KNOW how I love to use font colors.

                            I don't have the luxury of running DIFF on Windoze, easily, to compare / contrast what happened between the versions. Apparently, the menu option of Options -> Graphics -> "None" does not affect graphics in the later nightly versions. Or, have I missed a switch somewhere?

                            -SBux-

                            Comment

                            • Spacebux
                              Adept
                              • Apr 2009
                              • 231

                              #15
                              font-win.prf

                              Now, I did notice a difference in structure in the file font-win.prf:
                              Old (version 3.2.0 and prior) :
                              ### Terrain features ###

                              # Floors (white : centered dot)

                              F:1:1:7

                              # Invis traps (white : centered dot)

                              F:2:1:7

                              # Magma (slate : solid block)

                              F:50:2:127
                              F:52:2:127 ...
                              New (3.3 w-i-p nightlies):
                              ### Terrain features ###

                              # Floors (white : centered dot)
                              F:1:all:1:7

                              # Magma (slate : solid block)
                              F:50:all:2:127

                              # Quartz (light slate : solid block)
                              F:51:all:9:127 ...


                              Is that possibly part of it?

                              Comment

                              Working...
                              😀
                              😂
                              🥰
                              😘
                              🤢
                              😎
                              😞
                              😡
                              👍
                              👎