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.

Mám pocit, že se to běžně dělá tak, že máš buffer v chip ram a ten naplniš a hraješ z něj z fastky ho naplňuješ to ti může ušetřit čas nemusíš dělat čtení tak často/zápis.

Jasné, ale to práve chcem, audio/sample uložené vo fastmem kvôli veľkosti (viac ako 8mb). CPU ich rovno podáva do audio registrov cez CIA časovač aby bol tok konštantný, chipmem sa celkom obchádza.

No ale to je chyba... data jako zvuk nebo grafika pokud to jedeš přes chipset, musíš nasypat do chipram. Jinak tam máš navíc to kopírování. Tak je to namyšlené z hlediska HW.

Presne tak to robím. Data z fast priamo do AudXdat. Žiadne blbosti okolo. Len som to nazval wav. Zamozrejme je to raw 8bit.

No za mě to nedává smysl.. používat WAV. 8SVX jako zdroj dat bohatě stačí, převedení do RAW formátu a šup s tím na zvukového čipu.

Myslím že na 7mHz je už spomalenie citeľné, ale stále som to netestoval na realHW. Audio je 11kHz takže ten datový tok je slušný.

Tj. tohleto trochu zere CPU, v zavislosti na mozstvi dat, ano?