New version of PNG library (now v3.2.q)

User contributed sources that have become inactive, deprecated, or generally unusable. But ... we don't really want to throw them away either.
Post Reply
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Post by counting_pine »

KristopherWindsor wrote:I did that in the example I posted above, and in my program, and have seen no errors. That was in .18.4, and I haven't tested much since installing .20.
Imagedestroy should work on all versions of FB <= 0.20.0b. The recent changes were in SVN, so users of this library should make sure they're using deallocate in the 0.21 release.
yetifoot
Posts: 1710
Joined: Sep 11, 2005 7:08
Location: England
Contact:

Post by yetifoot »

counting_pine wrote:True, but if I didn't know better when using this library I'd choose imagedestroy by default, based on the fact that the function returns an FB-compatible image.

It's something to be wary of, with changes like this...
You have a good point there, I should make it very clear somewhere to only use dellocate/free with the image, or add a destroy function to the library I guess.
KristopherWindsor
Posts: 2428
Joined: Jul 19, 2006 19:17
Location: Sunnyvale, CA
Contact:

Post by KristopherWindsor »

Why can't you make it work with imagedestroy() like it does / did in .18.4? I probably have 30+ calls to imagedestroy() and don't want to change that every time I switch between PNGLoad and BLoad.
yetifoot
Posts: 1710
Joined: Sep 11, 2005 7:08
Location: England
Contact:

Post by yetifoot »

KristopherWindsor wrote:Why can't you make it work with imagedestroy() like it does / did in .18.4? I probably have 30+ calls to imagedestroy() and don't want to change that every time I switch between PNGLoad and BLoad.
ImageCreate/Destroy has changed lately, the new code aligns image buffers to a multiple of 16 to make SSE operations easier. In order to do that, some 'trick' has to be done, because the pointer you get from ImageCreate is not the same as the one that malloc returns, it's offset and the original pointer is stored before the data.

I guess I could make fbpng work that way too, so that it would be compatible with imagedestroy instead of deallocate/free, but it is a one or the other choice, I'll have to think a little about it. If I make it compatible with ImageDestroy essential I will break backwards compatibility so I need to think it over.
Merick
Posts: 1038
Joined: May 28, 2007 1:52

Post by Merick »

Would it be possible to just make an overload function for ImageDestroy that would be able to detect if the image is one that was made fbpng?
KristopherWindsor
Posts: 2428
Joined: Jul 19, 2006 19:17
Location: Sunnyvale, CA
Contact:

Post by KristopherWindsor »

Merick wrote:Would it be possible to just make an overload function for ImageDestroy that would be able to detect if the image is one that was made fbpng?
No, fb.image ptrs are fb.image ptrs. :-/

I guess I'll be compiling my game on .18.4 (or .20 if no bugs were added).
1000101
Posts: 2556
Joined: Jun 13, 2005 23:14
Location: SK, Canada

Post by 1000101 »

Well, since the alignment issue with imagecreate was actually a bug and it is now acting like it is supposed to, I say make pnglib use the image create/destroy functions to make properly aligned buffers and tell everyone they will need to update their code a little.

Personally, I use your pnglib but don't touch buffers directly or only access them in a compatible manner no matter the changes (actually obtaining the image pitch, etc, etc) so any changes to the backend won't affect my code (other then recompiling and relinking).
yetifoot
Posts: 1710
Joined: Sep 11, 2005 7:08
Location: England
Contact:

Post by yetifoot »

OK, after a bunch of thinking, I decided the way to go was to introduce a new sub, png_destroy(), that should be used instead of deallocate/imagecreate.

Sorry to anyone who has to change code, but all the ideas I came up with would have caused problems for someone.

Really it was a bad design decision by me in the first place, functions like these should really come in pairs, like allocate/deallocate imagecreate/imagedestroy, so I should have started with a png_destroy from the start.

I have made an update to the first post, the new version is 1.9.1.

You will only need to upgrade to this if you use an SVN build, or once the 0.21.0 FreeBASIC comes out.

