Parallax Scrolling Example

Not one to leave well enough alone … :slight_smile:

I took Nghia’s and David Olofson’s scrolling examples and added simple
2-layer parallax scrolling with layer velocities expressed in pixels/sec.

  • Randi

Regimental Command
Generic Armored Combat System
http://regcom.sourceforge.net

begin 666 parallax.zip
M4$L#!!0(`"Q<4RHZ9@$K?P<``$42```/<&%R86QL87 at O;6%I;BYC
MO5AM<]K*%?XL9O(?3KAS8W RSA.;R_7F;&!)&YLDP*)IY/Q,$):8"="HEIA MHR;Y[WW.KB0D(+?MEWHPEG;/ZW->]JQ/CBMT3-6/3N3XOK.AD1N%OB^#.?4W MSG+EBRI-$QHZ at 2?I;RT:"A^/(GH&+OZE]U+%893\GB\0W<T7TJ$F54>2!1P0 M62#N.8_2HX$?SE08,--8^L*C6V?UYWQ[%H'WTO/ JHS6=M-W$BRO,L]4)BZ5 M\"3C!1F:1^&'KHRE4"0VJT at H!3DRH)7<"%^=*.&VF.FD4OE%!JZ_]@3]H6+/ ME]/6XDUAL3KJW;06,/-9Y>289F$DYE&X#CR"A31UW*_I:T%?20M4/*O\XHF9 M# 2]'0S[[X:#3W>]R>?^#9W:=LO>[EY==C\4=L_U)JMEYT;R7X+"&<4+P6X+ M$6SU:#]2*=:H.^SW[R;WUEG;WEU\;[5?V94=B2%4%QR)$:R?B!Y?W_0AV'KU M6WGIO5Y*Q8YAX!*AEHI.7Y/ZY]H!^(@,L&3(SO.EA9PO&LS!RXO0]Y0VQ5T@ MNF[,8<:O(6YIJ?D.6T6>P-.2<7M:2'>A[58$8HI#F at KR(N=)8P3$F-X-(VA= MA<@QI%]F1!@4$&V5O+V]_,C.GKXNK<#7<P2%;6$WO^BU!_WG_H$NZ!M at L,@^ M;9^].G_]E]_^>GG5[?7?LERK>F;;-F*N?\[:[;-J0R]BN=VVVV8O6[3UHJ8^ MVRZ>::*SXN+.3[7RHY-'.%P*FOOAU/%5JV6\0SI/1NMHYKB"CC5F.3E(.!2* MN=S0^J_-^NF1AY#5#0C.F&66DF(P:X!J&/:F#])0P=+QZ1>^5:QF&$HW!C"
MUY$K)A&>&PBABO4C3+ .ZT- at +0[%@IN$/B)28O07R^A187T)"@0CT at .Z CF
MB/=“JI9&N”@C at 8R:3N8F’=E’=4Y-G:Q:[DCX;([>GT7ADN32F8OG>U
>(,6D
M?:>\L<@VWK/QN2?:]$VGN,&)65 at E"+C4%R[CQ%.KTE?,7<;C'@W8C$E; MWK)>QO7*EW$:#.VO:M"+$LQ9@%[D4NJ=RH]*A2.U=&10XP<GFKLF:L?\_/CE M(0_<3J0[.ZM:YV2Z7'50%];,#YVXT"<GJU#I:![:0]/$7KDK;@FW36E?2&'/ M""DW3R;$QP]1ZK%TOYXV^+N]Y?=B/!M'^H\"_ at O^SB"]#F2LD_SZ[GH\^7S= MZP_JO(=8'=\-QL<<F,G?/UV/:2$B9(U^7<N8GL+HJZ+E&OUH*F(T*-04=9IU M'40G%IM4+A-KB6DKO] B1B+^C#X9WJ+X:ED?;U#6O!MDXU-/\;^_9?JNLXIE M&-3^[+1O;&>!JE::1RS5>Q,ZWM7MQUI5;[2PP72&+"7I2;7"P?HVC)9.7,L% MU!E1WG\+-TI):'8Y(P":$C$7,, 1B6[/$7H_)]\<H#OZB+12+I,]D$D:2IC
MP^P,N]W!S6#XH?^/[[J9W/0ON]W^34Z Z6+X[LIP-=_,M)V-]OEYP^;O.AMJ
M;)G#%HGX2L?7J<‘YB ?N>8[OKGV’\30FZ<Q)7 at GXC%>52V5A$,'K4,'\R/P MUDE4>Z&SJ$YOD*OUBH7ZL4R1K3B#&2O]7J@/E=
>X7$WMM#=TTX?NQ&UV?;
M at 27GE$XO2\ZHI at UHQ<ET(4Q_’;P:=2_^C0>#^YZ at _L[F7MLG0NGG*<K1_L
M$ O-$! &$(4A2&">4C&M5QXO:U at T+NU#N%B6%YNVRP1-4WK<>3’V>S3L;,
MH&8%F:I.%?Q\P (0DD.C4B-V6LS+"]0T’>]T%ZUQIX]DE.46LK7$70@@“S#1
M)GPQBPGY8?)5>/,CFK46W'!$1=CP'927,/!+(JKM/W[\QG[3+]@4RA.F]] MT_LP(.+#396P\"2W[3PQ2]Z;_M<\X/C_@)&UJ[R _)[RO>;;W,/2^N]A1_YE MV.,+%-T\"\UDAW$_SD9?GBR1]#R*M#0U)WY:7YQY*)/ZCM<G^0'^$QV"9\;" M6(T#5%\D] 1,CNNN,78F1AW5QI at VN(DHJ at 9B#@E>E5A0U" 'LW]\A"$T%64X MW#",,'.RKLB!'G0;S"T at 8E^VFZUZ[L^!_O 3WW[-?-O)\UVVG5 at 4V J8]J
MX9B at 1ZGDU!=FI#9^&XJ[D%O#H7!,Q<MA8-RU.]Z)L/0DL;&X(D+AN%+;QEZ MV at K7L>++0 %Q9)9P$&A>?\X(IVP<^%0^#T89)YZ#(RRY\1K6)DA9OBP*KP$] M&>1KSN$F=RAR?;EB*6))SI.3Y#BGY:[-+61[WEUJB1XY*$&-9D?P23IZT<N7 M23TKL9H95VFS);P_23O 2VHS\<80FQ(_I%5#DY:7M1VTL]%M4^PI!^+<,(Q6 MDD^Y#9YY32'FY66T%MK*_\?7O*'JI)%<'P4;2I[S$5;C:U7R\&4#@6EE/]3I M^86>X at U9*ON02R5Q_PG)X66(5F$D at Y99+!E</<AQB 5[]9LKOT>L5W67V8
MX!H:X-E8N&^>K3]'KW3LC,2E\U6D5QV5EZ;AUY,7TCMEKV/,1]33 at BEF&;X
MMINH&.D_C00:4(&W)S#3\1” !5P(S$Q at Z]O!OP%02P,$% @`(5A3*H>N M%Z*V"P``-H<``!(```!P87)A;&QA>"]T:6QE<RYB;7#MFVMP$]<5 at -T_X0<S M)1W:.,1Y-"%NPR/8^"G)MOR0;?EMC!H;<(J#A2U MF2M]; EP.$Q!4)@.BX) MA*1-,H7.A$[!23 %/P@&/["->:=#2('P:FDS:3K3'_VY/:LK75_O2NOU:J6U MZ=XYNK.Z]YR]WYY[[KU'ZW%.:<J.*&])@<\K\(F'S[_A\X.HIU$']/?_$'W\ MA8ZB%5%$D<F%EAM <AY68=V3GJ at 6Q=%A7= 3E;EWF!28#MY(3T85D"<8H4 ? MT at +::6&H/)K"YU$(#VM:Q?&P[B \?GB<P)V7",P73SP'')T60!5B/,NX`PB? MV<CP**+(C)"PKIK0V:9*'G"CX^^==$.F`_7RH_(?0U&\O;2P.TQIRH+Q2\@S MZ7QQL>7EX3HPX-UHB7CXYXOFA:1Y[\D?SS1G:-'Q+&[]BK,5N-Y%\TA%I8 at B MBD at N=)!&GB4<L)<68"OPV K60O/>4R!5L(<2P3/I,PHYMH1[AGR0@ =-L.,F M8"\]V0U%Q \=O(4.P3^BYXO[C%&\'A#>*RZ>A7N5>P=QM at +C1T8>1129X9+[ MY!/&!7,W+'D*B3GNJ8;X:,O2IZT)\YH2YS6GQ+BU+[:F_Y1*CH&OT A=H( % M:X*"2_,\U""@OS'K):CMJ<^B1JXM:0B:;3DO[RQ:O$._</7\'U%)S[?$O]RR M)+8U+K8M><%6U:)=&?%[LA/;"U+?*5&_;]#N+]7L*U+!5VA\2QN_3;UHBVHA MR%:U7U.?^IM"U3O%*JA!$_2Q%31R;5F&[Y9H/JC*^FVM=F?Q8DO"O+WZQ#^E MKOQ\:2W(B:3:DRICEWIM=WI=;V9];Z;IB^QUI[-,(/"U)Z.N.WUM5YKQI,9X M2F,\J68TNS1U7>KZ+K6I)]W4DV;JS3"=S at 1]GQ7+]A374&4"VY,ZXZ%:_9MY M/[>KGWO_%UD]:>OZ4VS]R;9!M6THS3:283N?;AO10DV-9E)CV=18#HB-D6S; M:";N931!?U #0 at VE42,9%)B,:*F)AE100S4,2O6G4*<S-AQ:7;!9%]N6&WOX MC<+36O. at FAK54A>RJ0M9OIM<S*7&=-2E/.J*GKI22%TI\-9ZI at 7:F5ZO&J.? MS8@(0Q at .!H6A>]/7_ZXRQY/UTN[R^(X&PYGL1GA N.?E?.I2/F-[M9BZ5FZ_ M6M(,];6RYNL5XS5N!QUFE'SJLIX1,8;YS* P-$S0P>5:N^JY7QL2C]NJ^G(L M0QJ&&1Z$,2]K_M)@_TNEX\O7''RUP0Z:H _W9S"F;@C#P: P=+?:M*](;4N. M>;<Z]53+Z^=RK3#U%[T\U\N;;U3:;ZQPW%SEO+'""?57JYPWJXG:WPXZH GZ M5XLH$!&&,!P,"D-W:TRPT&Q)S[17)IVPKSRKLT T,OZ!VU;8;U0YOG[=>6NU M\Z^_=-Y^PWEG;<L=HPO7T +MT LZH GZR#\B#&$XY!]88HCGX!I-SZ::<WE- M at _[Y`NR;*QVW:YS?U+7<6>NZ:VJ]U^!^T.2Y;V%JN(86:(=>T %-TC]3-43S M-<CPU+?K4YJ2GCELS1M\VSQ43)TG_;/"<:O&>7=]ZWV+YX'%\[!YT]^<FQXZ MO'7S)FB!=N@%'="<X)\I&OK\DV;KTM3OR4J$'?N(L_C2`=?Y$@<9/^@Q[ZYK M?6#U/'*V/6II^];]YC^\-5Q#"[1#;S#_"#?TQX_M5&K=KHREEJ7S.K=7?G5X MVW!IRQ#'/_?6MSZT;7SD:OMVXY;O-F_[;M-6J.$:6J#]7G#_"#?TQX_M1/+: MK:K%<*Z=::^]]<>=(V4M0YSX08_YS]:V?[5M^W[[CN^W;(<:KJ%%B'^$&/KC MQ]:99(2CLR$NNO^ Z4['WI%RM[S^.9Y8ZX[_&208PQ]9ONG<-UKA at 4-'QO at Y MGE3;NB06>!C_?+IWU."&$U#&]=69XO./+W[*`\1/!/<?6V>R+WX"KZ]([\_C MZ\NW_Q0[9#V_QO<?M#\/%% ^_\ASO at -/_=O>_=EW?N4VR9O_=*E\YQ?.?^3- M#W'^L[<BX3-K95].XT J-9#"=*'4=SC#5\- ,,47=7[)85IP+]2@#W,-(L(0 MAH-!86C(#P^49U ISV+_R,N#_3,>/[+.%XZ?\?4E9SR/KR^T_PP5.^1=[R=3 M)N0_D&_(NQ_^F9O_R'I>L/.?96YYSU,R_[E[8M\%@T?V?*,UCLA_*MSRYF.= M21/SGS*9\WD</^/YCZSY/"O_&=]_9/(/WG_0_CQ82,G\>U UGO_T;JX9*&@: MDO/W,M6=7M]>X,]_J*H^G47F]PGC[UN2I\?[%M_Y_OL&7?^N#8,%E-SY_+0^ MWWW[CWSY#_?]AJSY88#W&_VIS'MI)G_&K[4SN:^U?>/ZTN!T1A,F&A;(9._# M at QBJ*>_[<-OQ!-_Y-7;8=K_GP&43I&3NX9(6^*$Z7&H?+*(&"YL&"AK/Y3?T MZ3:<S3/WZQO at ZU!QTW 9-;+,/K+,`3)<SF at .%%C/ZAK[<D#3?%;7`"9G<\UG M<M9##5;G\K&M=;B4&BFW$X9-?;K&,UD-O1D;CJI6N1-BS:_^Y/IGGH>C[]WO MV7^[8^_7G_SJZ@?NL?UVV+%ADSS>7'6L8?G'U7E_6%/XJ<4`7Z%Q<(_YXG[[ MY8,ND(M>S1[0M%5U-!B.U)5V-!HZ+ ;0_W"E#NJCYHHC]:5<6Y;AH=4%[46I M;LW\NH4_OG;,!4ACAZG^]TQ?M*_Y?.MKGSB*#UGR8-^&K7)7R9+6C!?;<F-W ME\7!5V@\9,T#A8[-RT%(35#87K `:A#0=Z6]`/6NDE=1(VE[=.,REF&;+M:6 M%%,3.S?WR2=FI<Z:7I(V:[9NMOP8!,]<PUP&*6V6S$+PQ%1'SRF>`U1R"8MG MOND%Y"40`&,)_ZTDT0_&@\*)9<[_7)+H*SP*3YAX6#+Y.I5"GV>]RR(*C\*C M\"@\TY!'R7\4'H4G?#Q*_J/P*#P*C\(S/7F4_$?A47C"QZ/D/\%X9)%@\R6C MQ%1'S\9_0_'RR"X^+Z7*_3<4SI]49/\'-$44463Z2]3\1!Z9)AB1!'M%6(D` MDD 2'C#98;B.DA8F(2%!J]66>PM<HY8(>PF30-'K]215PL02`232+0A&ZR_ M at RY0;V20, P"0#S85ZA at 0B&^"@4)C8Y&!!BXP'.$KG&-=* F.=%7"7G(F\.X M5555Y?Y"7F,DI(\=A0BY5.*0P)#T3!51JJNKJR86I(,QR.G#@1<B#W8.\D9 M&/(:`00,)QX>X4AXGR&'-AJ-Z()50T&3 at GFPNZ1R$>+!,)@'"KK -12SV0PU MXL&Q32*AWE!X4,P`$H)!0YN]Q6JUFHF"V_$4<_>ET/TCCH<,(6EYR,DR^@L: MVDH4W 77T,M""@</B808``FND4\P#^)$<<+R$@LFE/G"*QH#0'&Y7# TU'CZ M,!*>0?ZC7]SZ(M<4&A0Q>#P>^ HU8L->8CD3A5_ XTP$#UCAE8X?',T7YD%( M>/I(?Z(=&T^9)$<8>4R0DX4PR"E#,&BWA,(ZU*3E0?XG>="4H0L<WA@&.P>? MK5!+E0+!/7$4X5ABQ3.B)4,(^0>?Q:1_0LS'R"DCUS5K2\3^P3 X-6+!H MQ M,#P+G]QV2!B6?\B9PB44&-:LA<X3.DS B<,+"H=-L)5.SI=4, $=%3!)0V%# MYC_A at R&W;GSN<[-6<J4CGO"1L#9PY <RO9>%1!%%%%'D,9:HT(HA>K8(*W-< M=(CCLLHB:6\7SF</L01S'<#LT"\2CB3Y%'!A_ON?2U-""FN9JG^"%2%^T\V9 M)1!);J^(AY]Q8TE26+,OR[;S?U7"NDTI)?)ET at FMF3]7;L8),!^:,GF0I(U/ M(7<3YY])[SSCMF)<IN<QBHNR at XD++>2W,.T&HF,&<LAPP(A+3<$YW;NKA;M( M2"@BF&O'7%-"`@;0!QB:_CO4<,VB"F451,P_4T(29QB.^&$]<ECUE3+5(LG! M*F+YS-P#72F1+!+F)S-Z,U'62Y388 A3!@XP<'Q/%4FJ%WVB_4/J/,8O0J5% M$JXL/!Y"W]F4WVZ/??D?4$L!`A8+%@+%Q3*CIF2M_!P11(```\` M`````````0`@`("!`````'!A<F%L;&%X+VUA:6XN8U!+`0(6"Q0````(`"%8 M4RJ'KA>BM at L#:’```2````````````( " @:P’!P87)A;&QA>"]T:6QE ;<RYB;7!02P4&``````(@!]````DA,`````
`
end

(Can’t seem to get the KMail to see the attachment as… well, an attachment.
Guess I’ll have to decode it somewhere else. hrmpf)

I was just thinking about parallax… :slight_smile:

More specifically, I was thinking about a front-to-back, zero overdraw
implementation, and as a logical result, I wonder how expensive it wolud be
to change the screen’s clipping rect. Is SDL_SetClipRect() actually doing
anything significantly CPU intensize, directly or indirectly, or can I use
that instead of doing the clipping myself? (The latter seems wastefull as SDL
would have to check everything against the screen clip rect anyway…)

The next step is obviously tiled parallax layers containing color keyed (or
why not alpha blended? :slight_smile: tiles. The point with that is to make good use of
the fact that most parallax layer tiles are either opaque or fully
transparent.

An advanced “beauty trick” would be subpixel accurate scrolling, using
pre-processed tiles. Works only for bidirectional (single axis) scrolling
though, and still requires an interpolation operation to fix the edges of the
tiles. Besides, it’s pretty pointless without h/w pageflipping or retrace
sync, so I’m not very motivated to put that much effort into it. Retrace sync
and/or h/w page flipping on Linux must be fixed first.

Sprites, anyone? :slight_smile:

I just hacked an engine this weekend, but it’s probably a bit on the heavy
side for an example; 1100 lines in 4 files, OO style C. hehe (Sprite
container w/ banks + generic pos/speed/acc, animation and fire/spawning
control system w/ interpolated output.) Could probably cut’n-paste a very
simplistic example from it, though.

//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 18:40, Randi J. Relander wrote:

Not one to leave well enough alone … :slight_smile:

I took Nghia’s and David Olofson’s scrolling examples and added simple
2-layer parallax scrolling with layer velocities expressed in pixels/sec.

More specifically, I was thinking about a front-to-back, zero overdraw
implementation, and as a logical result, I wonder how expensive it wolud be
to change the screen’s clipping rect. Is SDL_SetClipRect() actually doing
anything significantly CPU intensize, directly or indirectly, or can I use
that instead of doing the clipping myself? (The latter seems wastefull as SDL
would have to check everything against the screen clip rect anyway…)

SDL_SetClipRect() is free, since the blit has to clip against the edges
of the surface anyway. This just changes the rectangle used as the edge.
The only drawback is that you can’t set a complex shape as a clip mask
or set of clipping rectangles. If you want that functionality you have
to do the clipping yourself.

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

More specifically, I was thinking about a front-to-back, zero overdraw
implementation, and as a logical result, I wonder how expensive it wolud
be to change the screen’s clipping rect. Is SDL_SetClipRect() actually
doing anything significantly CPU intensize, directly or indirectly, or
can I use that instead of doing the clipping myself? (The latter seems
wastefull as SDL would have to check everything against the screen clip
rect anyway…)

SDL_SetClipRect() is free, since the blit has to clip against the edges
of the surface anyway. This just changes the rectangle used as the edge.

Right, no pre-calculations or anything; should work fine. :slight_smile:

The only drawback is that you can’t set a complex shape as a clip mask
or set of clipping rectangles. If you want that functionality you have
to do the clipping yourself.

Yeah, I’m counting on managing that by treating colorkeyed (and alpha) tiles
as empty tiles, which means that there will be some overdraw in those cases,
but no complex clipping. (In the method I’m thinking of, the actual
renderding isn’t necessarilly done from front to back - only the clipping
areas are generated in that direction, in a recursive manner.)

Well… Guess I should just hack it and see how/if it works. :slight_smile:

//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 Tuesday 20 February 2001 00:10, Sam Lantinga wrote:

Whoa ! The way this “scrolling” thread is heading I think it should be written
up in a document ! Might come handy for a possible SDL Games book :slight_smile:

The only drawback is that you can’t set a complex shape as a clip mask
or set of clipping rectangles. If you want that functionality you have
to do the clipping yourself.

i’m considering complex clipping (stencil masks) for 1.3. To some extent it
can be done quite efficiently

Couldn’t it be emulated with an efficent 1-bit alpha implementation.
RLE’d 1-bit alpha surfaces could easily be as fast as normal colourkeyed
surfaces.

Or is this already done?:)On Tue, Feb 20, 2001 at 11:54:56AM +0100, Mattias Engdegard wrote:

The only drawback is that you can’t set a complex shape as a clip mask
or set of clipping rectangles. If you want that functionality you have
to do the clipping yourself.

i’m considering complex clipping (stencil masks) for 1.3. To some extent it
can be done quite efficiently


Martin

Bother, said Pooh as he ran out of dilithium crystals.

Couldn’t it be emulated with an efficent 1-bit alpha implementation.
RLE’d 1-bit alpha surfaces could easily be as fast as normal colourkeyed
surfaces.

we have these cases:

rectangular source and destination: no problem, we do it right now

shaped source, rectangular destination: no problem, we do it right now
(RLE-coded source surface)

rectangular source, shaped destination: not supported now, but could
be done with RLE-coded stencil

shaped source, shaped destination: not supported either, but could be
done either with RLE-coded source and bitmapped stencil or the other
way around (colourkeyed source and RLE-coded stencil). Blitting an RLE
source onto an RLE destination is quite complex and maybe not worth it

we could also allow the stencil to be >1 bit deep, for antialiased
destination masks. Whether this would be useful remains to be seen

the most useful stencil is probably colourkeyed destination (in
other words, only copy pixels where destination == colourkey)

save the whole message to disk… perhaps edit the non-file message part
(depends on your version of uudecode) and then use uudecode to turn it into a
zip file.On Mon, 19 Feb 2001, you wrote:

On Monday 19 February 2001 18:40, Randi J. Relander wrote:

Not one to leave well enough alone … :slight_smile:

I took Nghia’s and David Olofson’s scrolling examples and added simple
2-layer parallax scrolling with layer velocities expressed in pixels/sec.

(Can’t seem to get the KMail to see the attachment as… well, an attachment.
Guess I’ll have to decode it somewhere else. hrmpf)


Sam “Criswell” Hart <@Sam_Hart>
AIM, Yahoo!, MSN:
Homepage: http://www.geekcomix.com/snh/
PGP Info: http://www.geekcomix.com/snh/contact/

I could be wrong (haven’t looked at the code in a few months :confused: ) but I could
have sworn that SGE had some enhancements like this. You may also want to see
if/how it was done there.On Mon, 19 Feb 2001, you wrote:

More specifically, I was thinking about a front-to-back, zero overdraw
implementation, and as a logical result, I wonder how expensive it wolud be
to change the screen’s clipping rect. Is SDL_SetClipRect() actually doing
anything significantly CPU intensize, directly or indirectly, or can I use
that instead of doing the clipping myself? (The latter seems wastefull as SDL
would have to check everything against the screen clip rect anyway…)

SDL_SetClipRect() is free, since the blit has to clip against the edges
of the surface anyway. This just changes the rectangle used as the edge.
The only drawback is that you can’t set a complex shape as a clip mask
or set of clipping rectangles. If you want that functionality you have
to do the clipping yourself.


Sam “Criswell” Hart <@Sam_Hart>
AIM, Yahoo!, MSN:
Homepage: http://www.geekcomix.com/snh/
PGP Info: http://www.geekcomix.com/snh/contact/

Yeah, might be time to expand some one the theoretical background. Text,
html…?

Anyway, are we going to hack a complete game? :slight_smile:

Well, why not! It’s no that much work actually, especially not with SDL.
All that messy clipped blitting and RLE encoded sprites stuff is already
there. (Last time I hacked a “simple” game, I had to hack a VGA mode-X driver
and asm sprite + tile routines for a week before I could actually begin…)

//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 Tuesday 20 February 2001 01:48, Nghia wrote:

Whoa ! The way this “scrolling” thread is heading I think it should be
written up in a document ! Might come handy for a possible SDL Games book
:slight_smile:

I don’t think it’s a good idea. No matter how well you optimize, a color
keying painter’s algorithm oriented approach is always going to suffer from
the overdraw wasting bandwidth.

The point with clipping is to sipmly don’t touch the areas that aren’t to be
overdrawn, rather than restoring them after every update using some sort of
overlay.

Look at it as an “inverted overlay”. Say you want a game display with an
eliptic view window. Now, you could einther just render into a rectangle that
covers the whole eliptical window, and then draw the elliptical window border
image back, preferably using something like an RLE encoded surface with 1 bit
alpha or color key.

However, with a stencil mask, you could avoid touching the areas outside the
elliptical window at all, saving valuable bandwidth. Some targets can even
accelerate that in hardware.

//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 Tuesday 20 February 2001 12:10, Martin J Donlon wrote:

Couldn’t it be emulated with an efficent 1-bit alpha implementation.
RLE’d 1-bit alpha surfaces could easily be as fast as normal colourkeyed
surfaces.

Speaking of complex clipping, do you have any direct pointers or ideas about
fast and sexy ways of turning a tiled map into an optimized set of clip
rects? In other words, a 2D array of opaque and transparent tiles, where
either the former or the latter ones are to generate a set of non-overlapping
clip rects.

As to what “optimized set of clip rects” means, I’m thinking about the best
or horizontal strips one tile high, vertical strips one tile wide, or
something in between. I’m assuming that horizontal (left/right edges)
clipping can be significantly more expensive than vertical (top/bottom edges)
clipping, at least for RLE source data, but what’s the deal with the SDL
blitting code? Hardware accelerated implementations?

//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 Tuesday 20 February 2001 11:54, Mattias Engdeg?rd wrote:

The only drawback is that you can’t set a complex shape as a clip mask
or set of clipping rectangles. If you want that functionality you have
to do the clipping yourself.

i’m considering complex clipping (stencil masks) for 1.3. To some extent it
can be done quite efficiently

Yeah, that’s what I did. Loooong time since I had to do that, so I didn’t
remember the name of the tool - had to dig around some… heh

Anyway, Looks nice! I like the tite text in the corner. :slight_smile:

//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 Tuesday 20 February 2001 16:16, Samuel Hart wrote:

On Mon, 19 Feb 2001, you wrote:

On Monday 19 February 2001 18:40, Randi J. Relander wrote:

Not one to leave well enough alone … :slight_smile:

I took Nghia’s and David Olofson’s scrolling examples and added simple
2-layer parallax scrolling with layer velocities expressed in
pixels/sec.

(Can’t seem to get the KMail to see the attachment as… well, an
attachment. Guess I’ll have to decode it somewhere else. hrmpf)

save the whole message to disk… perhaps edit the non-file message part
(depends on your version of uudecode) and then use uudecode to turn it into
a zip file.