Root.cz  »  Programovací jazyky  »  Programování pro osmibitová Atari: blokové výplně a přesuny dat, grafický subsystém  »  Názory  »  Názor

Odpověď na názor

Odpovídáte na názor k článku Programování pro osmibitová Atari: blokové výplně a přesuny dat, grafický subsystém. Názory mohou přidávat pouze registrovaní uživatelé. Nově přidané názory se na webu objeví až po schválení redakcí.

  • Článek je starý, nové názory již nelze přidávat.

  • 24. 3. 2026 17:58

    Pivson

    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.