OldComp.cz

Komunitní diskuzní fórum pro fanoušky historických počítačů


Právě je 08.09.2024, 02:10

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]




Odeslat nové téma Odpovědět na téma  [ Příspěvků: 40 ]  Přejít na stránku Předchozí  1, 2, 3
Autor Zpráva
PříspěvekNapsal: 09.08.2024, 02:51 
Offline
Pan Štábní

Registrován: 23.06.2013, 23:49
Příspěvky: 1293
Has thanked: 102 times
Been thanked: 195 times
Busy píše:
Busy píše:
- Pre vsetky atributy, ktore maju same nulove pixely, vynuluje INK
- Pre vsetky atributy, ktore maju same jednotkove pixely, tieto pixely vynuluje, do PAPERu zapise INK a INK vynuluje
Vlastne ked sa tak nad tym zamyslam, pre teba by bolo vhodnejsie, ak by sa INK nenuloval, ale nastavil taky isty ako PAPER. Tym padom by si mohol vo vecsej miere optimalizovat svoj kod, ktory by sa vobec nemusel starat o pixely v atributoch s rovnakym PAPERom a INKom a dosiahol by si este rychlejsie vykreslovanie.

Tu je upravena verzia ktora takto nastavuje rovnaky PAPER a INK. Pridal som do zdrojaku aj nejake komentare, aby bolo jasne co sa kde deje.


Ten odkaz mi opet nefunguje. Dokonce to vypada ze to neni omyl.
Tak me to funguje teprve kdyz to rucne zadam do noveho tabu, pak uz to zarve ze je to nebezpecne a zda to chci ulozit. Lol.

PS: Neni to sermirka, drzi pusky.
PPS: Je tam zdrojak, pekne!

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH


Nahoru
 Profil  
 
PříspěvekNapsal: 09.08.2024, 16:26 
Offline
Óm Nejvyšší

Registrován: 22.05.2013, 21:14
Příspěvky: 3797
Bydliště: Bratislava
Has thanked: 375 times
Been thanked: 811 times
_dworkin píše:
To jsem vubec neresil, protoze jsem ji chtel nechat "cistou" a nezneuzit zasobnik.
Ale... kdyz se resim skutecne situace, tak zjistuji, ze se zase tak moc nemusim o to SP strachovat...
Tak samozrejme zalezi na tom co chces dosiahnut. Ci nejaky pekny uhladny kod reprezentujuci vybranu metodu, alebo kod ktory je efektivny, rychly a optimalny pre dany obrazok.

Predpokladam, ze chces to druhe. A to dosiahnes hlavne kombinaciou metod.

O SP sa strachovat rozhodne netreba, ak chces aby bol tvoj generovany kod normalne volatelny CALL-om, tak staci na zaciatku SP odlozit a na konci ho zase obnovit:
Kód:
zaciatok:
  ld (koniec + 1),sp
  ....
koniec:
  ld sp,hocico
A popripade este na zaciatku spravit DI aby ti prerusenie neprepisalo casti videoramky kam prave ukazuje SP.
_dworkin píše:
Moje prvni reakce byla, ze tohle je fakt hodne specialni pripad.
Ono v podstate vsetko su specialne pripady ;)
_dworkin píše:
Vytvori to dalsi bolest hlavy, ...
Ano, tych moznosti je vela. Pokial chce clovek urobit vsetko naraz, tak to je niekedy naozaj na rozskocenie hlavy. Preto je lepsie veci vyvijat postupne, najprv take vlastnosti, potom tam pridame dalsie vlastnosti (moznosti optimalizacie)...
_dworkin píše:
Ale bez toho sahani na vstupni soubor se uz neobejdu pokud budu resit pripad s neviditelnymi daty.
Ako to myslis ? Ved vstupny subor staci len nacitat do programu, a ten si uz interne v pameti vsetko co treba porobi, vratane vsetkych "predoptimalzacii" typu ako ten moj ZXreducer. Na vstupny subor (v zmysle zapisu) vobec nesahas.
_dworkin píše:
Muzu sice udelat prepinac ktery aktivuje nejake pravidla co si uvedl, jak na vstupni soubor tak na vystupni soubor a tim dosahnout spravneho zobrazeni, ale pokud budu chtit aby fakt ignoroval neviditelne data co to jde a setrit cas, tak musim krome vystupu do asm mit i vystupni "scr" obrazek, kde budou ty neviditelne data co me zbudou.
Ten vobec nepotrebujes, ved budes do pameti ukladat rovno data/kod/zdrojak ziskany a vytvoreny zo screenu upraveneho tymi pravidlami (v pripade ze budes ukladat iba rozdiely, tak aj vratane prveho "frejmu"). Aj tak to bude vyzerat rovnako.
_dworkin píše:
A nebo to resit jeste jinak a misto kazdeho framu zvlast mit moznost to resit hromadne a dovolit jednu masku na zacatku
Naco masku ?!?! Nez data pred zapisom maskovat s povodnym obsahom videoram, je ovela rychlejsie ich tam jednoducho natvrdo zapisat, aj ked to nejake kusy kresby (v casti zapisovanych bajtov) vobec nezmeni. Nerobis predsa zobrazenie sprajtov na vseobecnom neznamom pozadi, ale animaciu. Alebo nie ?
_dworkin píše:
Mimochodem ten tvuj prvni odkaz nefungoval
Mne ten odkaz normalne fungoval.
Aha, uz viem kde by to u teba mohlo robit problem - v odkaze chyba zaciatok http:// ale ten zaciatok si tam normalne browsery doplnia same. Co pouzivas za browser ze ti to tam nedoplnil ? Vo FireFixe to normalne funguje.
_dworkin píše:
Tak me to funguje teprve kdyz to rucne zadam do noveho tabu, pak uz to zarve ze je to nebezpecne a zda to chci ulozit. Lol.
Pretoze je tam EXE subor a ten moze byt potencialnym nosicom virusov. To je bezna reakcia.
_dworkin píše:
PPS: Je tam zdrojak, pekne!
Tak samozrejme, hlavne o ten zdrojak slo, aby si si z neho mohol "vyzobat" co sa ti hodi. Inak kompiloval som ho v MinGW takze by mal byt plne kompatiblny s gcc.

