Vlákno názorů k článku Programování pro osmibitová Atari: blokové výplně a přesuny dat, grafický subsystém od Pivson - Zdarec vespollek, jeste vyrazne rychlejsi je idelane v...

Zdarec vespollek, jeste vyrazne rychlejsi je idelane v ZP mit kousek kodu ala

...
lda addr16,y
sta addr16,y
iny
bne
inc ^^
....

jsou to 2 cykly na 1 byte, co je docela hodne :)

Pokud neni ZP tak se prodluzuje nastaveni adres a take vnejsi cyklus bude stat o 2 cykly navic.

P.

jj to je jeste lepsi reseni. Adresu tam cpes prepisem kodu ze?

Tak tak.... Prakticky je to totozne jako lda/sta lda/sta ldy #0 lda () sta () - jen misto 'lda ()' uz volas jsr $00xx. Dokonce i to inc zp+1 je defacto identicke, jen self-mod. V realu pak nekdy ZP funguje jak 'overlay' :)

Pri slozitejsich realtime efektech to ani jinak nejde (kazdej cykl je znat, tady je jedna z mala vyhod ataraka, ze se da, kdyz neni grafika, z procaku dostat vicero cyklu na radek, u nas je to vicemene fixni, kom badlajny). Jinak prakticky pocet cyklu u nas a u vas je az na chlup stejnej - chlup pro vas :)

Velice casto se nicmene musi vygenerovat lda/sta (nejdelsi co jsem generoval mel asi 12K v kuse). Z podstaty obvykle jsou adresy nemenenne, pripadne se meni v ramci X/Y registru.

P.

hmm sekvence LDA/STA, nebylo takto náhodou řešené video Bad Apple? Že aby se to ustíhalo, tak to byly přímé zápisy do VRAM a přepínaly se stránky... Musím dohledat.

Produkci ataraka moc neznam takze netusim, ale obecne je to bezne vsude, kde by pojidaci knedliku umreli hlady. Jednou jsem delal intro pro znamej diskmag a udelal jsem tam sachovnici a protoze jsem byl linej a je to kratke (konkretne $6447-$7e10), udelal jsem to makrama v asm co mam (moc to zabalit nejde :). Relanej kod teda vypada:

; roll the cheese
txt_roll            .rep font_size_y :y
                    .rep 8 :ycnt
                    .rep txt_scroll_size+1 :x

                    lda font+(y*(txt_scroll_size+1)+(txt_scroll_size-x))*8+ycnt
                    eor txt_eor_x+(txt_scroll_size-x)
                    eor txt_eor_y+y*8+ycnt
                    rol
                    sta font+(y*(txt_scroll_size+1)+(txt_scroll_size-x))*8+ycnt
                    .if ycnt & 1
                    sta font+$0400+(txt_scroll_size-x)*8+7-(ycnt+8*y)/2
                    .endif

                    .endrep
                    .endrep
                    .endrep

                    rts

to druhe dole je polovicni 'odraz'. txt_eor_x/y (btw. bufery v ZP, taktez moc a moc cyklu doma) paj ridi samotnej efekt. Zobrazeni je fontem (256 vlastnich znaku, hec :)

Efekt je vetsi textovej skrol, prez kterej jezdi po sinuvoce sachovnice, co to 'eoruje' (4 barvy). Pod tim se pak lehce vlni odraz jako 'na hladine'. A za tim je pak dalsi vetsi sachovnice, co to doplnuje (dalsi barvy). Par radku - ale vyapda to docela pekne :)

Zapisy do 2 VRAM narazi na problem toho, ze potrebujes mit kod 2x (lda() sta() je vykonove no go), coz je nekdy nerealny. Casteji se to resi syncrhonizaci s paprskem, kdy je 1VRAM a clovek bezi pred/za (podle toho jak na to chces koukat, ze...). U nas je to jeste komplikovanejsi v tom, ze poslednich 8 bajtu VRAM jsou 'adresy' sprajtu. Tim roste pocet 'sta' a cyklu. Pokud nejde sync, je lepsi rozdelit obrazovku na 2 VRAM a delat to napul, protoze vlk se nazere a cykly zustanou v koze (je to buferovane, nemusis byt akuratne sync, ale zaroven zeres 1 pamet a obetovat 2x0.5 VRAM je lepsi nez velke kB kodu). A CRAM (to neznate...) u nas je fixni a nelze nikam posunout, takze syncu se vyhnout nelze. A za 1 frame nelze presunout '2 VRAM' a jeste mit nejakej vykon na neco dalsiho, takze se to pak resi omezenim barev - treba 1x CRAM na 4 znaky, takze ma clovek lda/sta/sta/sta (to je usetrenych lda...). Nicmene pak jsou potreba taktez 2 'move' rutiny (suda/licha). Ale do 64K se toho vleze hafo... :)

No nic, uz prestanu placat blbosti.

P.