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...?
first, use 8 bit PNG's
for grabbing a Sprite you can use LOADANIM
then set ALPHAMODE
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?
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...
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.
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.
Nope, the 8 bit Alpha channel is lost, its beginning to look like a bug.
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(http://www.fourwitches.com/images/alphatest.png)
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.
Strange. Might be a bug. I'll see.
Gernot,
If Grabsprite grabs a bmp, or a png ?
ahhhhh
and what's about using SETTRANSPARENCY RGB(255, 0, 0) before?
You'll have another view then.
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.
grabsprite grabs from the back buffer.
SAVESPRITE saves to png, too (just tag them ".png")
oops the image is gone now. Sorry, please upload again.
The Alpha Channel is their, it seems that GRABSPRITE is not grabbing the full 8 bits...
My result is:
(http://www.pic6.us/pic/Ohx3562.png) (http://www.pic4.us)
Do you experience something else?
Yes, although I think my original test image result was a little different.
so... is it right or wrong?
Wrong I'm afraid, both images should be the same if all the RGBA channels have been copied.
The 1st line...
DRAWRECT 0,0,512,256,RGB(255,0,0)...was in, to test if the channels were being copied correctly, its kinda irrelevant, so setting it to ...
DRAWRECT 0,0,512,256,RGB(0,0,0)...results in the correct image but as you can see there is no 8bit alpha channel.
Preferably it should look like this...
(http://www.fourwitches.com/images/png.PNG)
I'm still not certain that GrabSprite would have any alpha information to grab, unless Gernot is storing that with the backbuffer image. But then I would wonder for what purpose as the backbuffer is not transparent, it does not get shown on top of anything else. You just draw to it, and as you draw any sprites with alpha information will get drawn in that way. Grabsprite will only ever grab the pixels as they are seen, like doing a screen copy unless I have that wrong.
Perhaps what is needed is alpha support for the create screen and/or the ability to modify the alpha channel information on sprites through commands?
The issue I found was with the original image - parts of the alpha channel that were very transparent were not drawn at all. I think it is likely to be related to the ALPHAMODE command where values in the range of -0.14 to +0.14 were not being drawn.
If GRABSPRITE could use a sprite as the source... that could solve this?
Then you must use CREATESCREEN. The problem is, that some (especially 16 bit) back buffers do not have any alpha information stored. That's bad, but I can't help. Thus, I'm performing a pixel-per-pixel check when grabspriting from such a back buffer and store the transparent pixels as 0, others as 255. Alpha in between gets lost.
I'm away from my computer just now, I'll give CREATESCREEN a go when I come back.