There is still a mild issue with the tests as mentioned before, due to a change in bload, but this will not effect actual usage, so I didn't spend time on that today, I'll do that for 1.9.2 :P

With the design improved, if I decided to do anything like make fbpng more SSE friendly for the next version, it will not be any issue, or need any changes in user code, so this should hopefully help in the future proofing.
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Post by counting_pine »

I hadn't considered this before, but now you mention it, it does sound like a good idea. I wholeheartedly approve.


EDIT: By the way, I don't know if you caught my musings on the "default header type" situation a month or two back...
KristopherWindsor
Posts: 2428
Joined: Jul 19, 2006 19:17
Location: Sunnyvale, CA
Contact:

Post by KristopherWindsor »

So you can use the image with Put(), but FBGFX can't destroy the image? o.0
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Post by counting_pine »

Well, FB can't load PNG images either...
yetifoot
Posts: 1710
Joined: Sep 11, 2005 7:08
Location: England
Contact:

Post by yetifoot »

counting_pine wrote: EDIT: By the way, I don't know if you caught my musings on the "default header type" situation a month or two back...
I did see this, but I'm not too sure at this point, as it seems another change that could affect people who rely on the current default, I'll have to think about it more for the next version.
Jojo
Posts: 107
Joined: Jan 04, 2006 20:02
Contact:

Post by Jojo »

the alpha channel of an image buffer doesn't seem to be used when saving PNG files. can you please add this functionality?
Also, how do I have to use PNG_TARGET_OPENGL exactly? Does the library actually resize images to 2^x sizes? If it does that, how can I get the new size? If it doesn't, does it matter a lot if the OGL textures are not square?
KristopherWindsor
Posts: 2428
Joined: Jul 19, 2006 19:17
Location: Sunnyvale, CA
Contact:

Post by KristopherWindsor »

I'd just like to mention again that I'd *really* appreciate if PNG_load() and imagecreate() returned the same type of data. I have an imageloading wrapper function, and it might use bload, or it might png_load onto a temporary buffer and then copy the image to the target, or it might destroy the target and make it point to a new image... and I don't want those local internals to change the destruction functions I call at then end of my program. ;)
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Post by counting_pine »

It should be possible to modify the routines so that they return an image in a format that can be destroyed with the current version of imagedestroy.
If you go into png_image_convert.bas, and change the "out_img = callocate(...)" lines to "out_img = callocate_aligned(...)", and change png_destroy.bas to use deallocate_aligned() instead of deallocate(), then that should work.

Here are the replacement functions you need:

Code: Select all

function callocate_aligned( byval size as long ) as any ptr
    
    assert( sizeof(long) = sizeof(any ptr) )
    
    if size <= 0 then return 0
    
    dim as long buf, buf2
    
    dim as long size2 = size + sizeof(long) + &hf
    
    buf = clng( callocate( size2 ) )
    if buf = 0 then return 0
    
    
    buf2 = (buf + sizeof(any ptr) + &hf) and (not &hf)
    assert( size2 - (buf2 - buf) >= size )
    
    cptr(long ptr, buf2)[-1] = buf
    
    return cptr(any ptr, buf2)
    
end function

sub deallocate_aligned( byval buf as any ptr )
    
    dim as any ptr p = any
    
    if buf <= sizeof(any ptr) then return
    
    p = cptr(any ptr ptr, buf)[-1]
    
    deallocate cptr(any ptr ptr, buf)[-1]
    
end sub

'' example:

var p = callocate_aligned( 10 )

print hex(p)

deallocate_aligned( p )
The significant difference in the _aligned versions is that a pointer to the actual allocated memory is stored 4 bytes before the pointer that's returned, and it's this that needs to be deallocated. But I've also done the necessary work to make callocate_aligned return a pointer that's 16-byte aligned. Otherwise, it would be

deallocate_aligned should be compatible with imagedestroy, although as a courtesy I added a simple pointer check.

But, barring any future changes, either function will successfully destroy images created with either imagecreate or with an appropriately modified fbpng.
Post Reply