80 RECTANGLES¢Radek ③t%rba, RASTER¢¢Na prvn) ro'n)k 8bitov[ demoparty Forever 2e3, kter* se konala v minul[m roce v Tren')n%, jsem si p@ipravil p@)sp%vek do kategorie Intro 1024 bytes - tj. demonstra'n) progr*mek limitovan` maxim*ln) d[lkou 1024 byt+. M%l jsem velkou radost, (e m+j v`tvor n*v&t%vn)ky zaujal a ve sv[ kategorii na Atari zv)t%zil. Pokud jste si u( toto Intro pustili a zaj)m* V*s, jak`m zp+sobem je tento efekt ud%l*n, 't%te d*le.¢¢Program p@edv*d) plynul` ╱50 sn)mk+ za sekundu$ pohyb 80 r+zn% velk`ch obd[ln)k+ v nejjemn%j&)m grafick[m mdu p@es sebe, co( v sou'tu p@edstavuje p@esun 18560 pixel+ ka(dou 1/50 sekundy. Pokud zn*te alespo '*ste'n% v`konnostn) parametry At*rka, je v*m jasn[, (e toto nen) teoreticky mo(n[ st)hat. Ov&em prakticky ano, za pomoci n%kolika trik+.¢¢Trik 1.¢Vodorovn[ strany obd[ln)k+ nejsou v+bec vykreslov*ny - na to je pou(ita PMG. X-ov* pozice PMG hr*'e je m%n%na v ka(d[m zobrazovac)m @*dku, celkem je tedy jedin[ "PMG['ko" vyu(ito na v&ech 80 horn)ch i 80 doln)ch stran v&ech obd[ln)k+. Pokud p@em`&l)te, jak posouv*m PMG objekt vlevo-vpravo s p@esnost) na jeden bod nejjemn%j&) grafiky, kdy( PMG lze posouvat minim*ln% po dvou bodech, tak je vyu(ito toho, (e do pozad) na krajn) pozice strany jsou dokreslov*ny pixely v GR.8. Tyto ji( jsou posouv*ny jemn%, ale PMG je posouv*no jen jednou za dva posuny pixel+, tak(e se bu⇦ s koncem strany jedn)m bodem p@ekr`vaj), nebo stranu o jeden bod prodlu(uj). PMG i GR.8 maj) nastaveny stejn[ barvy, d+sledkem je tedy zd*nliv` posun po jednom pixelu.¢¢Trik 2.¢Jak zn*mo, velikost videopam%④i cel[ obrazovky je d*na vyn*soben)m po'tu @*dk+ videopam%t) pot@ebnou pro ka(d` @*dek. V p@)pad% grafiky 8 je to 40 byt+ na @*dek. 160 @*dk+ by tedy znamenalo 6400 byt+ videopam%ti. Ne v&ak v p@)pad% tohoto Intra. Pomoc) displaylistu je zde toti( definov*no, (e videopam%④ v&ech @*dk+ za')n* na stejn[m m)st% - cel* obrazovka tedy vyu()v* pouze 40 byt+. Logick`m d+sledkem je, (e v&e co namalujeme do "prvn)ho" @*dku se zobraz) i na v&ech dal&)ch. Tud)( v takov[m grafick[m mdu m+(eme malovat pouze svisl[ '*ry shora dol+ p@es celou obrazovku, nic men&)ho ╱(*dn[ jednotliv[ pixely$. Dost nepou(iteln* grafika pro norm*ln) ]'ely, @)k*te si asi, ov&em my p@ece nepot@ebujeme (*dnou norm*ln) grafiku. A te⇦ p@ijde j*dro triku. Do 40 bytov[ videopam%ti p@ipisujeme postupn% a( b%hem vykreslov*n) obrazu, tak(e bod)k, kter` jsme tam zapsali t%sn% p@ed t)m, ne( se vykresloval na obrazovku prvn) @*dek, se zobraz) na prvn)m @*dku. P@ed druh`m @*dkem p@ikresl)me do t[ sam[ videopam%ti bod)k dal&), co( zp+sob), (e se na druh[m @*dku objev) jednak op%t bod)k z prvn)ho @*dku a nav)c i bod)k druh`. A tak d*le - p@ed vykreslov*n)m ka(d[ho @*dku na obrazovku v(dy dokresl)me do videopam%ti dal&) bod)k. Ve v`sledku dos*hneme zobrazen) svisl`ch 'ar, kde ka(d* bude za')nat o 1 @*dek n)(e. X-ovou pozici t%chto cel`ch 'ar p@itom ovl*d*me v(dy pouze pozic) p@)slu&n`ch horn)ch bod)k+. Aby svisl* '*ra nevedla a( ]pln% dol+, v doln) polovin% vykreslov*n) obrazovky naopak jednotliv[ bod)ky odmaz*v*me. ¢¢Proto(e svisl[ strany obd[ln)k+ jsou dv%, v horn) polovin% tedy b%hem vykreslov*n) obrazu v ka(d[m @*dku p@id*v*m 2 body a v doln) '*sti op%t v ka(d[m @*dku dva odmaz*v*m. T)m m*m tedy k dispozici 2 x 80 svisl`ch ]se'ek.¢¢Ve skute'nosti to v&ak nen) tak jednoduch[, jak je zde pops*no, nebo④ rychlost procesoru nesta') ani na to, aby st)hal v ka(d[m @*dku zm%nit pozici PMG a domalovat 'i smazat dva grafick[ body. Na to je pou(it dal&) trik.¢¢Trik 3.¢V`po'ty pro postupnou zm%nu obsahu videopam%ti nejsou prov*d%ny a( b%hem vykreslov*n) obrazu, ale b%hem VBI. Vypo'ten[ hodnoty, obsahuj)c) ur'en) kter[ byty se maj) m%nit a na jak[ hodnoty, se pr+b%(n% ukl*daj) do pol) a jsou pou(ity "pr*v% v 'as" p@i vykreslov*n) obrazu. I tak se to st)h* t%sn% a spousta v%c) musela b`t maxim*ln% optimalizov*na. Dal&) optimalizace byly nutn[ kv+li omezen) velikosti na maxim*ln% 1024 byt+, ale nakonec se v&e poda@ilo.¢
