Defor

​​​​​​​Tak oprava, ok, již alespoň trochu vím, k čemu slouží BPLCON1. Pro efekt který píšeš jsou ale použitelné asi jen bity PF1H2 a když se použije PF2H2, jen se ty dvě barvy prohodí. Tohle bylo použito v původním kódu, jen jsem nevěděl, že se to dělá tímhle, tedy jsem opět o něco více v obraze Nicméně alespoň pro typ písma co používám a styl jak s tím písmem pracuji se mi opravdu více líbí, když mám písmo pouze v jedné barvě. Myslím, že nejvíc mi vadí, že se tím dá šířka písma v jedné barvě na polovinu. To písmo pak již není hezké a použití druhé barvy v jakémkoliv odstínu/barvě tomu sice pomůže, ale vyhrává u mně celé písmo pouze v jedné barvě. Kdyby bylo písmo o šířce 3 pixely a ne 2, možná by to vypadalo lépe i s tímhle efektem, ale u šířky 2 pixely to z mého pohledu s tímhle efektem není ono.

Ale díky, opět si mne něco naučil

Tak jde udělat i 2 pixely široké písmo + stín, ale je to již moc tlustý. Mám teď kombinací která je fajn celkově 2 pixely tlusté písmo z toho 1 pixel je stín. Jde o to, že se mi to líbí na černém podkladu a když byl stín tmavší "vzadu" tak mi již s černým pozadím splival a to dávalo tomu textu vzhled že je široký 1 pixel, když jsem to ale obrátil a stín je světlejší a tedy "vzadu" tak to až tak s tím pozadím pro mně nespliva. Jde o to, že já čtu zleva i jednotlivé písmenko, tedy tu informaci vpravo až tak nevnímám a je třeba mi říci, že je tam ještě ten druhej pixel vpravo u písmene a to lépe vnímám ve světlé barvě, tu tmavou již tak nevnímám. Tedy logicky je to obráceně a vzadu je stín světlejší, ale výsledek je pro mne lepší. Tím že je tmavá vepředu již to písmo není tak výrazné, je to takový zašlý old style, ale je to pořád dobře čitelné a ve výsledku se mi to líbí více, jako když jsem měl písmo v šířce 2 pixelů pouze v jedné barvě

Takhle to například může vypadat (4x zvětšeno): Text posunutý o dva řádky dolů (tedy BPL2PT ukazuje na adresu o 2*40 bajtů nižší) a dva pixely doprava (BPLCON1, $0020) + vhodně nastavené barvy.

Jasně, supr, mně to před tím při posunu o 2 pixely rozhodilo barvy a správně mi to fungovalo pouze s posunem o 1 pixel. Teď již mi funguje i posun o 2 a více pixelů, tak nevím co jsem dělal před tím špatně, ale již to funguje a nechávám posun o 2 pixely. Udělal jsem posun dolů a nahoře mi to nechávalo v obraze bordel o výšce 2 pixelů, ale to by byl detail a to bych nějak spravil, nicméně ty stíny mi lezli, přesněji dotýkali se i textu v dalším řádku a nejvíce se mi i tak líbí pouze posun doprava, tak zatím zůstanu pouze u něj, díky moc

Ok, posun stínu textu o 2 pixely doprava a o 1 pixel dolů. Mezeru mezi řádky mám 2 pixely. Problém s bordelem v obraze v prvním řádku vyřešen. Alespoň vím, jak je důležité mít v bitplanu před tím než do něj zobrazujeme 0 a taky že i na 2 bitplany mi stačí mít rezervovaný prostor v paměti pro 1 obrazovku. S tím jsem si doposud nebyl jistý

Defor díky za vše, že si mně opět něco naučil, ale asi se vrátím k mému vzhledu zašlého stylu písma. Tam stín nelze použít, ale líbí se mi to více. Snad se to bude líbit i pár dalším lidem a né jen mně

V mém kódu pro psaní textu jsem chtěl ze 2 vodorovných čar o tloušťce 1 pixel udělat čáry o tloušťce 2 pixely. Původně jsem to dělal pomlčkou s tím že vůči ostatním písmenům jsem ji ve vykreslování časově nepribrzďoval. Řekl jsem si že to udělám pomocí Copperu. Nevím jestli je nejideálnější kreslit pomocí Copperu přímo do bitplanu. Fungovalo to, jen v emulaci jsem měl jinak posunutý text vůči středu obrazovky než na A1200. Řekl jsem si že zlepšim kontrolu a udělal jsem si na obrazovce 3 oblasti, tak aby mi obrazová oblast práce s bitplanem nezasahovala do místa na obrazovce pro Copper. Tam jsem zjistil, že první řádek zobrazovaný na obrazovce je až 27. Dost dlouho mi trvalo hledání čehokoliv, kde by o tomhle bylo psáno aby jsem si potvrdil že to tak opravdu je. Po tom co jsem udělal opravu jsem zjistil že poslední zobrazovaný řádek je až 312. Vše v LoRes. Udělal jsem opravu. Před tím se ještě trochu hrál s Copperom aby jsem to drobatko dostal do krve. Tak konečně v emulaci i na A1200 obraz se správným odsazením v horní a dolní části. Tedy LCD na A1200 mi obraz usekava ale je to ok. Mám v kódu zatím v krajních řádcích červenou čáru aby jsem přesně viděl kde mi zobrazování končí a vzal jsem to v závěru i pravítkem z LCD

