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.
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.