Transparency/Colour Keys in 16/32 bit

Johannes_Fortmann · February 16, 2001, 5:22pm

I have a little problem using transparency and colour keys with 16 bit
colour.
In 32 bit, my program works without problems, but when I switch to 16 bits,
I can’t use colourkey blits anymore, and certain alpha blits fail also.
In both modes (16 and 32 bit) I don’t have any hardware acceleration for
alpha blits;
although I have a TNT, but that can be due to the bad drivers from nvidia…
(W2K)

The following things fail:
-blitting a surface with alpha channel onto another surface without alpha
channel (the blit is done without using the alpha channel)
-repeatedly using SDL_SetAlpha on the same surface without changing the
alpha value or blitting it is crashing the program

I convert all my surfaces to display format after loading them from disk, so
that is ruled out…

Thanks in advance,
Pius

slouken · February 16, 2001, 6:47pm

The following things fail:
-blitting a surface with alpha channel onto another surface without alpha
channel (the blit is done without using the alpha channel)
-repeatedly using SDL_SetAlpha on the same surface without changing the
alpha value or blitting it is crashing the program

I convert all my surfaces to display format after loading them from disk, so
that is ruled out…

Definitely sounds like serious bugs. Can you put together a simple
sample program that demonstrates the problems?

Thanks!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Johannes_Fortmann · February 17, 2001, 12:53pm

The following things fail:
-blitting a surface with alpha channel onto another surface without
alpha

channel (the blit is done without using the alpha channel)
-repeatedly using SDL_SetAlpha on the same surface without changing the
alpha value or blitting it is crashing the program

I convert all my surfaces to display format after loading them from
disk, so

that is ruled out…

Definitely sounds like serious bugs. Can you put together a simple
sample program that demonstrates the problems?

I’ll try to. The problem is, it only happens in certain situations, i.e. I
have a player who emits smoke when damaged. SetAlpha-Transparent smoke
crashes. Non-transparent smoke does not crash. Alpha channel transparent
smoke does not crash. What I found out yesterday, when I don’t specify
SDL_RLEACCEL, there’s no crash either. And there’s no crash if I simply add
smoke sprites inside my main loop.
This looks like a serious bug in my implementation to me, but then, why are
there bugs only at exactly this position, and only if I use 16bit colour?
Anyway, since there are obviously no known bugs with SDL, it must be my
program (until proven differently).

I’ll mail again when I have the sample program (to prove it’s not my
implementation), so don’t think about it in the meantime…

Johannes_Fortmann · February 17, 2001, 2:23pm

I’ll mail again when I have the sample program […]

So I do. The attached program crashes in 16 bit, but works in 32 bit colour.
There must be something I am doing wrong.
If I take away the SDL_RLEACCEL flag, it does not crash anymore, but then
there’s still the question why it never crashes in 32 bit? If I always paint
at the same spot, it doesn’t crash (?!?), and if I don’t start the blit 26
pixels inside the source, but at pos (0,0), it doesn’t crash, either.

