OldComp.cz

<reklama>
Potrebujete co najlepsie spakovat obrazok ? Potrebujete co najviac skratit dlzku programu obsahujuceho obrazok ? Setrite miestom a kazdy bajt je vam dobry ? Potom ste na spravnej adrese ! ZX Spectrum screen remapper je ako stvoreny prave pre vas !!!

Vybrali sme nahodny obrazok - zaverecny obrazok z Micro dema - mikroskop - a vyskusali sme na nom ZX screen remapper !
A tu je vysledok !!
6912 ... Originalny nespakovany obrazok
4886 ... Obrazok spakovany iba Pressor5-kou (depaker 82 + data 4804)
4517 ... Obrazok spakovany iba LzxPack02-kou (kompresia tr47, depaker 79 + data 4438)
4220 ... Najprv Pressor5 a potom LzxPack02 (kompresia tn78, depaker 178 + data 4042)
3664 ... ZX remapper (mode 21, demapper 62 + data 6912) a potom LzxPack02 (tr34, depaker 97 + data 3563)
Vidime, ze vysledok so ZX remapperom je este o dost lepsi nez akakolvek metoda bez neho ! A to sa vyplati !!!
</reklama>

A teraz trosku vaznejsie

Na pakovanie obrazkov sme dlhocizne roky pouzivali specializovany screen pakovac - Pressor (obvykle verzie 5 a 6). Genialita tohto pakovaca spociva v tom, ze nerobi len nejaku jednu defaultnu kompresiu, ale ma v sebe niekolko roznych typov kompressi zvlast pre pixely a niekolko dalsich typov kompresii pre atributy. Pri pakovani vyskusa vsetky, vyberie tie ktore dosiahli najlepsi kompresny pomer a toto ponukne uzivatelovi. Samotne kompresie su zalozene na vhodnom preusporiadani obrazovych dat a naslednej aplikacii kompresie typu RLE, pricom data su preusporiadane tak, aby to pomohlo RLE kompresii dosiahnut lepsi vysledok.

Takto skompresovany obrazok (preusporiadanie + RLE) sa nasledne este vyplati spakovat nejakou LZ kompresiou (Turboimpoder, LzxPack...), ktora najde v datach rovnake bloky a vdaka tomu data este viac a lepsie spakuje.

Tento sposob pakovania obrazkov som pouzival dlhe roky...

...az kym mi nedoslo, ze pri modernyn LZ kompresiach ta RLE kompresia tomu az moc nepomaha, pretoze LZ kompresia je v principie cosi ako nadmnozina RLE a vsetko, co zvlada RLE, by zvladla aj nasledna LZ. Tak som si spravil zopar testov a zistil som (prekvapujucu, ale logicku) vec - RLE kompresia nielenze nepomaha, ale vysledok este zhorsuje ! A zhorsuje to preto, lebo do dat vnasa dalsiu (teraz pouzijem taky fuj odborny termin) entropiu, ktora vo vysledku data iba zbytocne predlzuje. Touto entropiou je rezia okolo kompresie - v zavislosti od typu RLE - potrebuje znacky ci sa jedna o povodny nepakovatelny blok dat alebo opakujuci sa bajt, a tiez aj pocty spakovanych bajtov.

Takze rozhodnutie bolo jasne - poslat celu RLE kompresiu do haja. Lenze pakovac screenov Pressor toto priamo neumoznuje, musel by sa prerobit, a tiez by bolo treba netrivialne prerobit aj vsetky jeho depakery, pretoze obe funkcionality - preusporiadanie a aj RLE dekompresor - su navzajom skombinovane v tej istej rutinke.

Preto som sa rozhodol, ze spravim nieco ako Pressor, ale s tym, ze iba preusporiada data v obrazku, ale nebude robit RLE kompresiu. A kedze dnes je moderny crossdevelopment, tak pobezi nie na ZX Spektre, ale na Pomocnom Calculatore (a inych mnohobitoch), aby bolo mozne cely proces pakovania obrazku pekne zautomatizovat, hlavne zretazit aj s LZ kompresorom, takze staci napr. nejake jedno makefile.

Takze tymto vam predstavujem moj novy ZX Spectrum screen remapper

