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

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.

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

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


​

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:

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

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.

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

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

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

Ze startu asi potrebuji slyset nejake kdyz tak nazory / kritiku abych nedelal na necem co neni dostatecne dobre. Zatim 1 dlazdice znazornujici zeď. Celkova hraci plocha šířka 320 px. výška 192 px (chci se pro jistotu drzet vysky do 200 px). Jde mi primarne o vzhled dlazdice, jsou tam 4 barvy a asi to taky chci drzet u "zdi" s poctem barev ale kdyby to nemelo byt dostatecne ok, mozna bych presel i na 8 barev na dlazdici. Koukal jsme po hrach a myslim ze jsem viděl i horsi dlazdice ale zajimal by mne nazor. Chci cilit na A500, 512 KB RAM, ale spise se priklanuji zamerne nevyuzivat vsech grafickych vymozenosti Amigy tedy bych se rad vesel celkove do 16 barev. Ta dlazdice je asi muj 30.pokus a ja s ni nemam problem, ale blbe se mi hodnoti ma vlastni prace.

Jen takovy postreh, jak vytahuji bitplany primo ze souboru ILBM tak potrebuji nekomprimovane ILBM aby byli bitplany v souboru nezpakovane. Jednou jsem vytahl spravně bitplany ale pak jsem nevedel jaky postup jsem pouzil, U Deluxe Paint 4 na Amize se mi takovy soubor nepovedlo ulozit, aby nebyl komprimovany, zaroven se mi u nej nepovedlo ulozit ILBM aby primo soubor obsahoval opravdu jen v mem pripade 4 barvy tedy byl vysledny soubor podstatne vetsi. Program GrafX na PC již dodržel počet barev a pocet bytu pro bitplany tedy v souboru odpovidal, ale nepovedlo se mi ulozit data nekomprimovane. Brilliance 2.0 na Amize uklada soubor s nekomprimovanymi daty a tedy po ulozeni souboru prave z nej muzu data ze souboru vykopirovat aby byla ok. Mozna jsou nejake postupy jak toho docilit i v DP4 nebo v GrafX2, ale mne se to zatim nepovedlo. Tedy zatim postup lze pro pohodlnost pouzit GrafX2, na editaci obrazku pak soubor nahrat v Brilliance a opet jen ulozit, nebo to cele delat rovnou v Brilliance na Amize / v emulatoru.

Hlavne šetrenie chipmem. A tiež počet kanálov, ja tu hudbu posielam do ľavého aj pravého a to len preto aby to nebolo také "hluché"
Keď máš repro pripojené k Amige a hrá ti hudba len z jednej strany tak je to fakt "choré" a potom ešte ostanú dva kanály voľné na efekty.
Hudbu čo som použil v poslednom deme je z X68000 a tam je označená ako osem kanálová.
Teoreticky prehrávaná hudba má osem kanálov a je hraná v jednom. Ale toto porovnanie nechám na audio maniakov.


Jedna začína na 1h14m20s / ďalšia na 1h25m25s





Niečo podobné ako keď zo ZX Spectra liezla 7kanálová hudba zo ZX7.

ObiWanKen jaký je hlavni duvod toho, ze takhle zpracovavas hudbu, je to to, ze si neni omezen poctem kanalů a možná pokud by nekdo mixoval hudebni kanaly aby jich mel vetsi pocet, je tvuj zpusob o neco efektivnejsi / uspornejsi na vykon Amigy?

Aj tak sa dá. Ale to by som sa už vrátil k MOD-om. Pri 2-kanálovom MODe ostanú ešte dva na SFX a to stačí. A myslím že šikovný skladateľ by niečo vedel dostať aj z dvoch kanálov.