Este zopar poznamok k suborom:
gallery.tap ... pre samostatne obrazky treba nizsiu rychlost, takto je to chaos
Vsetky run a sermirka ... ale toto nie su cele screeny, na takto male obrazky vobec nepotrebujes vymyslat rozne extra super sofistikovane sposoby ako naplacat data do obrazovky.

Kedysi som si spravil taky jednoduchy system na tvorbu animacii. Nastrkam do neho screeny a system sam najde vsetky rozdiely a vygeneruje datovy blok, ktory potom interpretujem jednoduchou animacnou rutinkou. Robil som nim napriklad dve animacie v deme Tailwind
0m 45s - prelet telesa poza strom 0:45
1m 16s - prebeh troch telies po nocnej ulici

a obe animacie pre takto velke animovane oblasti zabrali cca horny border casu.
Takze este mam veeeelku rezervu a stihalo by to animovat ovela vecsie oblasti pod 50 FPS.


Nahoru
 Profil  
 
PříspěvekNapsal: 09.08.2024, 19:44 
Offline
Pan Štábní

Registrován: 23.06.2013, 23:49
Příspěvky: 1293
Has thanked: 102 times
Been thanked: 195 times
Busy píše:
_dworkin píše:
To jsem vubec neresil, protoze jsem ji chtel nechat "cistou" a nezneuzit zasobnik.
Ale... kdyz se resim skutecne situace, tak zjistuji, ze se zase tak moc nemusim o to SP strachovat...
Tak samozrejme zalezi na tom co chces dosiahnut. Ci nejaky pekny uhladny kod reprezentujuci vybranu metodu, alebo kod ktory je efektivny, rychly a optimalny pre dany obrazok.

Predpokladam, ze chces to druhe. A to dosiahnes hlavne kombinaciou metod.

Ne opravdu nechci v prvni metode, aby ten kod pouzival SP dokud to vyslovne neuvedes s tim ze to tak chces a pocitas s tim.
To ze to nepouziva SP je pro me bonus. S SP ztratis cast univerzalnosti.
Je to jako mit jednorucni zbran a druhou ruku mit volnou. Treba pro stit. A ne mit jednorucni zbran a mit druhou ruku trvale zablokovanou, protoze tam mas dyku, a nekdy ji mozna pouzijes. Muzes rovnou pouzivat obourucni zbran a nebo chtit pouzivat ten stit. Nebo tu kombinaci s dykou, ale az kdyz to fakt uvedes.
Busy píše:
O SP sa strachovat rozhodne netreba, ak chces aby bol tvoj generovany kod normalne volatelny CALL-om, tak staci na zaciatku SP odlozit a na konci ho zase obnovit:
Kód:
zaciatok:
  ld (koniec + 1),sp
  ....
koniec:
  ld sp,hocico
A popripade este na zaciatku spravit DI aby ti prerusenie neprepisalo casti videoramky kam prave ukazuje SP.

Ano tak to mam. O tomhle jsem psal v te casti, ze mam problem s tim kdyz rozdelim obrazek na tretiny, abych utekl paprsku tak budu mit ulozeny SP zbytecne 3x misto jednou, protoze kazdy kod se generuje nezavisle.
Chce to dalsi prepinac.
Busy píše:
_dworkin píše:
Moje prvni reakce byla, ze tohle je fakt hodne specialni pripad.
Ono v podstate vsetko su specialne pripady ;)
_dworkin píše:
Vytvori to dalsi bolest hlavy, ...
Ano, tych moznosti je vela. Pokial chce clovek urobit vsetko naraz, tak to je niekedy naozaj na rozskocenie hlavy. Preto je lepsie veci vyvijat postupne, najprv take vlastnosti, potom tam pridame dalsie vlastnosti (moznosti optimalizacie)...

Popravde po jednom dnu premysleni stale nevim jak mam spravne uchopit pripad kdy mam diky masce obrazek rozsekany na radu radku o ruznych delkach, vcetne s lichym poctem bajtu.
Idealni by bylo mit neco co me postupne bude ty bajty spojovat do wordu jak je to nejvhodnejsi... ale nevim jak na to a vysledek by byl stejne vetsinou ten, ze to bude za sebou, ale jednou ten radek zacne lichym bajtem a pokracuje wordy a nebo naopak konci bajtem.
Ale pousnout wordy na lichy adresy taky neni zadna vyhra, protoze to muze zmenit vzor 0x3344 na 0x4433. I kdyz... ze zmeny
ld H,D
ld L, E
na
ld H, E
ld L, D

mit asi boleni hlavy nemusim, alepokud bylo predtim v HL uz 0x3344 a ted to musim prohazovat...