Pouzitie je nasledovne:Po spusteni sa vygeneruje osem suborov s nazvami vystupny_premapovany_obrazok.mXY kde XY su cislice oznacujuce sposob premapovania alebo preusporiadania dat. Nasledne mozete na tieto vygenerovane subory aplikovat vasu oblubenu LZ kompresiu (ja osobne doporucujem samozrejme LzxPack02 ) a vybrat si ten, kde tato kompresia dosiahla najlepsi kompresny pomer.

Ciselny parameter <startovacia_adresa> je nepovinny. Ak ho uvediete, tak program k premapovanym datam pribali aj kratucku rutinku, ktora premapovane data zobrazi na obrazovke v povodnom tvare. Potom staci takto vygenerovany subor nahrat do pameti a spustit od tejto startovacej adresy.

Ak by ste si rutinky chceli "prilinkovat" sami, alebo ich nejak pomenit, v balicku su prilozene aj zdrojove texty tychto rutiniek.

A je to

A este dve ukazky o tom ako remapper dokaze pomoct:

Help screen z dema Song in lines 3, tak ako je, LzxPack samotny zapakoval na 1833 bajtov.
Remapovany (rezim m11) a zapakovany LzxPack-om ma 905 bajtov. Teda menej ako polovica.

1k intro Evolution https://www.youtube.com/watch?v=-KG5SWDtGqs obsahuje 7 obrazkov.
815 ... vsetky obrazky priamo spakovane pomocou ZX7 (povodny packer pouzity v intre)
739 ... vsetky obrazky priamo spakovane pomocou LzxPack02
528 ... premapovane obrazky spakovane LzxPack02
Takze vysledne spaknute obrazky zaberaju cca polovicu povodneho rozsahu intra 1kB a do intra by sa ich voslo ovela viac. Alebo nejaka pekna hudba, aby to nebolo uplne hluche

A na zaver asi to najdolezitejsie. Stahujte tu: https://busy.speccy.cz/download/zxremap6.rar

Škoda, že se nepokračuje v tom dungeonu. Tam by hádám tahle nová komprese krutě pomohla.

_________________
Amiga/Amstrad/Atari/Commodore/Mac/Nintendo/PS/PC/Sega/Tandy/ZX

Wycheweald 2023
https://www.dungeoncrawlers.org/game/wycheweald/

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

Aha. Tak tys ho dokončil... To mě nějak minulo Jen vypadá nějak jinak, než si ho pamatuju. Kde je podlaha? Kde je barevná grafika ve výhledu? (soudím jen podle screenshotů)

_________________
Amiga/Amstrad/Atari/Commodore/Mac/Nintendo/PS/PC/Sega/Tandy/ZX

To jsem nepsal ja. A pouzivaji trochu jine techniky nez prosty maliruv algoritmus.

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

Asi by bolo dobré spomenúť pod čím ten remapper beží. Jeden by predpokladal DOS keď je tam exe a argumenty, ale vidím tam vo výpise "This program cannot be run in DOS mode.", takže Windows? Ktorý? Na konci je KERNEL32, takže Windows 98 a novší?

_________________
Oznamy o novom príspevku mi na mail chodia iba sporadicky, takže keď sa nehlásim v diskusii, tak je to tým. V 80% nepríde mail vôbec.

Mas tam zdrojak v cecku co pripojuje jen
takze to jde zkompilovat skoro vsude. Takze to bezi taky vsude, kde to potrebujes. Za me velky palec nahoru, ze to pouziva parametry a neni to napsany na klikani a zavisle na win.

PS: Jedine co bych delal jinak, ze bych to balil s adresarem a asi zipem.

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

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

_dworkin ti na to uz odpovedal, tak ja len doplnim ze:

- koncovka "exe" je taky standart pre spustitelne subory aplikacii vo vsetkych systemoch od microsoftu: msdos a vsetky mozne 16,32,64 bitove windowsy
- KERNEL32.DLL je klasika pre vsetky 32bit a 64bit windowsy, aj 64bit aplikacie si importuju KERNEL32.DLL (samozrejme 64bit verziu)
- "This program cannot be run in DOS mode." to vypise pri spusteni v cistom msdose, to je taky standartny zaciatok vsetkych windowsackych exacov. Konkretne tuto hlasku obvykle pouzivaju 32 a viacbitove aplikacie. Povodne vznikla pri Win95 / 98 / ME ktore este stale bezali nad msdosom a bolo mozne si nechat bezat iba ten msdos (to je ten DOS mode v ktorom by dotycny program nebezal).

