Hi Melchior,

Melchior FRANZ wrote:
> * Stewart Andreason -- Friday 27 April 2007:
>>      Red: 8-bit
>>      Green: 8-bit
>>      Blue: 8-bit
>>      Alpha: 8-bit        Alpha: 1-bit in danube, and 0 bits in bo105
> 
> I checked an arbitrary file for which "identify" reports 8/8/8/1,
> but after checking the header values it turned out that is in fact
> a normal, boring 8/8/8/8 file. The SGI format doesn't even support
> 8/8/8/1 -- there's no way to specify that in the header! So
> "identify" is wrong, or tries to be clever. No idea where it
> gets this nonsense from.

Oh!? I'll have to dig deeper in my research.

If my {danube|shuttle}-splash.rgb files are actually 8-bit alpha, and they 
work for me, and I haven't heard any reports of problems, then that would 
discount my conclusion.

That would however, explain why my splash files are larger than desired.

> An example is the harrier splash screen. Does it crash fgfs for
> you? (Doesn't for me.)

no. it loads fine.

Yes, identify shows it as 8/8/8/1.
I can't tell if it is or isn't.
Gimp doesn't have an info panel that shows alpha bits, but using the color 
picker, I can't find any pixels with an alpha less than 255.

>>> Can someone send me a link to a splash texture that crashes fgfs
>>> for him/her? And a backtrace for the crash if possible.
> 
>> For the an2-splash with 8-bit alpha color:
>>
>> (gdb) run --aircraft=danube
> 
> Don't have that aircraft. Is the texture available somewhere?
> (separate, not in a 20MB package :-)

Ooops! That was a sloppy mistake.
I might actually promote my work in the _negative!_

Actually, I didn't have the an2 installed, so just copied the splash.rgb over 
to my model directory for testing.

I hear a complaint my models are too big.
...
I can't disagree with that.
Thanks to this thread, I have shrunk my image files by 1/3
   Yea!

Would it also help if I gut the interior and doors, and release a smaller, 
(less functional) version?
I think I'm better off just making a new model from scratch that can be GPL'd.


>> #3  0x404b370f in operator delete[] (ptr=0x9800)
>>      at /usr/src/gcc-3.3.2/libstdc++-v3/libsupc++/del_opv.cc:36
>> #4  0x0854bae9 in SGTexture::read_rgb_texture (this=0x872e208,
>>      name=0x8b31e00 "") at texture.cxx:276
> 
> That's strange. Can you please update sg/fg and try again? (A new
> backtrace would be nice, and the broken(?) texture.) I made some
> changes to texture.cxx. I don't really think I fixed the problem,
> but one never knows.  :-)

That'll take days. I was waiting for the next tarball point release before I 
break my system. ;)

>>> The "Shared Rows" percentage says that it's "aggressively" compressed.
>> That's an interesting detail I don't know about.
> 
> I assume that KDE's image file module is the only way to check that. I
> wrote it.  :-)

Ah, very nice then. :)

Stewart


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to