| Szerző |
Üzenet |
Chain-Q
Divatamigás
|
# Elküldve: 2010. Jan. 18. 13:03
Mondjuk a hardveres Kickstart switchereddel beizzitod. Olyan nincs, hogy nem megy. :) Csak benazol, de nagyon. Valaszoltam a HW kerdesek topicban...
|
TCH
Tag
|
# Elküldve: 2010. Jan. 28. 17:43 - Szerkesztve: TCH
IRC-en már volt egyszer téma, de nem sikerült eléggé kivesézni.
Adott két db Amigás hanghullám (signed 8 bit), ezeket szeretném "összemixelni". Na most én két féle "kódot" produkáltam.
Az egyik szabályosan fogja, előjelhelyesen kibővíti a két beolvasott értéket 16 bitre, összeadja őket, majd ellenőrzi, hogy nagyobb-e mint 127, vagy kisebb-e mint -128. Ez valószínűleg nem túl gyors megoldás.
; a0 = source_wave_0, a1 = soruce_wave_1, a2 = destination_wave, d0 = mix_length
@mix_waves_pure:
move.w #-128, d3
move.w #127, d4
@mix_waves_pure_0:
move.b (a0)+, d1
move.b (a1)+, d2
ext.w d1
ext.w d2
add.w d1, d2
cmp.w d3, d2
bge @mix_waves_pure_1
move.w d3, d2
@mix_waves_pure_1:
cmp.w d4, d2
ble @mix_waves_pure_2
move.w d4, d2
@mix_waves_pure_2:
move.b d2, (a2)+
dbeq d0 @mix_waves_pure_0
rts
A másik elég ordenáré lett. :P A két számnak 256*256 végeredménye van (510 különbözővel mindössze ofcoz), úgyhogy fogja és a beolvasás után a két szám alapján egyszerűen kiolvassa egy táblázatból a végeredményt. Ez biztos baromi gyors, de azért nem frankó, hogy egy sima hangkeverés több mint 64 kilót foglal. :P
; a0 = source_wave_0, a1 = soruce_wave_1, a2 = destination_wave, d0 = mix_length
@mix_waves_table:
lea @signed_saturate_add_table, a3
moveq #8, d3
@mix_waves_table_0:
move.b (a0)+, d1
move.b (a1)+, d2
lsl.w d3, d1
eor.w d1, d2
move.b (a3, d2.w), (a2)+
dbeq d0 @mix_waves_table_0
rts
Kérdés: Hogy nézne ki a kettőnek valami arany középút szerű kombinációja? Egyszóval, hogy ne kelljen össze vissza bővítgetni, meg határokat ellenőrizni, de azért ne is legyen ordenáré nagy a tábla.
Valami olyasmiből ki lehetne indulni, hogy a 256*256 azért felesleges, mert összesen csak 510 féle különböző eredmény lehet, így ki lehet egyszerűsíteni azt a bazi nagy táblát?
|
Chain-Q
Divatamigás
|
# Elküldve: 2010. Jan. 28. 19:50 - Szerkesztve: charlie
SOUND MIXING: YOU'RE DOING IT WRONG.
A hotprimitiv hangmixeles elmelete ugye a kovetkezo:
(sample1 + sample2 + sample3 + sample4 + ... sampleN) / N = kimenet
Kovetkezeskeppen a te esetedben:
(sample1 + sample2) / 2, ha mindket sample -128 es 127 kozott levo ertekeket tartalmaz, a vegeredmeny is benne lesz a -128 es 127 kozotti tartomanyban. Clippelni tehat felesleges.
Ha N kisebb mint a samplek szama, mert mondjuk mestersegesen erositeni akarod a sample-ek amplitudojat a kimenetben, akkor pedig csak a samplek szama * sampletartomany (-128 - 127) / N keplet leclippelt ertekeit kell eltenni tablazatba, es a samplek osszeadasa utan az igy kapott ertekkel indexelni. Ez azt jelenti, hogy 16 bites mixing eseten, 32 csatornanal osszesen 32*65536*2 byte (4MB) meretu tablazatod lenne, a te esetedben pedig 512 elemu. (Egyszerusitve.) Az osztasnal megjeleno kvantalasi zaj elrejtesere, es az elveszett jel visszakeveresere a kimenetbe pedig vannak egyeb trukkok is.
A clipping egyebkent tenyleg lassu, de ugy szoktunk rajta segiteni, hogy a sample-ekat osszekeverjuk egy 32 bites bufferbe, majd ezt a vegso buffert osztjuk a sampleszammal es clippeljuk a legvegen. Egyebkent a csatornaszamnal jo, ha ketto hatvanyaval dolgozol mert akkor az osztasokat shiftelessel lehet helyettesiteni.
De ha eddig megvan, majd szolj. :)
|
TCH
Tag
|
# Elküldve: 2010. Jan. 28. 20:52
Eredetileg én is úgy akartam, hogy egyik + másik / 2, de Ray azt mondta, hogy az úgy nem jó, mert halk lesz.
Viszont ezek szerint, akkor ez így klappol?
; a0 = source_wave_0, a1 = soruce_wave_1, a2 = destination_wave, d0 = mix_length
@mix_waves:
moveq #0, d1
moveq #0, d2
@mix_waves_0:
move.b (a0)+, d1
move.b (a1)+, d2
add.w d1, d2
lsr.w d2
move.b d2, (a2)+
dbeq d0 @mix_waves_0
rts
|
rachy
Tag
|
# Elküldve: 2010. Jan. 28. 22:07
@TCH
Persze, hogy halkabb lesz, mert egy-egy csatornara csak feleakkora hangerotartomany jut, de ha szaturalod akkor meg torzul(hat), ha tul hangos mintakat keversz ossze. (Ld. clipping.)
A forrasod azert nem jo, mert az elojeles kiterjesztest nem lehet kisporolni. (-2 = 254, 0 = 0 -> 254+0= 254 -> 254/2 = 127, pedig helyesen: -1 = 255-nek kene lennie ugye.) A rotalasnak pedig aritmetikainak kell lennie: ASR-t kell hasznalni.
|
TCH
Tag
|
# Elküldve: 2010. Jan. 28. 23:26
Akkor tehát beszúrandó egy ext.w d1 meg egy ext.w d2 és az lsr-ből asr lesz, ugye?
|
rachy
Tag
|
# Elküldve: 2010. Jan. 29. 09:06
Igen, bar elkepzelheto, hogy lehetne valahogy optimolni rajta, most egy kicsit nehezen tudok 68k-ban gondolkodni. Oregszem, hiaba.
|
TCH
Tag
|
# Elküldve: 2010. Jan. 29. 11:59
Azér' még megy. :)
Gracias Amigók! :)
|
TCH
Tag
|
# Elküldve: 2010. Jún. 17. 15:38 - Szerkesztve: TCH
Nu, Amigók. Következő a kérdésem. Változók kezelése hogyan zajlik itten. Adott pl: x = y + z;
Ez akkor így néz ki:move.l y, d0
add.l z, d0
move.l d0, x
x dc.l 0
y dc.l 3
z dc.l 4 ?
Vagy ez így kurvára nem jó, mert nem a változó tartalmát tölti be, hanem a címét? Azaz valahogy így kéne kinéznie:movea.l y, a0
move.l (a0), d0
movea.l z, a0
add.l (a0), d0
movea.l z, a0
move.l d0, (a0)
x dc.l 0
y dc.l 3
z dc.l 4 ?
Vagy egyik sem?
|
TCH
Tag
|
# Elküldve: 2010. Dec. 11. 19:50 - Szerkesztve: TCH
Az egyik címzési móddal kapcsolatban, azt írják, hogy a formátuma: (d8, an, xn)
Az x az az indexregiszter, de most az mi lehet? Cím? Adat? Mindkettő?
Sz*rk: Never mind. Megtaláltam a választ, hogy mindkettő és a szélessége is kell, pl: (35,a3,a4.w) vagy (77,a0,d2.l)
Doksik közé postoltam az oldalt, ahol elég jól leírják.
|
TCH
Tag
|
# Elküldve: 2011. Feb. 11. 15:27
Jobb híján ide.
Lehetséges úgy nyitni egy képernyőt, hogy azok a pixelek, amelyeknek az értéke 0 azokat nem rajzolja a gép? Egyszóval lehet ilyen "kamu átlátszó" képernyőt nyitni?
És ha igen, hogyan?
|
Travis
Tag
|
# Elküldve: 2011. Feb. 11. 15:38
Szerintem nem lehet. De ha ilyet akarsz, akkor inkább csináld azt, hogy lemented a képernyő képét, mielőtt bármit is kirajzolnál. Nyitsz egy teljes képernyős ablakot, belerajzolod a lementett képet és rárajzolod amit szeretnél.
|
smokey2k
Tag
|
# Elküldve: 2011. Feb. 11. 16:59
ö dual playfield nem játszik ?
|
AliveMOon
Tag
|
# Elküldve: 2011. Feb. 11. 21:59 - Szerkesztve: alivemoon
Kell hogy legyen, mert az ICON-okat ki tudja rajzolni keret nélkül kulcsolva.
Szerintem rendszer szinten is van valami BOB-vagy akármi.
De nem külön képernyőn, hanem rá a képernyőre.
Külön képernyőbe, előbb bemásolod, a háteret és rá amit akarsz.
Egyébként a dual playfild is érdekes lehet. Valahogy a screen copperlistályába kell néhány plussz utasítás, amivel bekapcsolod a DPF-et és beálítasz plusz planekat. Ahogy cooperral néhány commoditi tud szivárványt rakni a háttérre, szerintem ezt is lehet. Esetleg, blitter másoló utasításokat be paszintani, azzal meg rá lehet másolni, akármit a képernyőre.
Vigyázni kell, szerintem, minél rendszer barátabban old meg, amire van lehetőség azt WB-vel, amire nincs azt meg ovatosan.
DPF az nem is lehet olyan bonyi.
Foglalni egy saját chip memoriát.
Biztos van lehetőség, kérj hozzáférést a screen leírójához, ott bepaszíntani a plussz cooper utasításokat, aztán tied a világ. Szerintem az AmigaOS nem tud megakadályozni semmiben.
|
TCH
Tag
|
# Elküldve: 2011. Feb. 12. 10:38 - Szerkesztve: TCH
Azért kérdezem, mert ha tud ilyen "átlátszóságot" a screen, akkor több képernyő egymás fölé helyezésével több színt tudok használni.
Pl. ha van egy 128 színű képem, akkor azt felosztom 4 db 32 színűre (azért nem 64-re, mert az EHB-ból csak 32 szín egyedi, a felső 32 már az alsó 32 fele fényerejű változata) és a 0 értékű pixelekkel lehetne "lapozni" a 4x32 színű palettában.
Pl. ha az egyik pixelnek a színértéke 11, akkor így nézne ki a 4 képpont: 11 0 0 0, ha 111, akkor így: 0 0 0 15, ha 72, akkor így: 0 0 8 0 és így tovább, tehát mindig annak a képernyőnek lenne a pixele, amelyiknek a palettájához tartozik és mivel a többi "átlátszik" azon a ponton, így nyugodtan össze lehet kombinálni a 4 képernyőt.
Igaz, így sem 128 színem lesz, csak 125, mert a három felül lévő képernyőnek a 0. palettaeleme átlátszik, csak az alsóé használható.
Pontosabban így ha N képernyőt összekombinálunk, valahogy így jön ki a színek száma, hogy (N*32)-(N-1)
|
AliveMOon
Tag
|
# Elküldve: 2011. Feb. 12. 14:41 - Szerkesztve: alivemoon
Aha a DPF-el két 16 színűt tudsz így össze kombinálni, tehát 32 színt. Amit it írsz az maga a planár képernyő elve. 256 helyett. Azt hittem valamit rá akarsz rajzolni a wb-re.
|
AliveMOon
Tag
|
# Elküldve: 2011. Feb. 12. 15:23 - Szerkesztve: alivemoon
Több színt szerintem úgy lehtne csinálni, mint a bayerszűrő a kamera CCD-jén. Bayerszűrőn egy pixel 2x2 pixelből integrálodik össze, átlóban 2 zöld a maradék 2 pixel piros és kék.
256 színü screennél 128 átmenet piros vagy kék, 128 átmenet pedig mindig zöld, soronként cooperal váltod a pirost és kéket, így feleződik a felbontás, negyedelödik a pixel szám de 7+7+7bit színt tudsz megjeleníteni, talán egy superhi(gh)res_lace kéne, akkor egész jó minőségű is lenne :)
Bár lehet, hogy ha interlacéban csak kép fázisonként kéne kék és piros palettát váltani és a vibrálást ösze integrálná a szem tenné.
8X osára rontva a másikon jpg integrálta a pixeleket mint a szem, szerintem az XTremeRace használ valami ilyet.
|
TCH
Tag
|
# Elküldve: 2011. Feb. 12. 16:21
Áhh ez a villogtatás nem hinném, hogy praktikus lenne. :)
Szóval akkor lehet "átlátszó" képernyőt csinálni, de csak 16 színűt? Mondjuk egy 64 színhez még az is elég jó, ha valódi 64 színt akarok, nem EHB-t.
|
AliveMOon
Tag
|
# Elküldve: 2011. Feb. 12. 16:27 - Szerkesztve: alivemoon
Csak anyira vibrál mint a lace, ha nem lace nem villog csak nagy felbontás kell.
|
TCH
Tag
|
# Elküldve: 2011. Feb. 12. 17:58
Oké és hogy lehet akkor átlátszó screent nyitni?
|
AliveMOon
Tag
|
# Elküldve: 2011. Feb. 13. 19:45 - Szerkesztve: alivemoon
Félre értettem, azt hittem, hogy valamit rá akarsz rajzolni a képernyöre, kulcsolva, aztán megértettem, hogy egy több szinü képernyöt szeretnél csinálni.
Ha most már jól értem, te azt kérdezed, hogyan lehet 2 screent úgy nyitni, hogy az egyiken a 0 pixelek átlátszanak.
Cooper a custom chip regiszrereit tudja írni, a blitterét is és van wait, hogy a képernyő rasztersugarához szinkronizálja ezeket a regiszter írásokat(figyeli, hogy a DAC DMA-ja hol tart a megjelenítéssel).
A wb-screen drugdown is szerintem ezt használja, hogy le tudjuk huzni a képernyöt, van egy rendszer szintű cooper lista amiben
Screen1:
mod 4plane
plane0..4
color0..15
wait xy
Screen2:
mod 4plane
plane0..4
color0..15
wait xy
Screen3:
screenmod
plane0..nPlane
color0..nColor
stb..
Neked ezt a listát kell megkeverned egy kicsit.
Screen1:
mod 8plane | DPF-bit ( | logikai vagy)
plane 0..3
color 0..15
(ha kinyirod a wait xy a két képernyő egymáson fog megjelenni)
Screen2:
// mod 4plane ( ez így már felesleges )
plane 4..7
color 16..31
Szerintem van rá mod, hogy lekérdezd a rendszertől a cooper lista memoria címét és akkor már modosíthatód.
Azért a rendszertől kell megtudni, mert ezek a regiszterek csak írhatók, ahol beálítja a cooper lista kezdetét.
|
TCH
Tag
|
# Elküldve: 2011. Feb. 13. 22:06
Oké, köszi a tippet, ki fogom próbálni, ha sikerül, megosztom az eredményt.
|
AliveMOon
Tag
|
# Elküldve: 2011. Feb. 20. 20:48 - Szerkesztve: alivemoon
Na viszont tegnap eszembe jutott, hogy a HAM képformátumoknál, a holdandmodifi mellet van lehetőség HAM6-nál 16, HAM8-nál 64 hagyományos színt használni paletáról, tehát ha a WB-t ráveszi az ember, hogy ezekkel rajzoljon hagyományos szöveget, ablakot, stb.. színes képeket viszont lehet 4096 és 200k színnel rajzolni.
Delux és Personal Paintban, ha HAM-ben rajzolsz akkor a toolbar szerintem ilyen modon kezeli.
|
TCH
Tag
|
# Elküldve: 2011. Feb. 20. 21:58
Igazad volt, a Dual Playfield mód valóban lehetővé teszi ezt, hogy a felső screen - pontosabban display - 0. color indexe átlátszódjon. Pontosan úgy van, ahogy leírtad, van egy idevágó regiszter, ami ezt kezeli.
Screen nyitáskor a ViewModes-ban be kell állítani a DUALPF flaget és ennyi.
Na most a probléma csak azzal van, hogy ha ezek a DPF képernyők max. 16 színűek lehetnek és csak kettőt lehet összekapcsolni, akkor ott vagyunk, ahol a part szakad, mert 32 színű képernyőt magától is tud az Amiga.
A leírás szerint a normál screen 1-5 bites lehet, a dpf 2-6, de ezek el vannak osztva a két képernyő között, a ham mindenképpen 6 bites.
Ahhoz, hogy valódi 64 színű képet kapjunk, ne EHB-t, ahhoz vagy 32 színű DPF-re lenne szükség, vagy arra, hogy ne csak 1 hanem 3 "átlátszó" playfieldet lehessen az első képernyő fölé rakni.
BTW, a doksik közé belinkeltem azt a pedofájlt, amiben elég jól ki van vesézve.
|
AliveMOon
Tag
|
# Elküldve: 2011. Feb. 20. 23:09 - Szerkesztve: alivemoon
Én ott leragadtam, hogy valami truecolor szerű képernyöt szeretnél létrehozni, egy trükel, hogy több képernyöt össze kapcsolsz!
Ezzel a HAMmel arra gondoltam, hogy végülis Amiga a HAM-el alapból tud.
HAM-el van 4 vagy 6 bites hagyományos lehetőséged és van truecolor is egyben.
Blitterel egy elkészített HAM et és hagyományos paletásat ösze tudsz másolni egy képernyőre akár copperal is automatikusan, tehát chipmemben készítesz egy HAMképet és egy másikban paletásat maszkkal, utánna viszafutáskor a copper listában lene egy blitter másolás ami automatikusan ösze montirozza.
Valszeg kéne egy Dupla buffer, hogy ne látszodjon, ha nem végez idöben a blitter.
|
TCH
Tag
|
# Elküldve: 2011. Feb. 21. 00:06
A HAM üzemmódot inkább elkerülném, ha lehet...
Az amit szeretnék csinálni az egy valódi 64 színű képernyő, nem EHB. De most kicsit belemásztam a dolgokba és sajna egyáltalán nem fog menni DPF-el. A DPF összesen max 16 színt kezel és ez van szétosztva 2 displayra.
6 bitplane a maximum, a páratlan bitek tartoznak a háttérhez, a párosak az előtérhez.
Vagyis mind a két display maximum 8 színű lehet. Tehát DPF-el az életben nem érünk el 64 színt.
Mondjuk ha össze tudnánk rakni 4 db DPF screent (azaz 8 displayt) akkor menne, csak ezzel az a baj, hogy a háttér elvileg nem tud átlátszó lenni. Pontosabban az egyik forrás azt állítja, hogy csak az előtér lehet átlátszó, míg a másik azt, hogy a háttér is lehet az.
Csak lehet, hogy a végén annyira lassú lesz, hogy a sima EHB-val jobban járunk. :P
Vagyis hacsak nincs valami eldugott trükk erre, hogy egy "normál" screen is átlátszódjon, akkor az OCS/ECS max az EHB üzemmódban tud 64 színt. Leszámítva persze a HAM képeket, dehát azok csak állókép megjelenítésre jók.
|
AliveMOon
Tag
|
# Elküldve: 2011. Feb. 21. 01:04 - Szerkesztve: alivemoon
Én azon már sokat gondolkodtam, hogy minden paleta színhez egy szín átmenetet rendelni fügölegesen, mostanában úgye divatos a candy képernyök és grafikák. És valami természetes szelekció szerint osztályozni a szineket és az osztályok természete szerint valami szinátmenetet rendelni,
az mondjuk:
zöld clorofil levelek
barna fa
piros-tűz
kék ég és víz
Az a lényeg, hogy ezek az osztályok ne nagyon legyenek szinkronban
Így elvileg egy 16 színű képböl is sokkal színesebb, gazdagabb képet eredményezne..
|
TCH
Tag
|
# Elküldve: 2011. Feb. 21. 21:43
Quoting: alivemoon minden paleta színhez egy szín átmenetet rendelni fügölegesen
|
AliveMOon
Tag
|
# Elküldve: 2011. Feb. 22. 06:45 - Szerkesztve: alivemoon
Ezt hivják dynamicHAM-nek.
Van egy 16színű képed és minden sor végén az öszes színt modulálod mondjuk egy színusz fügvényel, de mindegyik színt kicsit különböző fázisban és frekvenciában, lehet hogy egy 16 színű képed volt de a képernyön egy sokkal több színű látszik.
Azt a színek osztályozását meg úgy értettem, hogy egyszerűen eldöntöd, hogy a barnákkal mondjuk fa hatást akarok, pirossal meg tűz hatásút akarok és ki találsz szín átmeneteket.
Úgyan ezt lehet bonyolitani, soronként külön-külön konvertálod 16 színre a képet, így még jobb minőséget érsz el, a copper pedig proceszor idő nélkül tudja frissíteni soronként a palettát.
Aztán el tudnék egy olyat is képzelni, ha mondjuk 3D-t jelenítesz meg, hogy a felület normálok és fényforás írányból fresnelt számolsz és azt írkálod ebbe a copperlistába.
|
TCH
Tag
|
# Elküldve: 2011. Feb. 22. 10:26
Ja, így már értem.
A 3d nekem túl magas lenne, de gondolom az csak példa volt. :)
|