Vdaka !
Tak nejak z cias unixu som zvyknuty skor na cmdline utilitky, ktorych cinnost sa da automatizovat v skripte. Napriklad ja ho pouzivam v scripte, ktory urobi cely pakovaci proces naraz - vygeneruje vsetky premapovane obrazky, kazdy zapakuje a potom ich vypise (na konzolu aj do txt suboru) v poradi podla vyslednej dlzky.
Pricom medzi podla dlzky zoradenymi spakovanymi obrazkami je aj povodny obrazok bez premapovania, pretoze pri niektorych specifickych obrazovych datach moze akekolvek premapovanie viest k dlhsiemu vysledku.
Preco s adresarom ? Nechce sa ti robit adresar pre depakovanie ? Pokial to ale depakujes priamo v nejakom GUI depakovaci (WinRar, 7zip...) tak ten ti adresar vyrobi sam.

Asi som blbý, ale ja zo zdrojáku v Cé neviem skompilovať funkčný exe súbor.

>> Stačilo napísať že na to exe treba minimálne Windows 95.

_________________
Oznamy o novom príspevku mi na mail chodia iba sporadicky, takže keď sa nehlásim v diskusii, tak je to tým. V 80% nepríde mail vôbec.

Pod pravym tlacitkem mam na vyber:
Vetsina veci obsahujici vic souboru na ktere narazim uz ma v sobe adresar, takze se mi stane ze to ma 2x zanorene. Tentokrat jsem to neuhlidal a pak hledal obsah archivu mezi ostatnim bincem (to jsem nestastne formuloval) a presouval do rucne udelaneho adresare. Proto preferuji ten adresar.

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

Čéče... po podobných skúsenostiach rozbaľujem archívy zásadne v prázdnom priečinku. Skúsenosti. Najhoršie bolo rozbaliť niečo na plochu a očakávať že to bude v zložke. Nebolo, cez 100 súborov pomiešaných so všetkým čo som mal na ploche... to bola sranda. Ale riešenie bolo ľahké: rozbaliť to ešte raz niekde do priečinka, potom cez TC porovnať obsah plochy a priečinku, a čo bolo na oboch miestach naraz nechať z plochy zmazať.

_________________
Oznamy o novom príspevku mi na mail chodia iba sporadicky, takže keď sa nehlásim v diskusii, tak je to tým. V 80% nepríde mail vôbec.

Co dělám blbě? Zkusil jsem zabalit obrázek monoscop.scr (na linuxu, zkompilováno gcc) a získal jsem několik souborů velikých 6912 bytů, jako byl původní soubor.Neměly být různě veliké podle toho, jak úspěšná byla ta která varianta konmprese?

Dají se z toho získat relokovatelné samorozbalovací obrázky jako z Pressoru? Pokud ano, budou začínat stejnými instrukcemi, jako některá z variant Pressoru, aby se daly používat zobrazovače detekující samorozbalovací obrázky?

Věnoval jsem tomu zatím sotva deset minut, tak možná později zjistím, že jsem přehlíd něco zásadního... ale na první pohled to není tak intuitivní, jak bych rád.

_________________
https://cygnus.speccy.cz ZX Spectrum 128k, Betadisk, DivIDE, ESXDOS

Zkusil sis ty obrázky zobrazit?

Pokud jsem to pochopil, remapper pozpřehazuje data v obrázku různými způsoby, aby pro následující kompresi mohla být lépe uspořádána k dosažení lepšího výsledku.
Ale sám remapper nepackuje, jen přeuspořádá data.
(Nevím ale - nemá tam někde být i rutina 62 bajtů na zpětné přeuspořádání dat zpět na viditelný nerozházený obrázek?)

Packování se pak provede něčím (oblíbeným kompresním programem) nad těmi různě zpřeházenými daty.


Edit: aha, tak rutinka může nebo nemusí být.
"Ciselny parameter <startovacia_adresa> je nepovinny. Ak ho uvediete, tak program k premapovanym datam pribali aj kratucku rutinku, ktora premapovane data zobrazi na obrazovke v povodnom tvare. Potom staci takto vygenerovany subor nahrat do pameti a spustit od tejto startovacej adresy.

Ak by ste si rutinky chceli "prilinkovat" sami, alebo ich nejak pomenit, v balicku su prilozene aj zdrojove texty tychto rutiniek."