Jen doplním že před kreslením 2 čar pod sebou pomocí Copperu jsem kreslil jednu původní pomocí pomlčky a druhou Cooperem. Ale Copper dělá nejmenší skoky v jedné řádce po 4 pixelech (tedy mně dělal a v HiRes to bude dle všeho po 8 pixelech) a tahle čára nebyla zarovná s čárkou vykreslenou pomocí pomlčky. Samozřejmě nebylo to ideální řešení, spíše takový start a zároveň jsem to měl jako prvotní pomůcku kde chci udělat čáru Cooperem

Ten register BPLCON1 podporuje práci jen se 2 bitplany. Na písmo jsou již použity. To mi dle všeho znemožňuje použít na písmo již efekt stínu posunutého doprava. K bitplanu mám přístup jen po 1 byte, z toho co znám a to je po 8 pixelech, co je již moc. Stín pod písmenem bych mohl udělat. V řádcích na obrazovce můžu jít po 1 pixelu s tím že bych na to použil třetí bitplan. Uvidím

"Dost dlouho mi trvalo hledání čehokoliv, kde by o tomhle bylo psáno aby jsem si potvrdil že to tak opravdu je." Haha to je přesně ono, s tím taky zápasím, ale zrovna včera se mi povedlo ochočit si sensors.library bez jedinýho příkladu

Jen pár úvah, které mne bez ladu a skladu napadají.

* Je to často pro mne velmi překvapivé názvosloví, které používáš. Asi jsem se nikdy nesetkal s tvrzením, že "Copper kreslí". Kreslení je pro mne osobně komplikovanější proces (body, čáry, polygony, atd.). Copper umí jen a pouze nastavovat hodnoty do custom registrů (a to jen do některých) podle pozice elektronového paprsku. To je jeho funkce a v té synchronizaci s el. paprskem je jeho síla (kterou nám ve své době záviděly jiné platformy). Ještě se dá třeba tvrdit, že právě elektronový paprsek "kreslí" obraz - na stínítko CRT obrazovky.

* Počítadlo řádků (které myslím inkrementuje Denise) začíná mnohem výš než je první viditelný řádek obrazu. A končí mnohem později než je poslední viditelný řádek obrazu. Tebou empiricky zjištěné hodnoty zřejmě odpovídají tomu, co je uvedeno v dokumentaci (neověřoval jsem to). Skutečně vřele doporučuji si přečíst celý "Amiga Hardware Reference Manual" http://amigadev.elowar.com/read/ADCD.../node0000.html. Tam je vše velmi dobře popsáno. Je to "bible" Amiga coderů Nevím, jestli je angličtina pro tebe velkou překážkou. Snad by si s tím google translator nějak poradil.

* BPLCON1 nijak "nepodporuje jen 2 bitplany". Stejně jako jiné registry pro nastavení generování obrazu, jsou hodnoty rozdělené na liché a sudé bitplany. Takže máme dva modula (BPL1MOD, BPL2MOD), máme dva čtyřbitové posuny v BPLCON1, a dvě tříbitové hodnoty playfied-sprite priorit v BPLCON2. Souhrnně se v dokumentaci o lichých bitplanech píše jako o playfield1, a o sudých jako playfield2.

* Nevím přesně co myslíš tím "Copper dělá nejmenší skoky...". Copper umí dělat i skoky ve svém programu, ale to asi nemáš na mysli. Copper podporuje tři "instrukce": MOVE, WAIT a SKIP. Zdaleka nejpoužívanější je ta první. Copperu trvá minimálně čtyři DMA cykly (takty chipset sběrnice), aby provedl instrukci MOVE. Což odpovídá vykresleným osmi obrazovým bodům (generování pixelu - color-clock - je 2x rychlejší než bus-clock). Copperu tedy trvá nastavení custom-registru minimálně 8 pixelů. Nejde to udělat rychleji.
Zajímavost: Je možné to udělat rychleji pomocí rychlého CPU. Ale i to má svá omezení: Protože Agnus povoluje CPU přístup na sběrnici jen každý druhý takt, může se nová hodnota do custom registru dostat jen každý druhý takt - tedy každé 4 pixely. Ale to vše jen za předpokladu, že CPU by provádělo instrukce dostatečně rychle, a navíc z FAST RAM nebo ze své cache (fetch instrukce by nesměl být z chip RAM). Prostě pod 4 pixely to nejde udělat ani seberychlejším CPU Navíc by to bylo vykoupeno tím, že by CPU při generováni obrazu nedělalo nic jiného než jen zapisovalo do custom-registrů. A to zcela popírá výhody designu Amigy (byli bychom na úrovni Atari 2600 nebo ZX81). Jen doplním, že WAIT a SKIP instrukce Copperu trvá dokonce 6 taktů sběrnice.