A je to jeden bit rozhodovani na pixelradek. To je 256 kombinaci na znak, 64kb na 2 znaky a roste to fakt rychle kdyz mam smulu a vse ma lichy pocet bajtu.
Vyhodnotit to samostatne moc nejde, protoze to muze ovlivnit jakykoliv jiny radek a dopredu nevis jaky.
Ale ta dira je jeste hlubsi...
Dokazi si predstavit pripad kdy umyslne souvisly stream mam prerusovany jednim bajtem.
Protoze nahodne nekde zrovna tu adresu ziskam do HL, kde se pouzije pro LD [...], HL.
Ale pak by sla zaroven pouzit i pro LD [HL], xx nebo jeste lepe LD [HL], reg8 kdyz budu mit jeste vetsi stesti...
Takze 2 osamele bajty to pak ulozi za 2 bajty kodu a 14 taktu. Nebo az 4 bajty a 20 taktu.
Misto smolnych 6 bajtu a 26 taktu, kdyz mi to vubec nesedne do

LD HL, xxx
LD [...], HL

...a ted na to vymysli aspon nejakou zakladni heurestiku, ze to ma vubec zkusit...
Nastesti ty HL hodnoty se negeneruji uplne nahodne, ale pri skakani na liche a sude adresy se to lisit bude.
Mozna... byt optimisticky a zkouset vsechny dvojice bajtu jako potencialni adresy a ty porovnat zda lezi v rozsahu ktery zapisuji?

Jedine co me napada s nejmensi bolesti hlavy je generovat nahodne reseni a ty porovnat.
Ale protoze je tady jeste vetsi pocet moznych kombinaci tak to omezit.
Pro jednu nahodnou volbu "bud a nebo" otocit bit a v nove variante provest nekolik uplne nahodnych generovani a najit nejlepsi a to porovnat s puvodnim resenim a vybrat lepsi.
Vratit se k puvodni hodnote s vybranym novym nastavenim bitu a od toho algoritmus postupne opakovat.
Takova castecna iterace nebo by se to dalo nazvat zihanim?
Takze s trochou stesti to najde aspon lokalni minimum...?
Busy píše:
_dworkin píše:
Ale bez toho sahani na vstupni soubor se uz neobejdu pokud budu resit pripad s neviditelnymi daty.
Ako to myslis ? Ved vstupny subor staci len nacitat do programu, a ten si uz interne v pameti vsetko co treba porobi, vratane vsetkych "predoptimalzacii" typu ako ten moj ZXreducer. Na vstupny subor (v zmysle zapisu) vobec nesahas.

Myslim to pro reseni se skrytyma artefaktama. Neviditelnym bincem v bitove casti pokud INK=PAPER a nebo naopak binec v INK nebo PAPER kdyz jsou vsechny bity stejne.
Kvuli rychlosti, nebo necemu jinemu.
Takze kdyz programu predhodim serii obrazku s tim jak vypada puvodni obrazek a jak chci aby vypadal novy, tak mu nerikam pravdu s tim puvodnim obrazkem, protoze pamet se uz muze lisit.
Proto bych musel generovat krome vystupu kodu i vystupni SCR, ktere by na pohled odpovidalo co chci, ale v pameti by byl ulozeny presna kopie chaosu v pameti co to vygenerovalo.
Pak by to mohlo byt pouzito jako vstup.
To me ale generuje proste dalsi zbytecne soubory.
Proto jedine dalsi reseni pro artefaktovou metodu je to generovat v jednom volani programu a ne nezavisle, kazdy frame zvlast.
Ale to si zase vyzdauje prepravovat ten vstup na vice souboru jak jsem psal.

Ty pises neco o zavedeni pravidel, ale to uz neni "artefaktova" metoda. To nemas bordel v datech, ale naopak menis vstupni data presne do jednoznacnych nastaveni. Kdy z toho co vidis na obrazovce generujes pokazde identicky "SCR".
Busy píše:
_dworkin píše:
Muzu sice udelat prepinac ktery aktivuje nejake pravidla co si uvedl, jak na vstupni soubor tak na vystupni soubor a tim dosahnout spravneho zobrazeni, ale pokud budu chtit aby fakt ignoroval neviditelne data co to jde a setrit cas, tak musim krome vystupu do asm mit i vystupni "scr" obrazek, kde budou ty neviditelne data co me zbudou.
Ten vobec nepotrebujes, ved budes do pameti ukladat rovno data/kod/zdrojak ziskany a vytvoreny zo screenu upraveneho tymi pravidlami (v pripade ze budes ukladat iba rozdiely, tak aj vratane prveho "frejmu"). Aj tak to bude vyzerat rovnako.

Ne ten prepinac potrebuji.
Protoze jedna metoda je, ze mam obraz podle toho co mu zadam za "SCR" a vystup mam zase podle toho co mu zadam v druhem souboru "SCR".
To delam ted.
Je to taky jednoznacny.

Prepinac by to zmenil na to co tvrdis ty, ze oba vstupy by byly predem upraveny. Takze i obraz pameti by uz neodpovidal vystupnimu "SCR", ale upravenym pravidlum.
Na prvni pohled na obrazovku totozne, ale data jsou jina.
Tzn. je to dalsi metoda a prepinac umoznuje volbu.

Kterou by si pouzil v pripade ze by se ti proste ty vstupni soubory necim nelibily.
Busy píše:

