 |
Author |
Topic: TGA problems (Read 607 times) |
|
flight404
 
|
TGA problems
« on: Mar 5th, 2004, 12:07am » |
|
Could be something silly i am over looking. I was hoping to spit out a series of saveFrames as TGA using the alpha channel for some compositing. This is what I get...
http://www.flight404.com/p5/testTGA.jpg
--- the red grid is the photoshop background (tinted it red for ease of viewing) ---
Basically, every pixel that isn't BLACK is treated as 100% opaque. Each pixel is either invisible or totally visible... no inbetweens.
Suggestions?
|
| « Last Edit: Mar 5th, 2004, 12:07am by flight404 » |
|
|
|
|
toxi_
Guest
|
Re: TGA problems
« Reply #1 on: Mar 5th, 2004, 12:28am » |
|
don't think it has to do with the TGA export (it's just reading out the pixel buffer), IMHO it's more due to some drawing functions (ie. lines) not setting the actual alpha value when setting a pixel. the alpha component is hardcoded to 100% (255), even though the actual colour is alpha-blended. this is perfectly fine for displaying, only not for exporting. maybe somthing to add to the todo list? 
|
|
|
|
|
fry
|
Re: TGA problems
« Reply #3 on: Mar 5th, 2004, 6:02pm » |
|
hm, this is a bit difficult to know how to address properly. for the main screen, all pixels are set to 100% opaque, so ive you use saveFrame(), it shouldn't actually have an alpha channel (so the fact that you're getting even a binary one might be a bug..)
the alpha values of the drawing area aren't stored since they're only used to composite things as they're drawn to the screen. so in order to do store them, we'd have to add another buffer that just had all the alphas, or convince java to ignore the alpha channel as it was drawn to the screen (otherwise you'd get 'double' alpha). hm, what to do..
|
|
|
|
|
|
