Vlákno názorů k článku Jemný scrolling na osmibitových mikropočítačích Atari od MilanV - "...a nyní už máte dostatek informací k vyřešení...
-
"...a nyní už máte dostatek informací k vyřešení dnešního případu..." - slavná hláška z detektivního seriálu Hříchy pátera Knoxe, jestli si pamatuji správně, to se k seriálu s pátráním po zapomenutých tajuplných praktikách vyloženě hodí :)
Opět skvělý díl: nic nezamlčuje a přitom čtení krásně plyne, aby člověk mezi detaily neztratil pointu celého "příběhu". Ačkoliv celý seriál je pochopitelně moje srdcovka, tak musím říct, že ten "vypravěčský styl" se ještě vylepšuje každým dílem, alespoň podle mého "zcela objektivního názoru" :D Takže objektivní dík!
A teď za kapitolou, kde už by to nemělo narušit tu plynulost vysvětlování, opět následuje můj tradiční Doslov pro zvídavé
Při posouvání na větší vzdálenost samozřejmě potřebujeme kombinovat jemný posuv s klasickým, po znacích (v textových režimech). A to horizontálně i vertikálně. Že by to znamenalo pomocí 6502 přesouvat bloky paměti? Kdepak, opět pomůže náš věrný kouzelník ANTIC: každý scrollovaný řádek má v DL uvedený vlastní začátek videoRAM. Např. 80 bajtů na řádek. Posun doprava nebo doleva pak znamená jen pro tyto řádky inkrementovat nebo dekrementovat spodní bajty jejich ukazatelů VRAM v DL. Typicky tedy i pro celou obrazovku v max. rozlišení je to INC/DEC pouhých 24 bajtů. Podobně vertikální posun: posuneme ty ukazatele v DL, tj. pro celou obrazovku 2x24=48 bajtů (musíme spodní i horní byte).
Tak takhle se na Atari dělají ta grafická kouzla "s procesorem za studena"... Přidejte si k tomu, že se není potřeba starat ani o vykreslování znaků: stačí jen měnit ukazatel na znakovou sadu, a to i několikrát v průběhu obrazu, jak vidíte na snímcích z her, a vidíte, čím tehdy své uživatele Atari umělo nadchnout...
Ale... Jakmile narazíte na strop možností ANTIC a GTIA, tak se ta složitost pro vás rázem otočí o 180°: detailní informace o ANTIC dodnes nejsou oficiálně zveřejněné. A složité je to až na úroveň konstrukce procesoru... Zkrátka klasický problém "magického pomocníka" :)
-
Zdar a silu, jen takovej dodatekk tomu 'oknu'. Defacto tim urcujes jaka cast pameti se vykresli a teda v praxi potrebujes mit celou scenu v RAM, coz je pri 64K RAM vylozene neprakticke (viz treba Turrican levely na C64: ~100-150 navazujicich VRAM - tj. 100-150K dat, CRAM radsi nepocitaje - takrka *2). Pokud mas tedy rozsahle levely, stejne se skladaji z bloku/superbloku/... a 'rendruje' se nova radka/sloupec - takze musis polochtat klopaky CPU a popresouvat. Pripadne se depakuje on-the-fly - opet posun okna k nicemu. Smysl to ma kdyz kopirujes na pozadi - vis, do jakeho smeru, tak mas treba 1-2 frejmy k dobru. Nicmene to je prakticky double-buffer, tedy trochu jineho, staci par bitu nekde na offset.
Takze tyhle kouzla "s procesorem za studena" jsou nedomyslena - zde schazi zde 'wrap'. Pokud by ANTIC umel zobrazit znaky 0123...X a potom 123...X0 tak by to davalo smysl. Alepon teda nevim, ze by tam takova featura byla. Takhle presne casto funguje HW scrolling - je tam 'wrap' a vyreseno :) Na VICu se takhle da delat fullscreen scolling grafiky. A bez pocitani pixlu be tam tam moc 'levelu' neveslo.
Ten kdo Antic delal nedomyslel tyhle veci v praxy bohuzel (nebo pocitali s Basicem IMHO). Pritom stacilo pomerne malo a dalo by se rict, ze je to dobrej grafickej cip :) Nejvtipnejsi mi prijde HW inverze znaku :)
P.
-
Wrap resi to, ze se nemusim presouvat. Usetrime par cyklu, energii a planeta se zazelena a obraz netrhne :)
Zobrazuju:
0123...X
Postupne shiftuju 'doleva' az fakticky zobrazuju
123...X (nula neni videt, nebo koukaji prave pixly)
Ted se resetnu se shiftem na 0 a mam 2 moznosti (Y=novej znak):
zkopiruju o 1 doleva: 123...XX -> 123...XY
Pokud ale mam WRAP a posunu VRAM +1 tak zobrazuju
123...X0 -> 123...XY
A nestalo mne to nic krom prepisu 0->Y. Pouhe 'okno' do RAM je proste k prdu, neni na to RAM.
Taky to pak cini problem kdyz se updatuje level za behu - treba se borti most za hracem. Pokud pracuju jen ve VRAM jak pisu, nenicim si 'zroj'. Pokud mam okno ve VRAM (mimochodem, misto sta,x uz se musi pouzivat sta (),y -> dalsi cykly navic) tak si temahle 'runtime' animacema nicim 'zdroj' a musim ho pak nejak opravit/nahrat znova. Taktez se moc nedaji optimalizovat animace (nekdy je lepsi updatovat VRAM nez char) a podobne.
P.
-
Ono není problém mít "celou scénu" v RAM, protože pro většinu tehdejších her ta "celá scéna" byla o velikosti třeba 2x2 nebo 1x5 obrazovek. Což v tom textovém režimu znamená, že i v celkovém součtu to zabírá cca jako polovina jedné jediné obrazovky v ANTIC mode F...
Samozřejmě byly hry, které potřebovaly tuto scénu aktualizovat, generovat, protože jejich celá mapa byla ještě větší. Ale i tak je rozdíl, pokud to jako programátor musím řešit jen když hráč ujede vzdálenost třeba 2-3 obrazovek nebo při každém posunu o 8 pixelů...
-
Pavel TišnovskýZlatý podporovateljj hele na něco se to hodilo, na něco ne. Zkusím dát z hlavy příklady, kdy to okno mělo význam:
1) East front, celá mapa byla ve video RAM a nikde jinde, jinak se vše počítalo na pozadí ve VBI (když hráč přemýšlel, připravoval si 6502 další tah), v podstatě to byl mutiprocessing
2) Boulder Dash - ten je zmíněnej ve článku. Taky byla celá scéna jen ve video RAM, nikde jinde
3) scrollovačky typu Defender - nejsem si na 100% jistej, ale na 99% to byl taky jedinej širokej pruh
4) Caverns of Khafka - scrolling všemi směry, IMHO zase jen okno bez přesunů
Kde to naopak bylo nutné zkombinovat s přesuny:
1) Zybbex - tam si nedovedu představit, že by to nacpali bez postupného updatu scény (ale můžu se mýli)
Nevím:
Cavelord a Shreckenstein (stejný autor, podobná technologie, teoreticky to může být jediná velká herní plocha s videoRAM oknem, ale bude to chtít prozkoumat)
-
Pavel TišnovskýZlatý podporovatel
mimochodem ten Shreckenstein (píšu to dobře nebo tam má být Sch...?) má dva nezávislé scrollingy - pro prvního a druhého hráče. To neumí ani VGA, natož jednodušší čipy než ANTIC :-)
-
Paralax a i nezavysle scollingy nejsou domena jen ANTICu nebo vypocetni sily (tu nemame)... Trebas neco tady: https://youtu.be/DQpLAIkNVLE?t=111 Nektery hry to maji nezavisle.
Ad k cemu/necemu. To je ten rozdilnej uhel pohledu. Kdyz to mas tak jak to mate - nemas to druhe. A proto nemate hry jako Turrican a tunu dalsich :) Takze na papire vsechny tyhle veci vypadaji suprove, ale v realu (dle mne) to nekdy nadela vic skody nez uzitku.
P.
-
Máme nebo nemáme, to je relativní. Technologické demo je zde:
https://www.youtube.com/watch?v=kthZdlr6wL0
Ale zase máme Doom https://youtu.be/DuZywAxfGkw?si=ve2CuvtovY56CQ8P&t=66
Nebo https://www.youtube.com/watch?v=zRGpT-Kjxs8 a to už vypadá, že by ten Turrican šel. Ale proč chtít zrovna Turrican, když máme spoustu jiných krásných her, že. Např. https://youtu.be/u9nDCg63wNc?si=zyVzNg1yzhxwRIkw&t=173
Jako jasně, neumí to všechno, ale na tu dobu... Já si nestěžuji. Já teda ne. :-) -
Pavel TišnovskýZlatý podporovatel
dik za odkaz. Jen pro upřesnění: když se na Atárku mluví o fine scrollingu, tak je to většinou pro textové režimy. A tam řešit nějaké přesuny paměti "nic nestojí", to je necelý kilobajt. Turrican na commodoru je čistá grafika?
-
Pavel TišnovskýZlatý podporovatel
no právě, takže se bavíme o přesunech "pár bajtů". I kdyby se to muselo dělat pro každý snímek, tak pořád máme nějakých 25000 cyklů na to to ustíhat, ne? A úplně nejhůř by šel double buffering, ale to se IMHO v "textových" módech nikdy moc neřešilo.
-
Pár bajtů :) Na plnych FPS to je vice nez par bajtu na 1MHz... A ani nakonec nejde o FPS, protoze nakonec v jeden okamzik to musis udelat naraz.
Bajt lze nejrychleji udelat za 4+4 (LDA 16 STA 16), ale spise za 4+5 (LDA 16,x STA 16,x). My mame k dispozici ~20K cyklu (@ 50FPS), po odpoctu DMA a spol. To odpovida ~2.2K 'charu' za frame. U vas o neco vice, zvlaste, pokud zmensite screen a mate vhodny mod :) U nas v realu jeste CRAM a z toho plyne, ze na 'veci okolo' uz neni moc misto. Sice to je dost cyklu navic, ale za ty barvy (a hires/multi kombinaci) to stoji :)
Vsechny Ackove hru jedou pekne VSYNC (pokud nepoustis PAL verzi na NTSC a podobne ;) takze nakonec musis setrit, typicky se pouziva 1 CRAM na 4 znaky, takze misto 4*(lda+sta) mas jen lda+4*sta, coz je podstatny rozdil. Druhak je vhodny vygenerovat lda/sta, to usetri taktez prez tisic cyklu. Double buffer se pouziva kvuly plynulosti, protoze pokud nechces zlomit screen 'kdesi na obrazovce' (a byt VSYNC) tak mas jen 2 moznosti - stihnout to prez/za paprskem, nebo mit 'STA' do jine VRAM a prepnout ja naraz pozdeji. Takze pak kopirovani jeve na polovicnim FPS, ale i tak je to hrozne rychle - 4px za frame.
Takze double buffer - rozhodne jo. Takze v praxi to vypada tak, ze si treba 1 frame pripravis VRAM a druhy frame CRAM+switch. Udelat to behem jednoho frame stoji takrka 90% vykonu a to nikdy nemas (hudba, tick hry, ...). Leda v jednoduchych hrach (kterych je ale vetsina, to zase jo...).
CRAM navic nelze buferovat, je v DRAM mimo 'RAM' (samostate 4 bitove kilo povesene primo na VIC, dokonce v realu horni 4 bity vraci bordel na sbernici).
Navic tim jde krasne rozdelit kod a zjednodusis si engine, protoze se tyhle veci daji rozlozit mimo/do interuptu a zesynchronizovat se. Dlouhodobejsi veci, ktery se deji 'nekdy' pak narusuji strukturu casovani.
Sranda zacina, kdyz do toho jeste dotahujes z drajvu data :)
R.
-
Pavel TišnovskýZlatý podporovatel
tech volnych cyklu na Atarku se uvadi 24800, ale to neni presne. Zalezi na povoleni PMG, jestli je to znakovy rezim, na sirce playfieldu (jak spravne pises) atd. Takze rekneme 24000 max. Mas pravdu, prenosy s adresovanim pres X/Y jsou pomalejsi.
Hele diky za debatu! Jak za starych casu...
-
Kdysi jsem s kamaradem atarakem pomeroval pindiky, kdo jich ma vic a v realu to vyslo, ze u nas bylo na radek 63 cyklu a u vas 64. U nas minus bad lajny (cca ~500 cyklu mene). Takze nakonec byly skoro stejne velci :)
Take dik za pekny pokec. Nekdy mi tyhle debaty u piva schazi... Na novejsich HW to takova zabava neni a vetsina lidi uz nema chut si namahat mozek. Asi to boli...
Kdysi chtel kamarad vysvetlit jak funguji turba i C64/drajvu (5x open colector mezi 2ma systemama prakticky), ale chteli jsme na pivo. Dotahl asi 40 stran dis-asm na traktoru primo do hospy. Slo nam to pekne od ruky :)
Peknej vecer (o:
P.