New version of PNG library (now v3.2.q)
Can't use static version of Zlib
I am having the same problem.
Cannot get fbpng to use the static version
Instead it wants to use zlib1.dll.
Ekkk !!!
-
Cannot get fbpng to use the static version
Instead it wants to use zlib1.dll.
Ekkk !!!
-
Hi Lassar, a couple of things, do you have the DEFINE before you include the header? Like this:
Also, have you looked in your FreeBASIC/lib/$PLATFORM directory too see if there is a libfbpng.a in there? From what I understand other people had problems because they had another version of the library in there and FB was giving it priority.
I think for the next version I will make the static version have another filename, libfbpngs.a, and make the #inclib choose one dependent on PNG_STATICZ being set or not. I hope that will make it easier for people.
Code: Select all
#define PNG_STATICZ 1
#include "fbpng.bi"
I think for the next version I will make the static version have another filename, libfbpngs.a, and make the #inclib choose one dependent on PNG_STATICZ being set or not. I hope that will make it easier for people.
OK, I upped a new version:
If you are using v1.9.3 you should upgrade to this if you intend to use the static zlib version on windows (The build of that was broken in that version).
If you are using v1.9.2 you should upgrade if you use the dimensions functions (A bug in those was fixed in v1.9.3).
Anyone else might just want to upgrade to this version because I reworked some of the code and it's now about 40% faster in my tests.
If you are using v1.9.3 you should upgrade to this if you intend to use the static zlib version on windows (The build of that was broken in that version).
If you are using v1.9.2 you should upgrade if you use the dimensions functions (A bug in those was fixed in v1.9.3).
Anyone else might just want to upgrade to this version because I reworked some of the code and it's now about 40% faster in my tests.
http://www.streetcds.co.uk/fbpng_v1_9_4.tar.gzThe changes for this version are as follows:
1) The prebuilt windows static zlib version was bugged in v1.9.3 due to a misbuild. That is now rectified.
2) Static versions of the library are now built under a new name, 'libfbpngs.a'. This will mean you can keep
both in your FreeBASIC lib/ directory without having any clashes as it takes precedence. Hopefully this
will help stop a lot of the problems people had using the static version.
3) A lot of code has been changed in png_image_convert.bas in order to improve it's efficiency. I am seeing
around 40% faster times on my machine.
Someone asked me about something on IRC, I forget who now, sorry, but he was asking "Why doesn't fbpng work with TRANS PUT?" or something along those lines.
I don't think I specified anywhere before the way fbpng works in that manner. As you know it always returns a 32 bit image. It also always returns an image suitable for ALPHA put. Your TRANS put will only work if you are using magic pink. If in your image editing program you assign a tRNS chunk to your image, stating a transparency, fbpng will use that to set the alpha channels for the image.
So the simple rule here is 'Just Use ALPHA PUT' (unless you know why you are doing something else)
There are some technical reasons I did this.
1) I wanted to return one simple image type no matter what PNG you gave. This means that a user should always get a decent result by just using 32 bit/alpha modes, without having to care about anything.
2) If I had gone the other way, say for example you decided white was the transparency colour. I would have had to go through, and convert all those white pixels to magic pink so that TRANS would work. I consider the changing of your pixel data in this manner to be a bad thing, at least worse than the other alternatives, because I feel like that would be unexpected to people. There could also be subtle bugs in that method. Say for example you chose white as your tRNS colour, in order to use magic pink in your image as a normal colour. Well, that would just explode and consume the earth if you tried to use PUT TRANS, because it would treat both your white tRNS, and magic pink as transparent.
I hope my reasoning on this makes sense, In general my aim with this png library is to be as consistent, simple, and intuitive as I can.
I don't think I specified anywhere before the way fbpng works in that manner. As you know it always returns a 32 bit image. It also always returns an image suitable for ALPHA put. Your TRANS put will only work if you are using magic pink. If in your image editing program you assign a tRNS chunk to your image, stating a transparency, fbpng will use that to set the alpha channels for the image.
So the simple rule here is 'Just Use ALPHA PUT' (unless you know why you are doing something else)
There are some technical reasons I did this.
1) I wanted to return one simple image type no matter what PNG you gave. This means that a user should always get a decent result by just using 32 bit/alpha modes, without having to care about anything.
2) If I had gone the other way, say for example you decided white was the transparency colour. I would have had to go through, and convert all those white pixels to magic pink so that TRANS would work. I consider the changing of your pixel data in this manner to be a bad thing, at least worse than the other alternatives, because I feel like that would be unexpected to people. There could also be subtle bugs in that method. Say for example you chose white as your tRNS colour, in order to use magic pink in your image as a normal colour. Well, that would just explode and consume the earth if you tried to use PUT TRANS, because it would treat both your white tRNS, and magic pink as transparent.
I hope my reasoning on this makes sense, In general my aim with this png library is to be as consistent, simple, and intuitive as I can.
Hello all!
There is a new version of fbpng in the works now.
Thanks to 1000101 who spent a lot of time reworking the code, and adding some new features, I think he made it both faster, and more useful for advanced users.
Here is a test upload of the new version. As so much changed, this is a test/beta release for people to try out, the next 'official' versions will be based on this release.
New features should be covered OK in the README, people who just want to carry on using it as they were should not be affected.
http://jafile.com/uploads/1000101/fbpng_v3_2_q.zip
There is a new version of fbpng in the works now.
Thanks to 1000101 who spent a lot of time reworking the code, and adding some new features, I think he made it both faster, and more useful for advanced users.
Here is a test upload of the new version. As so much changed, this is a test/beta release for people to try out, the next 'official' versions will be based on this release.
New features should be covered OK in the README, people who just want to carry on using it as they were should not be affected.
http://jafile.com/uploads/1000101/fbpng_v3_2_q.zip
Getting a runtime error with version 1.9.4. I feel like I'm going something wrong but I moved the build (libfbpng.a) to the freebasic win32 directory, and all the .bi files for fbpng into the freebasic inc direction. But when I run any of the test sources (test1,test2,etc) I get a runtime error:
R6034
An application made an attempt to load the C runtime library incorrectly.
and then
The application was unable to start correctly 0xc0000142
What am I missing? Thanks for any help.
R6034
An application made an attempt to load the C runtime library incorrectly.
and then
The application was unable to start correctly 0xc0000142
What am I missing? Thanks for any help.
You need zlib, you can downlod the dll here: http://code.google.com/p/fb-extended-li ... /zlib1.dll
or if you prefer a static lib there is http://code.google.com/p/fb-extended-li ... -z-win32.a just rename to libz.a.
or if you prefer a static lib there is http://code.google.com/p/fb-extended-li ... -z-win32.a just rename to libz.a.
I put the zlib1.dll into the example source directory. I now get the error:
zlib1.dll is either not designed to run on Windows or it contains an error. Trying installing the program again using the original installation media... blablabla.
Instead, I removed that and tried putting the libz.a into the freebasic win32 folder, but I get the same error as mentioned in the last post.
EDIT: Agamemnus provided me a different zlib1.dll. It seemed to solve the issues but test1 in the source for fbpng says Fail (compare) on every image. It shows them loading, they seem to appear fine. So I tried loading a 32bit png I made and it displayed with no alpha and crashed the program.
EDIT: I tried using the static define for zlib but it still reports "fail" on the test and crashes loading my alpha png. I've got fbc .20 on windows 7.
zlib1.dll is either not designed to run on Windows or it contains an error. Trying installing the program again using the original installation media... blablabla.
Instead, I removed that and tried putting the libz.a into the freebasic win32 folder, but I get the same error as mentioned in the last post.
EDIT: Agamemnus provided me a different zlib1.dll. It seemed to solve the issues but test1 in the source for fbpng says Fail (compare) on every image. It shows them loading, they seem to appear fine. So I tried loading a 32bit png I made and it displayed with no alpha and crashed the program.
EDIT: I tried using the static define for zlib but it still reports "fail" on the test and crashes loading my alpha png. I've got fbc .20 on windows 7.
The link (http://www.freebasic.net/arch/file.php?id=23) should also contain the updated fbPNG.
~creek23
~creek23
Re: New version of PNG library (now v3.2.q)
Still can't get fbpng to work in dos.
I compiled it to a static library.
When I tried to compile a basic program to use it, I get the following.
dostut7.o:fake:(.text+0x34e3): undefined reference to `PNG_Init'
dostut7.o:fake:(.text+0x34ff): undefined reference to `PNG_LoadFile'
dostut7.o:fake:(.text+0x3518): undefined reference to `PNG_Decode'
dostut7.o:fake:(.text+0x355c): undefined reference to `PNG_OutputRaw'
dostut7.o:fake:(.text+0x36ff): undefined reference to `PNG_Cleanup'
What am I doing wrong?
I compiled it to a static library.
When I tried to compile a basic program to use it, I get the following.
dostut7.o:fake:(.text+0x34e3): undefined reference to `PNG_Init'
dostut7.o:fake:(.text+0x34ff): undefined reference to `PNG_LoadFile'
dostut7.o:fake:(.text+0x3518): undefined reference to `PNG_Decode'
dostut7.o:fake:(.text+0x355c): undefined reference to `PNG_OutputRaw'
dostut7.o:fake:(.text+0x36ff): undefined reference to `PNG_Cleanup'
What am I doing wrong?
Re: New version of PNG library (now v3.2.q)
Your code compiles. But the linker cannot find the listed symbols.
That's your header file (or function declaration) doesn't match the library binary.
That's your header file (or function declaration) doesn't match the library binary.
Re: New version of PNG library (now v3.2.q)
Well I found I was using a different png library then fbpng library.
I have given up on getting pngs to show up in dos.
I have given up on getting pngs to show up in dos.