A ještě doplním, že v případě generování "hi-res" obrazu je třeba všechny ty počty pixelů vynásobit dvěma. Takže neplatí, že při vyšším rozlišení to budou třeba jen 4 pixely (nebo stále těch 8 pixelů). Bohužel to tak není. Taktování sběrnice se samozřejmě nemění. Mění se jen rychlost generování barevného signálu (=pixelů). Takže zatímco Copper dělá MOVE své čtyři takty sběrnice, Denisa vygeneruje 16 hi-res pixelů.

Jasně já to dělal v emulací, možná proto jsem se dostal na 4 pixely, ale to je jedno, jednoduše teď mám obě čáry pod sebou čisté pomocí Copperu, co je lepší než kombinace 1 čáry pomocí pomlčky a druhé čáry pomocí Copperu.

Dostávám se do toho postupně.

K té bibly, já mám rád když se na mně nalepují věci o programování postupně. Ostatní způsoby jsou pro mne moc informací naráz, ale díky za vše

Díky za vysvětlení s tím BPLCON1 a playfield1 a 2. Již tomu rozumím lépe

Defor A můžu tedy pomocí BPLCON1 udělat v písmu posun mezi 1. a 2. bitplanem co mám teď a k tomu přidat posun mezi 1. a 3. bitplanem?

Tak měl jsem v kódu takovou blbinu, já si něco neuvědomoval a ono to fungovalo, ale měl jsem za to že to dělám jinak a proto jsem myslel, že by mi ten 3.bitplan měl fungovat, ale nefungoval a ani memohl. Konečně se mi i další 4 barvy, celkově 8 zobrazují. Zatím jsem druhé čtyři barvy nastavil na hodnoty prvních 4 barev. Tedy se to tváří jako se 2 bitplany, ale všechny barvy mi již reagují, tak se s tím opět budu hrát příště. Ve výsledku jsem vlastně do adresy prvního a druhého bitplanu pro Copper nahrál adresu prvního bitplanu a provádím posun o 1 pixel pomocí BPLCON1 a do adresy třetího bitplanu pro Copper jsem nahrál adresu posunutou o jeden bitplan.

Horizontální posun je definován pro liché bitplany (playfield1) a sudé bitplany (playfield2). To druhé, co píšeš, tedy nejde udělat.

případ čárka

V mém programu pro psaní textu jsem font pro text, kde byly všechny znaky definované nahrával z externího souboru. Čárka tam nebyla. Šlo by jí tam dodefinovat, spíše vyměnit třeba za dvojtečku, ale to se mi celé nějak nelíbilo. V externím souboru byly všechny znaky definované vedle sebe, bylo jich tam 40, co je u písma širokého 8 pixelů celá šířka viditelné obrazovky tedy 320 pixelů. Je otázkou, jestli by šlo definovat znaky i mimo vyditelnou šířku bitplanu, myslím že ano, nebo v druhém případě další znaky do externího souboru definovat do dalšího řádku, to by se pak ale u načtení znaků z druhého řádku musel udělat i přechod na druhý řádek v programu. Vše tohle se mi nelíbilo a tak jsem přistoupil k tomu, čemu jsem se chtěl vyhnout aby jsem se nezdržoval. Definovat si znaky přímo ve vývojovém prostředí. Naštěstí to ani tak nebolelo. Nechal jsem se inspirovat cizím kódem a ten pak upravil a začlenil do kódu mého. Z cizího kódu si zatím vzal i font písma. Tenhle font se mi nelíbí a zatím si jej chci předefinovat na font z externího souboru co jsem používal doteď jen ho budu mít již přímo ve vývojovém prostředí.

Původní kód používal na násobení číslem 8 rotaci bitů pomocí instrukce ASL, na téhle instrukcí jsem se jednou dosekal i já. Tahle instrukce by měla být použita jen tam, kde má svůj účel. Já jsem jí zatím nepotřeboval. Zůstávám zatím pro rotací bitů u ROL a ROR a já použil místo ASL instrukci ROL.

Čárku jsem si zeditoval sám, jen jsem poslední 3 pixely posunul o jeden pixel doleva. Z obrázku je zřejmé že kvůli čárce budu mezeru mezi řádky posouvat ještě o 1 pixel. U fontu který použiju budou poslední 3 pixely z čárky vždy posunuté o 1 pixel níže vůči pismu jak je to vidět u použitého "U,". To by mělo být dostačující. Čárka je snad po grafické stránce v pohodě