begin 666 test.tar.bz2
M0EIH.3%!629369HJ8M0!Q1_____B41_?__/?^__:O_OW_X_W^= 0-#& MP 9< )X AO@ $54FF6@&E0"$DB: F$FT:$TU-3&FC4QH0VIZAHT!D:!H M:!H`--!H`&C#1,:)IZA"4/*/4:FC)D9&@#0&0TP)HTTT```TT9 `Q#! &T@, MFF at T0:8F!!@`FFFFF ",!&)DP"8C",(P`F3)A,0 at TQ,"# !----,`$8" M,3)@$P`!&$81@!,F3"8A!IB8$&"::::8(P$8F3 )@ “,(PC "9,F$Q M`D0 at 0B0U,2&F-0::!H]0]1HT ````!Z@_5 : : )="G'Q.>42>IS]4Z$7 M/.^&XR%K8H(0:7UCA%Q$7)D at EJ!H@;2"4<XB>UVR)5RE)=W[1&9B2\(PX9@: M7;9=TDV[HA0P8]$3XFB;!M 8,DE&E9Z7G!SC!#"5O">X,V+KO^#Y'9KNDC.[ M$112/0#.28A]8<+E,*4T]W3EMM05"<D-H8V-)#H:"@H at 8^M0=<GOST!*Z\'? M&3E-:(D[@4]E)M%:((18Z0=R1Q0I at QP&8**W6<HVP.^*"B4[I^99*AEWK:YD MU896.YMEU>\[XO_Q]"9S!C'Q!:5PQ;-NANAB8.5:PRG1"D.2AE$%E!&SC8 at 8 M,EHL]QV=W1JB2E)B25:FM:MB\100'">1V3?1:6/!&YI=NQE,R8U)LN&2LX-U MDN<6#+&/C'&[,FYB(,+1)!163-YRIMOFVL:[!O at N$4,D=G)EO89NVDS1 88
M6%4!PJC17, at E63EZ)5N"LJ5CD&Y<NH&BY?=7)-UXQ8,%1<Y<!0X12P:HWM<;
M1?)BV8Z^+$V6DL*%2Y&P[&“52<P1^,Q6]01T1)$72B<O"9IUG:TS65L<[K
MD4V.P9*#=-HRMXU,!<Z#%\A9.+$;)W!J’%^9??9;%L6F:&:Y-I7WJN"5E4X
M”'9<!!H.“DT;A1>YEYOA06,D!L;SF7-D-49,PK at R[-@@?8-3H<QME:!
MK"N!8LL%]E>#3(;CC-[-Q,T9R8M<FU%6”#D8N1M=T0QC&0&”%25HK-G>SHT
MK44$6J[R’3SPI.LMR#7+ at Q@WW.1?,QE$&K%QDT7(=8RTU62<+)62HGBGF>* M+.=%HV&L7!CNB"B(:=7*3E3F"$PU"=N&,/U'5YTHBB?V'1^F2YU/RV('[N_A ML07^)9)11HU.FQ3NP$3B#FE6&.3#A2Q,3A&X)9RAS.ZC8F,+3J1U-<KU,V"D M>8LD$UZJ^7K-#$2D]<S=:N%?6OU+0+8R#=>P+2>TA35 at R=>F%6;JVQ3S.[$C MZYJ&EZ]ZUCS2YYS*LK:R/+6YL[6+/S>O"ME[D$QMTYLKN8H0O41P3LN.:51/ MF)I,CJB)2#*=1YQ*5V!LU&,KSJ4&- TTVV-,&TB\G3&$^<0=$19-YU .<]/+ MK8["FK/HXRF2B8H&;'VNS/55V6)!=NC<6WM]Z(R\$ S3.\SPS<^0’F(:/;,
M/%F)<L(:EN3W_K6J19C/F/RH;NKRX-]CVNT>,X,/R1GEXOWL6 ZAC^3S4W-
MG=^GO24CY8,];3Y_ at YD’>XT9SI<3SG/<IVMZ:<AAKT9_95FYN103XQW>T@>
M0B5)3$8E2Y-<JK=H&’%“K(FVX9343) 6L524#5"A/1,LGBMF$&5”)9(]@#B
M=-,K^,%2P[I2:['EP!+;V’3T&T\KO7EH,‘0&+%"69S7[NED)XV<YMK>Z9%.P M:N^PE:6)W%.B/-$@B8^-P;\6FG##(ZG3B-?@=CZ^K’+R+88^YWY#1T.#"Y\V M^DN6T0?&W4%[OF_$S;;8EE%[LZ"3L$F8BEP9(1Q =8XKQ1&SF-5Y2,V\8K3 M1SN&9M306\8=N^YQH5\.#,ZR"Z2FWQ+]D_<D1ZP(4;8S4 [?#S("4[(3G!
MLU1-0&\4 at O(!B"CZ(];#!7Z8^.HK_X&S;@)1QAC+0\C'"-(4\AL32/7"XA% MEBF9N#@V2BTDH>8603\*>;/RG#+BKNWV9[AA[W$3*%DY6AE#DP>HCP'=&179 M,RSY=&MIK:+=1^WV<>-"VF6!)A#QI3M&L[DI;L<<HU=?BZID2P$^Z)2 QW)* M=-*/81Z>_1:A2J60C';:- <5$""7HG*3+D=UUD2?(Z*R'=,"*R)*TM$''-FA M*-$Y!Z5-II)L,$38D6B1)8C@^U BNO).R"T;HT5<O,/LS&[X]8;Z,N±)?X
MABA[<#UG.F?K6K-8>#O3SVNI+1T%5+P7=NR37P94/1NH6#6O’<-KQ<CPC25
MS(0X@:8T<(&>I=TP5K0^GTWLO ,8VDM;.:EY3W/RJ59;;+R6I,VIDTU(7#
MS986';C$S8R^3(<]&=*<K5 ]'#M7&7-5_-;>\<&I9[HDISF%%NGP5S&NN.' MFYU[W:AP at M$619R'@=D/)Y?%?]Z6Y%0M<CCCY$=Y]^LI*A6HQFW at 6J*/CO&
MQ=KU6Z_++!Z['7 at F3M(RO"/8>Y_UW;70SX1[LGZ2.H;%WBDYE_3"1T18)51
MU$+RBY!85B&P8R&‘4U#DDRI+#4T1+(%<B^5@@^I5$),NGH)%5C!95(UP4I
MHRC&L56:&045C-9&9Q=V>:U#5[W)B;3&(:B61<36EA4#8VI1%[Q98U5FW-$
M,FPH0Q0$&04T-Z;;)"I#,P%,4E444Y;S1)C!%L.(O%KZN\WC3Q.2^2(K6I
JM-\8+LS-[9BT7M;L_[+O[9O’=<VX5/$&9QN=\A_XNY(IPH2$T5,6H
end

slouken · February 17, 2001, 6:49pm

So I do. The attached program crashes in 16 bit, but works in 32 bit colour.
There must be something I am doing wrong.

Nope, it was a bug in the RLE clipping code in SDL.
It’s fixed in CVS.

By the way, if you use RLE acceleration, you should blit the entire
surface. If you blit a rectangle inside of it, the RLE acceleration
must be recalculated and it’s often slower than doing a normal blit.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

David_Olofson · February 18, 2001, 12:43am

Exactly what I was just about to ask about!

So, RLE encoding is managed per surface, and isn’t even trying to
be or “smart” about source rectangles in any way. Fine; it’s probably
the only sane way to do it. (Been there, done that; RLE is kind of
messy as it is with clipping at the target…

Right, then I know how to do what I’m going to do, so back to work…

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Saturday 17 February 2001 19:49, Sam Lantinga wrote:

So I do. The attached program crashes in 16 bit, but works in 32
bit colour. There must be something I am doing wrong.

Nope, it was a bug in the RLE clipping code in SDL.
It’s fixed in CVS.

By the way, if you use RLE acceleration, you should blit the entire
surface. If you blit a rectangle inside of it, the RLE
acceleration must be recalculated and it’s often slower than doing
a normal blit.

Mattias_Engdegard · February 18, 2001, 3:32pm

Nope, it was a bug in the RLE clipping code in SDL.
It’s fixed in CVS.

thanks Sam, and sorry about that. it’ll be rewritten for 1.3 anyway

By the way, if you use RLE acceleration, you should blit the entire
surface. If you blit a rectangle inside of it, the RLE acceleration
must be recalculated and it’s often slower than doing a normal blit.

no it’s not recalculated at all but clipped RLE blits are slower since
the clipped parts have to be skipped at each blit

the recommended procedure when loading artwork crammed together into
a big image file is to copy each sprite into a surface of its own (having
the display format) and set SDL_RLEACCEL on it. For non-RLE surfaces
blitting subrectangles from big surfaces imposes no penalty

David_Olofson · February 19, 2001, 12:48am

Nope, it was a bug in the RLE clipping code in SDL.
It’s fixed in CVS.

thanks Sam, and sorry about that. it’ll be rewritten for 1.3 anyway

By the way, if you use RLE acceleration, you should blit the
entire surface. If you blit a rectangle inside of it, the RLE
acceleration must be recalculated and it’s often slower than
doing a normal blit.

no it’s not recalculated at all but clipped RLE blits are slower
since the clipped parts have to be skipped at each blit

Uh oh… Not very good when blitting from wide surfaces then, that
is, but how about high surfaces? (No row LUT?)

the recommended procedure when loading artwork crammed together
into a big image file is to copy each sprite into a surface of its
own (having the display format) and set SDL_RLEACCEL on it.

Yeah, doing that.

Not that it really matters (I think…), but it seems kind of
wasteful using a separate surface for every single object. That’s a
lot of surfaces in a well animated 2D game…

How much memory does an RLE encoded surface use, total, as an
approximate function of w * h?

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Sunday 18 February 2001 16:32, Mattias Engdeg?rd wrote:

slouken · February 19, 2001, 7:14am

How much memory does an RLE encoded surface use, total, as an
approximate function of w * h?

It depends on the complexity of the transparency pattern, but
usually on the order of 70% of the size of the original image.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

David_Olofson · February 19, 2001, 10:22am

Ok, but… I was thinking about the overhead (structures and stuff),
rather than the actual data. That is, how much does it cost compared
to using the good ol’ sprite “palette” images?

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Monday 19 February 2001 08:14, Sam Lantinga wrote:

How much memory does an RLE encoded surface use, total, as an
approximate function of w * h?

It depends on the complexity of the transparency pattern, but
usually on the order of 70% of the size of the original image.

slouken · February 19, 2001, 6:44pm

Nothing at all. The image data is converted into a bytestream of
interpreted copy/skip commands with embedded pixel data. If there
is any transparency at all, the transparent pixels are removed and
the space for the commands comes from that.

At the very worst case (no transparency), there is an overhead of
~5 bytes for each 1024 pixel scanline.

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software> On Monday 19 February 2001 08:14, Sam Lantinga wrote:

How much memory does an RLE encoded surface use, total, as an
approximate function of w * h?

It depends on the complexity of the transparency pattern, but
usually on the order of 70% of the size of the original image.

Ok, but… I was thinking about the overhead (structures and stuff),
rather than the actual data. That is, how much does it cost compared
to using the good ol’ sprite “palette” images?

David_Olofson · February 19, 2001, 7:55pm

What about the SDL_Surface structs…?

(A few hundred sprite frames and background tiles on an average level in a
well pixeled 2D game… That’s what I’m thinking about. I still don’t think
it matters, but I just can’t seem to get off this thread or something…

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Monday 19 February 2001 19:44, Sam Lantinga wrote:

On Monday 19 February 2001 08:14, Sam Lantinga wrote:

How much memory does an RLE encoded surface use, total, as an
approximate function of w * h?

It depends on the complexity of the transparency pattern, but
usually on the order of 70% of the size of the original image.

Ok, but… I was thinking about the overhead (structures and stuff),
rather than the actual data. That is, how much does it cost compared
to using the good ol’ sprite “palette” images?

Nothing at all. The image data is converted into a bytestream of
interpreted copy/skip commands with embedded pixel data. If there
is any transparency at all, the transparent pixels are removed and
the space for the commands comes from that.

At the very worst case (no transparency), there is an overhead of
~5 bytes for each 1024 pixel scanline.