já uz jsem to predelal.
[joke] normalne vas tam napisu jako spoluatory... [/joke]

... to je reakce na ten zdroják v jednom z předchozích příspěvků #298
Jestli si to dobře pamatuju, tak rušit sprite DMA jen tak bez jistoty, kde je paprsek, je riskantní. V datových registrech sprajtů můžou zůstat načtené hodnoty, a pak se kreslí na screenu pruh z těch dat. Taková Amigácka klasíka Myslím, že není třeba zapisovat do copper strobe registru ($8. Má to smysl jen pokud chcete, aby copper okamžitě skočil na zadanou adresu, ale to asi není tento případ. Spíše to dělá neplechu, když se ještě zobrazuje starý copper-list. Copper si resetuje adresu automaticky při každém vertical-blank.

A asi to není důležité, ale takový "trik" (postup?), který používám: Pro inicializaci custom registrů hodnotami, které se už později nemění - a že takových je vlastně hodně, si dělám pomocný jinak prázdný copper-list, který se provede jen na jeden frame obrazu, a který nastaví potřebné hodnoty. Na konci změní adresu ($80) už na "provozní" copper-list, který se používá po zbytek programu (nebo obecně po delší dobu). V něm se už tyto zápisy do custom registrů nevyskytují. Každé provedení copper intrukce zabírá několik taktů chip sběrnice (načtení instrukce, načtení operandů). Přístup k chip sběrnici je cenný, a tak mám ve zvyku šetřit raději každým taktem, když to jde a není to ani nějak pracné.

Kdyz jsem se hral s grafikou dlazdice 16x16 px, tak jsme prichazel na to, ze vzhledu hodne pomaha, pokud je mezi dlazdicemi jisty odstup nebo jsou dlazdice nejak od sebe oddelene. Pokud byli dlazdice vedle sebe vypadala v pohode i cerna mezera mezi nimi, ale pokud byli dlazdice nad sebou, tak jiz cerna mezera nevypadala dobre. Koukal jsem na par plosinovek tak 4 snad takove klasiky a byla mezi nimi i hra Dynablaster a vsiml si, jak genialne to resi v tehle hre. Az dodatecne, jak s tim clovek pracuje si uvedomuje ty supr myslenky v ramci grafiky, jak to mela udelane napriklad tahle hra a nechal se tou dlazdici inspirovat. Neni to upla koupie spise ta hlavni myslenka a navic odstiny a barvy jsou taky neni okopirovany ale ano styl te dlazdice je hodne inspirovan, jenze pokud to ma vypadat dobre, moc voleb v takovem prostoru neni... .

V podstate vo všetkom máš pravdu Zmenu v DMACon robím pri VB samozrejme, a použitie copperstrobe pri zmene CL je taký zvyk z 90-tiek. Ani neviem kde to vzniklo a dostalo sa k nám. Zrejme z voľne šírených zrojakov. Trik s pomocným CL je zaujímavý, skúsim do budúcna. Je pravda že ja nechávam všetky zápisy na CL aj tie ktoré nie je nutné opakovať, aj keď viem že to nie je potrebné. Zase taký blbý zlozvyk.

Ten problém s tím Cooper listem, byl docela hodně profláknutý v momentě když přišla Amiga 1200, a s tím i instrukční cache.
Protože hodně her, dělalo to, že měnilo svůj vlastní kód a tím následne cooper listy. Myslím, že docela hezký příklad byl ve hře Brat.
V momentě kdy se to stalo, tak hra běžela, ale přestala měnit cooper listy, protože kód hry byl v instrukční cache a neměnil ty cooper listy a grafika šla do trouby .
Bylo to velice specifické.

Kdyz vypisu text do 2 bitplanu, po kliknuti mysi jdu na pomyslnou herni obrazovku, pred timhle vykreslinim obrazovky pouzivam kod, ktery byl pouziti i pri psani textu a tu logiku psani textu jsem si upravil jak jsem potreboval. Jde o to ze obrazovka se mi stabilne vykresli az po 4 opakovani toho kodu. kdyby jsem ho opaoval 3 krat, nekdy se nevykresli a pri 2 se vykresli obrazovka jen nekdy, Pri 1 opakovani se snad navykresli obrazovka nikdy nebo jen ojedinele. Je to normalni stav, nebo to jde delat i nejak standardneji? Dnes jsem udelal par drobosti a taky si udelal smazani obrazovky, ktere jsem dal pred ty 4 opakovani zdejsiho kodu, rikal si jestli to tomu nepomuze, ale stav zustal stejny, je ho treba porad opakovat alespon 4 krat.

Kód ktery opakuji pred vykreslenim obrazovky 4 krat je zde:

​Rozumiem tomu správne že keď chceš vypísať text na obrazovku tak ti to ide až na 4 krát ? Ak áno tak to asi niečo robíš zle ty.

Ak ide len o kód ktorý si sem dal tak mu asi trochu nerozumiem. Čakáš na H-Pos ? Nechcel si skôr čakať na riadok $FF (V-Pos) alebo VBL ?
Ja keď si chcem overiť riadok presne tak hneď za wait slučku dám MOVE.W #$0FFF,$DFF180. A od daného riadku sa zmení farba pozadia na bielu, poprípade inú farbu.



Ja mám na to makrá WAITVBL a WAITLINE. Pozor, pri použití WAITLINE musí byť parameter riadok posunutý o 8bitov doľava.


​

Ten kód co jsem posílal byl použit pro postupne zesvětlení a ztmavnuti pisma pomocí rotací barev, pak zobrazuji obrazovku, něco jako jsem zde postoval s těmi dlaždicemi. Když 4 krát použiji ten kód po pisme a před obrazem z dlaždic obraz se mi i zobrazí. Budu se muset na to ještě podívat

Několik poznámek.
Pro spolehlivou synchronizaci s pozicí vykreslovacího paprsku je lepší používat copper-list. Proto byl vytvořený a proto nám Copper v té době záviděli
Nicméně VPOS a HPOS lze číst i z CPU a děláš to v podstatě správně. Nejsem si jen jistý, jestli se doporučuje číst byte z custom registrů. Nebývá to obvyklé. Přinejmenším je to matoucí. Ve tvém příkladě čteš vertikální pozici el. paprsku, která je v $06 (VHPOSR registr). Jenomže ze smyčky vystoupíš jen pokud je VPOS čítač na hodně 255. Pokud se ale test bude provádět o něco později a přesná hodnota 255 se "prošvihne", tak vlastně čekáš na další výskyt hodnoty 255 a k němu dojde až při dalším překreslování obrazovky. Prostě je to riskantní, pokud neznáš přesné časování tvého programu vzhledem k procesu generování obrazu.
Mimochodem hodnotou čítače 255 jeden generovaný snímek nekončí. Paprsek pokračuje na další řádek, čítač jen přeteče a začíná zase od nuly.
Dá se to upravit třeba takto (a tím se test stane spolehlivějším, ale na úkor zbytečného čekání): Čekal bych na nějakou nižší hodnotu čítače ( třeba Skip: cmp.b #$f0, $dff006, blt.b Skip ) a pak na nějakou další hodnotu ( třeba Skip2: cmp.b #$04, $dff006, blt.b Skip2 ). Tím se čeká na řádek 259.
Celé to čekání (a spolehlivost testu) velmi záleží na celém tvém programu. Prostě nesmíš tu pozici prošvihnout, jinak čekáš celý další frame.Proto je lepší k tomu používat Copper a copper-list.
Takový dovětek: Popravdě jsem se nikdy nesetkal se situací, kdy bych na Amize potřeboval číst číslo řádku přes CPU. Když jsem chtěl, aby se nějaký kód vykonal, až když je nějaký řádek vygenerovaný, dával jsem si do copper-listu vyvolání přerušení. Vlastně jsem to přerušení ani nevyvolával, jen jsem využíval toho, že copper umí zapsat do INTREQ registru a dané přerušení jsem zakázal. V nějaké smyčce v kódu jsem si pak jen tenstoval, jestli byl patřičný bit nastavený (INTREQR). Pokud ano, věděl jsem, že paprsek už prošel stanovenou pozicí (vertikální i horizontální) a bit jsem smazal. Copper ten bit zase v dalším frejmu nastavil, a tak pořád dokolečka. Myslím, že jsem k tomu použival SOFT interrupt bit (bylo to tak běžné). Viz. http://amigadev.elowar.com/read/ADCD.../node0036.html
Ale opakuju: Bylo to zřídka, kdy jsem na CPU potřeboval vědět, že paprsek už někde byl. Tyhle synchronizace se obvykle dělají na úrovni copper-listu. Prostě program má (nebo generuje) copper list takový, jaký potřebuje, a v něm je předepsáno, kdy a kde se mění hodnoty registrů na obrazovce.

A ozaj, tam sa porovnáva byte z adresy DFF006. To mi ušlo.

Hele nejsem si jistý jestli tenhle postup bude kompatibilní v rámci různých chipsetů a navíc si myslím, že ti tam vznikne problém ruzně rychlého provádění smičky na různých CPU protože podle mě například na 020 to pojede třeba OK. Ale na 060 se ti celá ta sranda smička vejde do cachce a navíc se bude řešit skrz predikci při zpracování a to může dělat zle. Obecně jak psal Defor je lepší věci v čipsetu ohlídat čipsetem a jen si předávat info, nestane se ti, že by někde padla kosa na kámen. Vnímej to odděleně, dneska se taky do grafické karty nezapisuje tak, že by si CPU hráblo do její paměti, ale přehazjí si to skrz vymezený buffer v RAM.

Po delsi dobe jsme se dostal k asm (mam dovolenou) a i kdyz asi zatim nepouzivam postup ktery naznacoval Defor, cooper list inicializuji jen na zacatku, pak si pred kazdym novym zobrazenim obrazovky nactu adresu bitplanu. Ale jiz alespon vim, proc se mi to chovalo jak se mi to chovalo. Zatim mam s kodem ktery jsem zde jiz psal a uvedu opet:
nejlepsi vysledky a v tom co jsem prozatim potreboval i stabilni. Postup je takovy ze po vykresleni prvni obrazovky pouziju vyse zmineni wait kod pak vymazu obrazovku, pouziju opet wait kod a zacnu zobrazovat dlazdice. Pred vykreslenim dlazdic musim pouzit vyse uvedeny wait kod 2 krat po sobe. Duvod je ten ze ten druhy wait kod musim pouzit kvuli prechodu pro vykreslovani dlazdic v daslim radku, tedy po kompletnim vykreslenim vsech dlazdic v prvnim radku ktere maji 16x16 pixelu. Dle vseho se to tam nestiha a ja mam ted 2 varianty, bud ten wait kod dam pred vykreslenim vsech dlazdic 2 krat po sobe a dlazdice se mi vykresli naraz pro celou obrazovku, nebo dam 1 wait kod pred vykreslenim vsech dlazdic a 1 wait kod pred prechodem vykreslovani dlazdic na novem radku, to se mi pak ale dlazdice vykresli takovym rolovanim dole, portoze ten wait je tam pri prechode na kazdy radek. Ale taky se to vykresluje stabilne. Alespon tedy jiz vim, proc musim kdyz tak mit 2 krat ten wait pred vykreslovanim vsech dlazdic pokud je chci vykresli naraz a ne postupne, Tenhle stav je snad jiz dle mne normalnejsi jako ten co jsem psal pred tim, ze musim pouzit ten wait kod 4 krat po sobe... .

Hrám sa s obrazom vo formáte ILBM aby som vynechal potrebu konverzie do RAW formátu keď budem potrebovať obrázky nahrať loaderom a nie importovať cez incbin/inciff. Najprv som každý obrázok automaticky decrunchoval cez RLE decompresor, ale všetky obrázky z DPaintu IV boli "rozdrbkané" tak som sa pozrel na:
https://wiki.amigaos.net/wiki/ILBM_IFF_Interleaved_Bitmap#Appendix_F._Additional _Information
a podľa info v "hlavičke" obrázky v ILBM nemusia byť komprimované. Tak som pre kontrolu importoval jeden obrázok vo formáte ILBM (incbin) a aj vo formáte RAW (inciff). Porovnal ich a boli zhodné na 100%. Pri väčších obrázkoch je už použitá kompresia. Keď som obrázok prehnal RLE decruncherom tak znovu bola zhoda.
Pre zaujímavosť obrázok ILBM je uložený vo formáte pre blitter (RawBlit). A tiež farby je treba konvertovať, nie sú vo formáte xRGB ale v RRGGBB.

Ale já v DP4 neimportuji obrázek, já ho tam vytvořím a když ho uložím v ILBM tak není nezpakovany a nepovedlo se mi dosáhnout to tam uložit jinak a u Brilliance 2.0 mi vytvoření obrázek v něm uloží bez komprese co potřebuji. To se bavím o obrázku 32x32 px, tedy nic velkého.

EDIT: potřebuji aby při 2 bitplanech byl první řádek prvniho bitplanu, první řádek druhého bitplanu a pak se jde stejně na další řádky. A když DP4 ukládá nekomprimovaně, nepovedlo se mi to v něm uložit takhle a Brilliance to umí.

To či je obrázok komprimovaný je uložené v ILBM hlavičke. Keď si pozrieš ten link na wiki.amigaos tak je tam "časť" označená ako PlMkCoPd (Planes/Mask/Compression/Pad).
A ak je "Compression=1" tak je obrázok komprimovaný. Ja čo som pozeral moje obrazky z DP4 tak tie menšie sú nekomprimované.
Ten formát čo opisuješ je blitter ak som to pochopil. Ale to je jedno,keď vieš ako ho dostať na obrazovku