_dworkin píše:
A nebo to resit jeste jinak a misto kazdeho framu zvlast mit moznost to resit hromadne a dovolit jednu masku na zacatku
Naco masku ?!?! Nez data pred zapisom maskovat s povodnym obsahom videoram, je ovela rychlejsie ich tam jednoducho natvrdo zapisat, aj ked to nejake kusy kresby (v casti zapisovanych bajtov) vobec nezmeni. Nerobis predsa zobrazenie sprajtov na vseobecnom neznamom pozadi, ale animaciu. Alebo nie ?

Maskou se mysli soubor ukazujici jak vypada obraz/pamet predtim(ted).
Neni to teda doslova "maska", ale neco co pro vymaskovani bajtu ktere se (ne)meni pouzijes.
Urcite to neni rychlejsi prepisovat stejna data... Co nemusis prepsat to usetri jak pamet tak takty.
Pokud chces zapsat vsechno znovu bez ohledu co tam bylo predtim tak proste nepouzijes tu "masku".
Proc je hromadne reseni vhodne reseni jsem psal u tech artefaktu, kde je to zpusob jak negenerovat dalsi soubory.
Busy píše:
_dworkin píše:
Mimochodem ten tvuj prvni odkaz nefungoval
Mne ten odkaz normalne fungoval.
Aha, uz viem kde by to u teba mohlo robit problem - v odkaze chyba zaciatok http:// ale ten zaciatok si tam normalne browsery doplnia same. Co pouzivas za browser ze ti to tam nedoplnil ? Vo FireFixe to normalne funguje.
Chromium.
A kdyz najedu na link tak me to ukazuje "tmp.128.sk/zxreducer1.rar" a u druheho odkazu "https://busy.speccy.cz/tmp/gigascreener1.zip", proto jsem se domnival ze si zapomnel dopsat zbytek adresy a zkousel nejake kombinace, protoze jsem prehledl to 128.sk a myslel si ze chces psat "https://busy.speccy.cz/tmp/zxreducer1.rar"
Ze se jedna o jine webovky jsem si vsimul az u druhe verze, ale po kliknuti na soubor se nic nevypise a je to hned blokovany.
Busy píše:
_dworkin píše:
Tak me to funguje teprve kdyz to rucne zadam do noveho tabu, pak uz to zarve ze je to nebezpecne a zda to chci ulozit. Lol.
Pretoze je tam EXE subor a ten moze byt potencialnym nosicom virusov. To je bezna reakcia.

Vlastne me to delalo i u midi souboru, ze to nestahne dokud si neotevres stahovani a tam nezjistis ze to musis potvrdit.
Vadi mu ze tam neni to "s" a po ceste se ten soubor muze zmenit.
Busy píše:
_dworkin píše:
PPS: Je tam zdrojak, pekne!
Tak samozrejme, hlavne o ten zdrojak slo, aby si si z neho mohol "vyzobat" co sa ti hodi. Inak kompiloval som ho v MinGW takze by mal byt plne kompatiblny s gcc.

Este zopar poznamok k suborom:
gallery.tap ... pre samostatne obrazky treba nizsiu rychlost, takto je to chaos

Ano vim ze je to moc rychle, to je ucel zjistit zda to dokaze pred paprskem.
Proto jsem doplnil do kodu ten stisk klavesy, takze to muzes prirovnat vyhernimu automatu, kde se snazis trefit jackpot.
Je to pro test nad realnymi daty a pro potreby co takovy zpusob pouziti pozaduje.
Busy píše:

Vsetky run a sermirka ... ale toto nie su cele screeny, na takto male obrazky vobec nepotrebujes vymyslat rozne extra super sofistikovane sposoby ako naplacat data do obrazovky.

Kedysi som si spravil taky jednoduchy system na tvorbu animacii. Nastrkam do neho screeny a system sam najde vsetky rozdiely a vygeneruje datovy blok, ktory potom interpretujem jednoduchou animacnou rutinkou. Robil som nim napriklad dve animacie v deme Tailwind
0m 45s - prelet telesa poza strom 0:45
1m 16s - prebeh troch telies po nocnej ulici

a obe animacie pre takto velke animovane oblasti zabrali cca horny border casu.
Takze este mam veeeelku rezervu a stihalo by to animovat ovela vecsie oblasti pod 50 FPS.


Existuji urcite lepsi reseni co sice nejsou tak rychle, ale zato kratsi.
Ber to jako ukazku na co to jde pouzit s tim, ze nemusis resit kde co budes kopirovat, tohle si to najde s maskou automaticky tu cast kterou ma zmenit a nejrychleji co to jde. Za cenu ze muze existovat kratsi specializovane reseni s trochou vic prace.
Nenasel jsem na netu zadna data prichystane pro muj program, nevim na co lidstvo doted cekalo... .)
Aby mohl rovnou ukazat animovany multikolor co jinou metodou nejde.
Coz je navic dost tezke, protoze na skoro kazdy obrazek mohu udelat spcializovane reseni a tvrdit ze je lepsi, protoze je dost rychle aby uteklo paprsku, a navic kratsi.
Ty metody jsou stale obecne, nemusi prenaset obraz, ale je dost tezke vymyslet neco jineho, krome toho jak si proste usetrit nekde praci a zvolit tohle snazsi reseni nez neco lepsiho.

PS: Uplne jsem jeste ignoroval instrukci "ex DE, HL", aspon pro posledni pouziti, se musi pouzit na konci souvisleho bloku znovu. Pripadne u jednorazovky LD [...], DE. Ale to zase nezmeni HL na nejake nasledne "inc L". A jeste neni jiste ze se ty bajty pouziji v tomhle poradi. Prilis mnoho podminek.
Pritom clovek se koukne na ten kod a hned vidi, ze zrovna tahle optimalizace se hodi...

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH


