2 options for Windows PNG support

[Blue Baron]

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.

[takkaria]

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.

[Shockbolt]

Any progress on the PNG matter?

[d_m]

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.

[Blue Baron]

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.

[d_m]

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.

[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?

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"?

[myshkin]

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.

[Blue Baron]

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)

[zaimoni]

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).