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