Nahoru
 Profil  
 
PříspěvekNapsal: 12.08.2024, 11:11 
Offline
Óm Nejvyšší

Registrován: 22.05.2013, 21:14
Příspěvky: 3797
Bydliště: Bratislava
Has thanked: 375 times
Been thanked: 811 times
_dworkin píše:
Je to jako mit jednorucni zbran a druhou ruku mit volnou. Treba pro stit. A ne mit jednorucni zbran a mit druhou ruku trvale zablokovanou, protoze tam mas dyku, a nekdy ji mozna pouzijes. Muzes rovnou pouzivat obourucni zbran a nebo chtit pouzivat ten stit. Nebo tu kombinaci s dykou, ale az kdyz to fakt uvedes.
Ja to vidim tak, ze systemu povies ze mas dve ruky a nechas system nech ti automaticky nakonfiguruje zbrane (vratane dyky a stitu) tak aby si mal maximalne sance v boji proti konkretnemu nepriatelovi, proti ktoremu su tie zbrane optimalizovane.
Alebo mu povies ze mas iba jednu ruku, ak chces mat tu druhu volnu pre svoje vlastne (nebojove) ucely, akurat to potom vyrazne znizi tvoju celkovu bojaschopnost.
_dworkin píše:
mam problem s tim kdyz rozdelim obrazek na tretiny, abych utekl paprsku tak budu mit ulozeny SP zbytecne 3x misto jednou
Na to sa vykasli. Ci bude SP odlozeny 1x alebo 3x, robi rozdiel "iba" 62T na 70000T co je 0.08%. Toto naozaj netreba nejak prioritne riesit. Alebo ak ano, az potom ked uz vsetko ostatne bude dokonale a optimalne :)
_dworkin píše:
Jedine co me napada s nejmensi bolesti hlavy je generovat nahodne reseni a ty porovnat.
Vies ako pakuje moj LzxPack ? Ponuka vela roznych variant kompresii a kazda varianta ma este rozne podvariany a kazdy podvariant moze mat este nejake parametre...
Co myslis, ako urcujem ktora kompresia bude najlepsia pre dane data ? Proste ich vsetky vyskusam ! A vyberiem tu najlepsiu.
Pre subory nad niekolko kB to predstavuje cca 3000 roznych moznosti kompresie. Preto LzxPack pakuje tak dlho (zopar sekund az minutku) pretoze proste skusa vsetky tieto kompresie :)
A preto - neboj sa vyskusat vsetky moznosti a vsetky kombinacie metod, ktore ta napadnu. A aj take co ta nenapadnu. Moderne Pomocne Calculatory su na to dnes uz dostatocne rychle, aby (pri beznych problemoch) vedeli hrubou silou nahradit rozne sice efektivne, ale velmi zlozite sofistikovane riesenia.
_dworkin píše:
Takze kdyz programu predhodim serii obrazku s tim jak vypada puvodni obrazek a jak chci aby vypadal novy, tak mu nerikam pravdu s tim puvodnim obrazkem, protoze pamet se uz muze lisit.
Proto bych musel generovat krome vystupu kodu i vystupni SCR, ktere by na pohled odpovidalo co chci, ale v pameti by byl ulozeny presna kopie chaosu v pameti co to vygenerovalo.
Pak by to mohlo byt pouzito jako vstup.
To me ale generuje proste dalsi zbytecne soubory.
Nie, ziadne zbytocne subory netreba. Ty programu podhodis dva screeny, program si tieto dva screeny priamo v pameti predpripravi tak ako by to spravil ten moj ZX reducer a kod generuje rovno z takto predpripravenych screenov. A potom ked programu podhodis dalsie dva screeny, tak si ich tiez interne predpripravi tak isto, takze aj ked to bude dalsia faza pohybu animacie, tak uz bude generovana zo spravnych dat. Ziadne screeny ukladat nepotrebujes. A kod pre uplne prvy screen "keyframe" celej animacie tiez vygenerujes uz z interne predpripraveneho screenu takze ti prvu fazu animacie rovno vykresli "redukovanu" a tym spravne pripravenu pre dalsie fazy animacie.
_dworkin píše:
Busy píše:
Ten vobec nepotrebujes, ved budes do pameti ukladat rovno data/kod/zdrojak ziskany a vytvoreny zo screenu upraveneho tymi pravidlami (v pripade ze budes ukladat iba rozdiely, tak aj vratane prveho "frejmu"). Aj tak to bude vyzerat rovnako.
Ne ten prepinac potrebuji.
Nie, nemyslel som prepinac, ale ten uvodny screen, vid moj predchadzajuci komentar.
_dworkin píše:
Takze i obraz pameti by uz neodpovidal vystupnimu "SCR", ale upravenym pravidlum.
Na prvni pohled na obrazovku totozne, ale data jsou jina.
Ved presne prave o to ide - aby to vyzeralo rovnako, ale aby bol kod vdaka tym inym data jednoduchsi, kratsi a rychlejsi.
_dworkin píše:
Maskou se mysli soubor ukazujici jak vypada obraz/pamet predtim(ted).
Aha, ale potom to nenazyvaj maskou, ale predoslou fazou animacie alebo predchadzajucim frejmom. Lebo taka maska v pripade obrazovych dat sa obvykle mysli nieco co umoznuje vykreslit sprajty na nejakom pozadi a maska na pixelovej urovni (teda nie cele pixelove bajty) urcuje kde bude kresba sprajtu a kde kresba pozadia.
_dworkin píše:
Aby mohl rovnou ukazat animovany multikolor co jinou metodou nejde.
Podobne tak pojem multicolor obvykle oznacuje ked mas v atribute viac roznych farieb ako dve - co vznika tak ze po nacitani pixeloveho riadku vratane atributu tento atribut zmenis, takze dalsi pixelovy riadok ma uz inu hodnotu.
To co ty myslis je rozsirena paleta farieb, miesanie farieb na 25Hz alebo tiez ULA+ farby.


