Grabbing from a PNG... problems...?

[bigsofty]

How can I grab a sprite from a 32 bit PNG? (RGB+Alpha)

I can load in a PNG as a sprite and then use ALPHAMODE -.999 to display it properly blended against the background.

Now I wish to split this PNG Sprite, into smaller sprites but GRABSPRITE is not grabbing 32 bits properly.

If I use the RGB(255,0,128) as a background, draw the PNG sprite with ALPHAMODE -.999, and then use GRABSPRITE, Im still loosing any Alpha channel that is > 0. That is, the GRABSPRITE command is simply masking the Alpha channel to 1 bit, not 8.

I'm getting a pink blurry border as the blended edges don't have any Alpha channel data?

Not sure thats clear...?

[Schranz0r]

first, use 8 bit PNG's
for grabbing a Sprite you can use LOADANIM
then set ALPHAMODE

[bigsofty]

My PNGs have an 8 bit Alpha channel, RGB = 24 bits, this is necassery and works fine for an Alpha blended sprite.  

I cant use LOADANIM, as my  'cutting' is not sequential, and has many different sizes and random positions. The resulting sprites are not all the same size.

Setting Alphamode is not helping because GRABSPRITE is not actually grabbing the textures existing 8 bit Alpha channel, its recalculating it (wrongly in this case) based on RBG(255,0,128).

Ideally I I would like either direct access to a texture bytes (as an array for example) or a way to grab the Alpha channel direct from a GL_RGBA8 or a version of GRABSPRITE that is a simple copier of 4 bytes per pixel as opposed to creating a new alpha mask.

I suppose I could have a go at getting the data myself if I could get a way to locate a GLBasic texture via C?

[Moru]

I would also like something like this. Gave up and used BMP with 1 bit alpha (the pink colour) instead just to get it working...

[bigsofty]

Another option would be to allow the user to define a sprites UVs AND Texture handle by himself, this would allow users to share a texture between sprites. This is more efficient for texture ram and memory in general.

Maybe an idea for the future.

[Kitty Hello]

For grabsprite, draw a rectangle with current background color before drawing the full sprite, then use grabsprite.
For transparency, 24bit png/bmp with any color + settransparency before loadsprite works.
If you need texture coords for your sprite, draw a 4 noded POLYVECTOR.

[bigsofty]

Nope, the 8 bit Alpha channel is lost, its beginning to look like a bug.

Code (glbasic) Select Expand

DRAWRECT 0,0,512,256,RGB(255,0,0)
LOADSPRITE "alphatest.png", 1000

ALPHAMODE -.999
DRAWSPRITE 1000,0,0 // Draw original sprite with Alpha channel from 32 bit PNG, this works great
GRABSPRITE 1001,0,0,256,256 // Grab a new sprite and Alpha channel


DRAWRECT 0,0,512,256,RGB(0,255,0) // Erase all
DRAWSPRITE 1000,0,0 // Original PNG sprite is still working fine and has an Alpha transparency
DRAWSPRITE 1001,256,0 // All 8 bit Alpha data is lost

SHOWSCREEN
MOUSEWAIT

Right click on the above image and save it in your source dir.


OK, now run the program.

Both left and right images 'should' be the same but arnt, the grab is not working properly for all 4 channels.

The left one is the original PNG, the right, the GRABSPRITE produced one.

The background color doesn't seem matter, so the GRABSPRITE, is working on a 1 bit level, so its just producing a mask as apposed a feathered 8 bit gradient.

[Kitty Hello]

Strange. Might be a bug. I'll see.

[Schranz0r]

Gernot,

If Grabsprite grabs a bmp, or a png ?

[Quentin]

ahhhhh

and what's about using SETTRANSPARENCY RGB(255, 0, 0) before?

You'll have another view then.

[AndyH]

Does the display surface even have an alpha channel?

When you draw sprites with alpha channel, isn't it only applying the 8-bit transparency to what is currently under the sprite on the screen and you see the end result correctly.  When you do GRABSPRITE I assumed you would only get an image from the screen, not an alpha channel as well.  Why would the display surface need one?

Perhaps it would make sense for a CREATESCREEN to be able to have an alpha channel to do the kind of operations you want to do, but it doesn't look like it supports it yet.  The SAVESPRITE for example only saves as BMP's according to the help.

I could be wrong of course, but from looking at the help and other languages I've used in the past  this is my understanding.

[Kitty Hello]

grabsprite grabs from the back buffer.
SAVESPRITE saves to png, too (just tag them ".png")

[Kitty Hello]

oops the image is gone now. Sorry, please upload again.

[bigsofty]

The Alpha Channel is their, it seems that GRABSPRITE is not grabbing the full 8 bits...

[Kitty Hello]

My result is:

Do you experience something else?