Na starých barevných televizích se ten obraz pěkně „rozpliznul“, takže i ten režim multicolor (třeba 160×200, co měl komodor) vypadal docela koukatelně. Teď v článku mi připadají příliš hrubý i ty malý screenshoty a říkám si, jak jsme na to mohli celý ty roky s kámošem koukat. Ještě podotknu, že v té době měl jeden spolužák PC (rozuměj obrovské monochromatické XT), ukazoval mi na tom Budokana a vyprávěl mi, jak hrál u někoho něco na C64 nebo Atari a jak to mělo super grafiku a zvuk.
To je pravda. Kamarad si k Atarku poridil monochromaticky monitor (Atari XL melo video vystup bez VF modulace, nektere dalsi varianty Atarka mely konektory resene jinak) a ty hry vypadaly o hodne hur nez na bezne televizi, proste kosticky :-)
Asi nejlepsi bylo v te dobe pouzit Ataracky video vystup spolu televizi, ktera mela naopak video vstup (nektere Tesly apod.), to bylo presne na hranici mezi rozmazanym obrazkem a „kostickami“.
Inspiroval jste mě k nějkému bádání, podařilo se. Skript se dá stáhnout odsud: http://sysinf0.klabs.be/…ostalgia.css?…
(přesný link ke stažení je: http://sysinf0.klabs.be/…ostalgia.css?… )
Nakopíroval jsem ho do C:\Program Files\Opera\Styles a pomocí menu View → Style → My style sheet si jej nastavil, tj. zadal jsem cestu C:\Program Files\Opera\Styles\nostalgia.css .
Vypadá to super. Moje opera je 9.63 Build 10476.
Další možností, jako použít sprity, bylo vytapetování obrazovky na místech, kde jste potřebovali víc barev, než grafický režim umožňoval. Tady je ukázka, i se zdrojákem:
http://ftp.penguin.cz/…tari/tetris/
Režim 320×něco byl zcela monochromatický – pouze dvě vybrané barvy. Na screenshotech je ovšem režim kombinovaný – dolní příkazová sekce používá textový režim.
Je to tak. Pri rozliseni 320× neco se jeste pouzivala finta – color artifacting. Sude sloupce mely diky vlastnostem PAL modulace a hw rozliseni obrazovek (i v NTSC neco podobneho bylo) jinou barvu nez liche. Nektere hry toho vyuzivaly, i kdyz vysledek krasou barev spis pripominal CGA. Vice napr. zde: http://www.atariarchives.org/dere/chaptD.php Protoze na LCD tyhle artefakty nefunguji, nektere emulatory (Atari800Win Plus) umi tyhle artefakty vytvaret umele, aby aplikace vypadala stejne, jako original HW na CRT.
To je ta finta, ze za urcitych podminek, vedle sebe 2 cary s ruznou barvou vyrobili dalsi barvu ? To jsem zkousel a bavil se tim, dali se vyrobit dalsi barvy. Taky jsem mel tusim +256MB rozsireni na Atari , a pres ty banky slo udelat 4 ruzne obrazovky, a preblikavanim dosahnout CGA rezim , no ale blikalo to :D
Ano, to je ono. Nejlepe to fungovalo s normou NTSC, trosku i na PALu. Problem byl, ze ruzne televize se chovaly odlisne a jeste take v zavislosti na tom, jestli se do nich privadel VF signal nebo separatni video+zvuk.
Nektere emulatory se to skutecne snazi napodobit, ale neni to stale ono (staci si v Basicu vykreslit horni pulku stranky v GR.8 „lichymi“ carami a druhou pulku stranky „sudymi“ carami na realnem Atarku a potom na emulatoru). Taky se samozrejme spatne emuluje prepinani obrazku s frekvenci 50/60 Hz, jak to delaly nektera dema pro zvyseni barev pomoci blikani nekterych pixelu.
Obrázek 7: Kombinace grafických režimů ve hře International Karate.
Ach to jste mě dostal. Tohle jsem pařil, myslel jsem že už to nikdy neuvidím… Ještě pak hru Captain Bieble, nebo tak nějak. Od ty doby co jsem prodali Atari jsem už pak nikdy hry nehral a pocitac pouzivam uz jen na praci…
Na ty hre je (krome hudby samozrejme) zajimavy kolik se jim podarilo dostat na obrazovku barev. Jenom v dolni casti kde stoji hraci je jich 5. To by sice znakovy mod ANTIC 4 mohl zvladnout, ovsem ti hraci muzou prijit az k sobe a castecne se prekryvat a to uz by byl problem (5 barev se ziskavalo tak ze kdyz jsem misto barevneho znaku s kodem A vytiskl znak s kodem A+128, tak se zmenila barva pozadi na 5 tou barvu a puvodni ctvrta se v tomto znaku nemohla vyskytovat).
Takze myslim ze spis pouzili sprity. Konkretne myslim ze kimona karatistu jsou tvorena vzdy 2ma sprity vedle sebe (karatista sice muze mit kimono sirsi nez 16 bodu, ovsem na kazde radce ma maximalne 2 osmibodove souvisle useky – pripadne by se dal sprite jeste na nekterych radcich prepnout do nizsiho rozliseni, coz by se dalo vyuzit pro nakresleni rozpazenych rukou). Zbytek karatisty je nakreslen do framebufferu v modu ANTIC 0×E.
Taky je zajimave si vsimnou hory Fuji a stromu v pozadi. Vypada to jako by slunce a nektere listy byly tez nakresleny pomoci spritu.
No muzu si tu hru stopnout v emulatoru a podivat se na vypis display listu + nastaveni registru GTIA (pokud si teda jeste pamatuju, co ktery registr ridi, ale asi to budu mit nekde v poznamkach :-). IMHO to budou opravdu sprity, kazdy karatista jsou dva osmipixelove sprity + strely na oci, nohy atd.
Dulezite take je, ze se hraci nikdy nedostanou tak vysoko, aby prekryli horni obrazek, takze v dolni casti skutecne muze byt nastaveny jiny graficky rezim (viz zmineny DL).
Ja myslim ze strely na oci a podobne nevystaci. Protoze treba vlasy jsou prilis siroke. Takze bud (pokud karatista nemuze zvednout ruce na uroven hlavy) je to tentyz sprite jako kimono, jen s prepnutou barvou a nebo je sprite jen kimono a zbytek se kresli do framebufferu.
Krom toho je tam dole cerny stin dost siroky a taky telo ma dalsi barvu a na to by strely nevystacily.
Jestli se opravdu podivate v emulatoru na nastaveni GTIA a spritu tak se s nami lenochy podelte.
Tak jsem neco malo pozjistoval, ale je to delsi, takze odpoved rozdelim do vice casti. Nejprve vypis display-listu, ktery vam dava za pravdu s tim, ze v dolni casti obrazovky je skutecne pouzity textovy rezim gr.12 (znaky 4×8 pixelu v peti barvach):
6260: 8 BLANK
6261: 5 BLANK
6262: DLI LMS 61c0 MODE 4
6265: DLI MODE 4
6266: DLI 1 BLANK
6267: 1 BLANK
6268: LMS b000 MODE E
626b: MODE E
626c: MODE E
626d: MODE E
626e: MODE E
626f: MODE E
6270: MODE E
6271: MODE E
6272: MODE E
6273: MODE E
6274: MODE E
6275: MODE E
6276: MODE E
6277: MODE E
6278: MODE E
6279: MODE E
627a: MODE E
627b: MODE E
627c: MODE E
627d: MODE E
627e: MODE E
627f: MODE E
6280: MODE E
6281: MODE E
6282: MODE E
6283: MODE E
6284: MODE E
6285: MODE E
6286: MODE E
6287: MODE E
6288: MODE E
6289: MODE E
628a: MODE E
628b: MODE E
628c: MODE E
628d: MODE E
628e: MODE E
628f: MODE E
6290: MODE E
6291: MODE E
6292: MODE E
6293: MODE E
6294: MODE E
6295: MODE E
6296: MODE E
6297: MODE E
6298: MODE E
6299: MODE E
629a: MODE E
629b: MODE E
629c: MODE E
629d: MODE E
629e: MODE E
629f: MODE E
62a0: MODE E
62a1: MODE E
62a2: MODE E
62a3: MODE E
62a4: MODE E
62a5: MODE E
62a6: MODE E
62a7: MODE E
62a8: MODE E
62a9: DLI MODE E
62aa: DLI MODE E
62ab: MODE E
62ac: MODE E
62ad: MODE E
62ae: MODE E
62af: MODE E
62b0: MODE E
62b1: MODE E
62b2: MODE E
62b3: DLI MODE E
62b4: DLI MODE E
62b5: MODE E
62b6: MODE E
62b7: MODE E
62b8: MODE E
62b9: MODE E
62ba: MODE E
62bb: MODE E
62bc: MODE E
62bd: MODE E
62be: MODE E
62bf: DLI MODE E
62c0: DLI MODE E
62c1: MODE E
62c2: MODE E
62c3: MODE E
62c4: MODE E
62c5: MODE E
62c6: MODE E
62c7: MODE E
62c8: MODE E
62c9: DLI MODE E
62ca: DLI MODE E
62cb: MODE E
62cc: LMS 1800 MODE 4
62cf: MODE 4
62d0: MODE 4
62d1: MODE 4
62d2: MODE 4
62d3: MODE 4
62d4: MODE 4
62d5: MODE 4
62d6: MODE 4
62d7: MODE 4
62d8: MODE 4
62d9: DLI MODE 4
62da: DLI LMS 0e27 MODE E
62dd: DLI LMS 0a40 MODE 4
62e0: DLI LMS 0e27 MODE E
62e3: LMS 0e27 MODE E
62e6: JVB 6260
Vysvetleni display-listu, neboli prakticky priklad jako priloha k clanku :-)
13 prazdnych radku | |
2 textove radky v rezimu ANTIC 4 (GRAPHICS 12, 5 barev, znaky 4×8 pixelu) | |
2 prazdne radky | |
97 obrazovych radku v rezimu ANTIC E (GRAPHICS 15, 4 barvy, 160 pixelu/radek, vyska pixelu=1 scanline) Zajimave – obrazova pamet zacina od adresy B000, takze je odklopena ROM | |
12 textovych radku v rezimu ANTIC 4 | |
1 obrazovy radek v rezimu ANTIC E | |
1 textovy radek v rezimu ANTIC 4 | |
2 obrazove radky v rezimu ANTIC E |
Jinymi slovy design obrazovky je nasledujici:
To je vazne zajimavy. Takhle bych to necekal. Myslel jsem ze spis pouzijou vsude mode E a podle polohy karatisty budou editovat displaylist tak aby na vhodnych radcich povolili DLI ve kterym zajisti korekci polohy nebo i barvy spritu.
Jenze tady je DLI povoleno az na poslednich 18ti radcich, coz mozna souvisi s tvorbou stinu.
Dal jsou zajimavy polohy spritu. Ono teda zalezi na tom kdy presne jste ten dump poridil. Jestli to bylo v case VBI, nebo v nejakem DLI. Zarazi me ze sprity lezi na sobe a jeste ke vsemu druhe dva maji posuv 172 bodu. Uz si nepamatuju odkud presne se ta poloha meri, mozna az od leveho overscanu, to by pak sprite mohl byt uplne vpravo. Jestli se to meri od okraje tak by uz ani nebyl videt. Pro karatisty se nejspis poloha spritu (pokud jsou vubec pouzity) nastavi az v DLI na adrese 62bf a 62c0.
Asi nejjednodussi by bylo zapsani nejake malo pouzivane barvy, treba tmave modre do vsech registru barvy spritu a bylo by hned videt co takto kresli. Jenom by se to mozna muselo pridat to jako kod za vsecha DLI, pro pripad ze barvu prubezne meni.
Registry ANTIC:
DMACTL=3e – DMA povoleno, sprity jsou vysoke 256 radku, standardni sirka bitmapy (320 pixelu)
CHACTL=02
DLISTL=60
DLISTH=62 – zacatek display listu (viz adresy v hornim vypisu)
HSCROL=00
VSCROL=00 – nastaveni scrollovani (posun obrazu, v IK se nepouziva)
PMBASE=00 – AFAIK stranka, ve ktere jsou ulozeny sprity, to je divny, stranku 0 obsadit sprity???
CHBASE=64 – stranka s ulozenou znakovou sadou
VCOUNT=9c
NMIEN= c0Registry GTIA:
HPOSP0=4c
HPOSP1=4c
HPOSP2=ac
HPOSP3=ac – horizontalni pozice hracu (4 sprity 8×256), vsimnete si ze jsou vzdy dva hraci (sprity) pres sebe
HPOSM0=54
HPOSM1=52
HPOSM2=50
HPOSM3=4e – horizontalni pozice strel (4 sprity 2×256)
SIZEP0=00
SIZEP1=00
SIZEP2=00
SIZEP3=00
SIZEM= 00 – velikosti hracu a strel (normalni velikost, x1)
GRAFP0=00
GRAFP1=00
GRAFP2=00
GRAFP3=00
GRAFM =00 – priority – sprity nad bitmapou
COLPM0=1e
COLPM1=34
COLPM2=1e
COLPM3=34 – barvy hracu i strel
COLPF0=5a
COLPF1=7a
COLPF2=0e
COLPF3=3a – barvy playgroundu (bitmapy na pozadi)
COLBK= 00 – barva okraju (cerna)
PRIOR= 01 – dulezite, neni pouzity paty hrac, tj. mame 4 hrace a 4 strely
VDELAY=00
GRACTL=03 – nemam ted u sebe vysvetleni jednotlivych bitu, ale pravdepodobne je povoleno DMA pro sprity
Karatisti byli skutecne delani pres znakovou sadu. Kamaradi z toho dokonce kdysi tu grafiku vytahli a byla ve znacich (taky jsem jim to tehdy nechtel verit :-) Ono je to totiz ale uyasne elegantni – ti karatisti jsou uplne stejni az na barvu kimona, coz se udela tak, ze znaky (ne font) jednoho karatisty maji nastaveni 7. bit.
To je sice elegantni, ale zase to hodne komplikuje situaci kdy stoji za sebou a prekryvaji se. A to se v te hre opravdu muze stat. Musi pak dynamicky vytvaret specialni znaky, ktere budou mit obe barvy kimona a navic musi mit rozmyslene pohyby postav tak aby se do techto prekryvovych znaku nikdy nedostalo vsech 5 barev najednou. Kdybych to programoval tak bych spis pouzil sprity na kimona a zbytek bych delal v grafice, abych si tyto problemy usetril.