Nahoru
 Profil  
 
PříspěvekNapsal: 12.08.2024, 21:58 
Offline
Pan Štábní

Registrován: 23.06.2013, 23:49
Příspěvky: 1293
Has thanked: 102 times
Been thanked: 195 times
Busy píše:
_dworkin píše:
Takze kdyz programu predhodim serii obrazku s tim jak vypada puvodni obrazek a jak chci aby vypadal novy, tak mu nerikam pravdu s tim puvodnim obrazkem, protoze pamet se uz muze lisit.
Proto bych musel generovat krome vystupu kodu i vystupni SCR, ktere by na pohled odpovidalo co chci, ale v pameti by byl ulozeny presna kopie chaosu v pameti co to vygenerovalo.
Pak by to mohlo byt pouzito jako vstup.
To me ale generuje proste dalsi zbytecne soubory.
Nie, ziadne zbytocne subory netreba. Ty programu podhodis dva screeny, program si tieto dva screeny priamo v pameti predpripravi tak ako by to spravil ten moj ZX reducer a kod generuje rovno z takto predpripravenych screenov. A potom ked programu podhodis dalsie dva screeny, tak si ich tiez interne predpripravi tak isto, takze aj ked to bude dalsia faza pohybu animacie, tak uz bude generovana zo spravnych dat. Ziadne screeny ukladat nepotrebujes. A kod pre uplne prvy screen "keyframe" celej animacie tiez vygenerujes uz z interne predpripraveneho screenu takze ti prvu fazu animacie rovno vykresli "redukovanu" a tym spravne pripravenu pre dalsie fazy animacie.
_dworkin píše:
Busy píše:
Ten vobec nepotrebujes, ved budes do pameti ukladat rovno data/kod/zdrojak ziskany a vytvoreny zo screenu upraveneho tymi pravidlami (v pripade ze budes ukladat iba rozdiely, tak aj vratane prveho "frejmu"). Aj tak to bude vyzerat rovnako.
Ne ten prepinac potrebuji.
Nie, nemyslel som prepinac, ale ten uvodny screen, vid moj predchadzajuci komentar.
_dworkin píše:
Takze i obraz pameti by uz neodpovidal vystupnimu "SCR", ale upravenym pravidlum.
Na prvni pohled na obrazovku totozne, ale data jsou jina.
Ved presne prave o to ide - aby to vyzeralo rovnako, ale aby bol kod vdaka tym inym data jednoduchsi, kratsi a rychlejsi.


Myslim si ze me nechapes.
Takze jeste jednou... rozdelime to pekne na 3 reseni.

Prvni reseni je to co je tam ted, muzeme to nazvat proste reseni.
Predlozis jeden nebo dva soubory.
Pokus predlozis dva soubory tak PRESNE TAKOVY jsou hodnoty na VSTUPU i VYSTUPU (s tim ze to jeste parametrem muzes upravit).

Druhe reseni je mit filtr a upravit si dva predlozene obrazky co dostane pro vstup a vystup. Muzeme to nazvat Busy reseni.
Pak se vstup zmeni na VSTUP-->FILTR-->UPRAVENY_VSTUP. A pamet se predpoklada ze je shodna s UPRAVENYM_VSTUPEM.
Vystupni obrazek se taky prvne zmeni na VYSTUP-->FILTR-->UPRAVENY_VYSTUP. A vysledek toho kodu jsou pak presne takovy hodnoty, aby byly shodne s UPRAVENYM_VYSTUPEM.
Myslim si ze ty porad mluvis o tomhle reseni.

Treti reseni je to co je problematicke a co nevim proc porad ignorujes i kdyz o nem neustale mluvim.
Protoze zanechava neviditelne artefakty. Takze to muzeme napsat reseni s artefakty.
Pak toho ceho chci dosahnout je, aby obraz byl pro oko identicky, ale na pamet sahal co nejmene a dosahl to nejlepsim zpusobem co umi.
Predpokladej scenar ze mas pozadi s hvezdama a raketou a ted to postupne zakryje mesic jednolitou barvou.
Vykresli to pixelove jen okraj mesice a vnitrek nastavi pomoci INK=PAPER=nejaka barva.
Pak zmizi mesic postupne mimo obraz a zase se bude vykreslovat jen okraj a pokud zjisti ze hvezda nebyla zasazena okrajem tak staci obnovit INK.
To ale nejde dosahnout kdyz mu predkladam falesny vstup, ktery mozna na oko vypada stejne ale ve skutecnosti je pamet jina, jen obraz vypada stejne. Driv nebo pozdeji se to pak pokazi, protoze ocekaval jiny obsah pameti.
Bud pak kreslim zbytecne co nemusim. Tu hvezdu, ktera neni dotcena, ale on to nevi.
A nebo naopak se me stane ze pohyb raketky zmeni PAPER != INK a pak pixely co jsem raketkou v tom znaku nezmenil se me najednou nechtene zobrazi (artefakt treba po vykresleni toho okraje mesice).
V tom pripade pokud to delam oddelene, tak potrebuji od neho bude skutecny obraz pameti i s neviditelnymi artefakty co vytvori pro ten vystup, aby to mohlo byt vstupem pro pristi frame a nebo to delat najednou. Aby si tu pamet drzel sam pro kazdy "mezikrok".

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH


Nahoru
 Profil  
 
PříspěvekNapsal: 12.08.2024, 22:22 
Offline
Pan Štábní

Registrován: 23.06.2013, 23:49
Příspěvky: 1293
Has thanked: 102 times
Been thanked: 195 times
Busy píše:
_dworkin píše:
Maskou se mysli soubor ukazujici jak vypada obraz/pamet predtim(ted).
Aha, ale potom to nenazyvaj maskou, ale predoslou fazou animacie alebo predchadzajucim frejmom. Lebo taka maska v pripade obrazovych dat sa obvykle mysli nieco co umoznuje vykreslit sprajty na nejakom pozadi a maska na pixelovej urovni (teda nie cele pixelove bajty) urcuje kde bude kresba sprajtu a kde kresba pozadia.


Predchozi fazi animace nebo framem sem to nechtel nazyvat protoze to stale beru jako univerzalni nastroj pro EXTREMNE RYCHLE kopirovani dat.
To ze to lze pouzit na animaci je vedlejsi efekt.
"Predchozim obrazem pameti pro tvorbu masky", jsem to mohl nazvat.
Ale puvodni idea byla predlozit masku na orezani toho co se ma kopirovat.
Az pozdeji me doslo, ze misto predkladani masky a teda praci s jejim tvorenim mohu pouzit "predchozi obraz pameti" a usetrit si praci. Nazev jsem pak nechal, protoze je kratsi a "je to jen tesne vedle".
Mozna bych to mohl zmenit na "input" nebo "original". Ale to by se mohlo taky nekomu nelibit a navic je to vic obecny a neni jasne k cemu to je.

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH


Nahoru
 Profil  
 
PříspěvekNapsal: 13.08.2024, 14:15 
Offline
Pan Štábní

Registrován: 23.06.2013, 23:49
Příspěvky: 1293
Has thanked: 102 times
Been thanked: 195 times
Vytvoril jsem "h" knihovnu...
...vlastne je to spatne...
h soubor by mel obsahovat jen headery ze?

No neva, to se dalo ocekavat spatne pojmy.

Takze vytvoril jsem soubor s koncovkou h... :D

Ktery v C resi ten pripad AF = konstanta.

Problem byl ze ten soubor mel 3.5 Mb... protoze tam bylo pole o 64k polozkach ktere jsem inicializoval...

Takze jsem ho zase promazal a neinicializoval kompletne s tim ze pokud to ma 31 taktu tak je to vzdy

ld HL,num : push HL : pop AF reseni a upravil funkci co inicializuje textovy retezec ve tvaru "DB 0x12,0x34,...".

Je to pole struktur:
Kód:
struct ld_af_bytes {
  unsigned char clocks;
  unsigned char bytes;
  unsigned char opcode[6];
};

A ty opcode inicializuji pomoci konstant:
Kód:
const unsigned char rlca   =0x07;
const unsigned char rrca   =0x0F;
const unsigned char rla    =0x17;
const unsigned char rra    =0x1F;
const unsigned char ld_hl_n=0x21;
const unsigned char daa    =0x27;
const unsigned char cpl    =0x2F;
const unsigned char scf    =0x37;
const unsigned char ld_a_n =0x3E;
const unsigned char ccf    =0x3F;
const unsigned char inc_a  =0x3C;
const unsigned char dec_a  =0x3D;
const unsigned char add_a  =0x87;
const unsigned char adc_a  =0x8F;
const unsigned char sub_a  =0x97;
const unsigned char sbc_a  =0x9F;
const unsigned char and_a  =0xA7;
const unsigned char xor_a  =0xAF;
const unsigned char or_a   =0xB7;
const unsigned char cp_a   =0xBF;
const unsigned char add_n  =0xC6;
const unsigned char sub_n  =0xD6;
const unsigned char push_hl=0xE5;
const unsigned char and_n  =0xE6;
const unsigned char pop_af =0xF1;
const unsigned char or_n   =0xF6;
const unsigned char cp_n   =0xFE;


Otazka zni... ma to cenu psat takto prehledne?
Ma cenu mit pristup k polzce bytes a clocks?
Vzhledem k tomu ze max bajtu je 6 a max. taktu je 31 u te push/pop metody... tak to muze byt jeden bajt! 3 bity a 5 bitu.
Misto konstant muzu mit DEC cisla...

Za kazdou polozkou jsem psal komentar ", // AF = 0x1234"

pomoci regularnich vyrazu jsem promazal vsechny liche cisla...

Pak vsechny cisla nekoncici nulou jsem upravil na tvar

",//..32"

a co konci nulou na

",//AF=1230"

ale i tak je to 1.8 Mb soubor... muzu to stale omezit udelat tabulku do tabulky, ale to se me taky nelibi.

https://codeberg.org/DW0RKiN/M4_FORTH/src/branch/master/M4/ld_af_const.h

PS: Testovaci soubory jsou o 10+ bajtu kratsi. Prvne jsem nechapal nez me doslo ze je tam NEKOLIK obrazku a nekdy i rozdeleny na tretiny a kazdy ma ld AF = a jeste ld AF'=.

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH


Nahoru
 Profil  
 
PříspěvekNapsal: 20.08.2024, 20:51 
Offline
Óm Nejvyšší

Registrován: 22.05.2013, 21:14
Příspěvky: 3797
Bydliště: Bratislava
Has thanked: 375 times
Been thanked: 811 times
_dworkin píše:
Myslim si ze me nechapes.
Takze jeste jednou... rozdelime to pekne na 3 reseni.
_dworkin píše:
Treti reseni je to co je problematicke a co nevim proc porad ignorujes i kdyz o nem neustale mluvim.
Neignorujem, len mi z tvojho predchadzajuceho popisu nebolo jasne ze vlastne pises o troch roznych rieseniach. Skoda ze si tie tri riesenia jasne nespeficikoval uz na zaciatku.
_dworkin píše:
...to stale beru jako univerzalni nastroj pro EXTREMNE RYCHLE kopirovani dat.
To ze to lze pouzit na animaci je vedlejsi efekt.
Snazit sa u univerzalny nastroj je podla mna zla koncepcia.
Na mnohogigabajtovych a mnohogigahertzovych pocitacoch je to obvykle jasna volba, pretoze tie su dostatocne vykonne na to aby umoznovali pouzivat univerzalne a opakovatelne riesenia (a tym setrit naklady na programatora), ale my sa pohybujeme v uplne inom (a nekomercnom) svete - vo svete kde nepotrebujeme za kazdu cenu eliminovat naklady na programatora, ale mame to ako hobby a v ramci toho chceme dosiahnut co najlepsie riesenie site na mieru pre konkretnu situaciu. A v tomto pripade jedna konkretna situacia je prave ta animacia (to je aj 25Hz miesanie farieb), a napriklad nejaka ina konkretna situacia moze byt zase multicolor.
Riesenie, ktore by bolo univerzalne a zaroven poskytlo najrychlejsie mozne kopirovanie dat, tu proste neexistuje :)

Ono ked sa tak nad tym zamyslam, tak tvoje riesenia s priamym ukladanim wordov (ci uz ld (...),hl alebo push) nie su az tak univerzalne, pretoze
a) samotny kod je dlhsi nez blok ktory takto kopirujes, co je v mnohych pripadoch neakceptovatelne
b) nemozes vseobecne (napr. zaciatocnou adresou zdrojovych dat ako parametrom do uz hotoveho kodu) specifikovat zdroj dat odkial sa ma kopirovat.


Nahoru
 Profil  
 
PříspěvekNapsal: 06.09.2024, 22:42 
Offline
Pan Generální
Uživatelský avatar

Registrován: 11.06.2013, 15:27
Příspěvky: 3201
Has thanked: 2296 times
Been thanked: 962 times
Ad uvodni zminka:
_dworkin píše:
Vysledek je out.tap a ten muzete porovnat s rotation.tap v jinem vlakne...

Navedete mne prosim, ktery prispevek to konkretne je?

_________________
// na co myslím, když sedím u oldkompů: . celníci


Nahoru
 Profil  
 
PříspěvekNapsal: 07.09.2024, 00:57 
Offline
Pan Štábní

Registrován: 23.06.2013, 23:49
Příspěvky: 1293
Has thanked: 102 times
Been thanked: 195 times
SCjoe píše:
Ad uvodni zminka:
_dworkin píše:
Vysledek je out.tap a ten muzete porovnat s rotation.tap v jinem vlakne...

Navedete mne prosim, ktery prispevek to konkretne je?


Pokud neco nevis tak ja to urcite taky nevim... .)
Zvlast kdyz si VUBEC NIC UZ NEPAMATUJI.
Ale jsem dost blblej, abych se to snazil najit...
Nic jsem nenasel, ale nakonec se me pamet prece jen obnovila...
Pamatuji si nejake vlakno od JIVY kde prezentoval svuj DOSovy program s rotujici spiralou...
Mozna to bylo smazane, nebo jsem blbe hledal.
Ale to je to vlakno o kterem se zminuji, ze obsahuje zdrojaky programu pro ZX co kresli spiralu.

Mozna to bylo vlakno Tigerhareram Archive 2024 update nebo o te hre na itch.io nebo o tom jeho linuxu... ale kdyz to nemam v seznamu vlaken kam jsem prispival tak je to asi smazane.
Jsem si jisty ze to mam v nejakem bordelu stale na disku, znovu nahravat to nema cenu, stejne o nic nejde, aspon se usetrilo misto na webu. .)))
Kdo to kdy videl posilat jako odpoved program!
Kdyby to nekdo chtel... tak az dokoncim 100 dnovy maraton zirani nepretrzite do spiraly... protoze kdyz se budes divat dlouho do spiraly... spirala se bude divat do tebe...
...tak to muzu s fanfarami nahrat. .)

_________________
Z80 Forth compiler (ZX Spectrum 48kb): https://codeberg.org/DW0RKiN/M4_FORTH


Nahoru
 Profil  
 
Zobrazit příspěvky za předchozí:  Seřadit podle  
Odeslat nové téma Odpovědět na téma  [ Příspěvků: 40 ]  Přejít na stránku Předchozí  1, 2, 3

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]


Kdo je online

Uživatelé procházející toto fórum: Žádní registrovaní uživatelé a 1 návštěvník


Nemůžete zakládat nová témata v tomto fóru
Nemůžete odpovídat v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete přikládat soubory v tomto fóru

Hledat:
Přejít na:  
cron
Založeno na phpBB® Forum Software © phpBB Group
Český překlad – phpBB.cz