Lamerskie pytanie: Który atarowski depaker rozpakowuje dane liniowo i pozwala np. rozpakować stronę pamięci per ramka (nie wszystko w jednym rzucie do dest)? Nie wiem jak to działa, ale wyobrażam sobie że niektóre toole sieją po dest (a może nie)?
Ma ktoś może tak zmodyfikowany depaker jakiegoś typu gdzie określa się taki "paging" / n bajtów per iterację
Ugh - jeżeli to pytanie jest oczywiste to przepraszam :) Ale nie znam się na tym :)
Jeśli masz zamiar pakować każde 256 bajtów niezależnie od innych, to nastaw się na słabą wydajność kompresji. I oczywiście możesz użyć dowolnego pakera.
Jeśli zamierzasz pakować więcej na raz, to oczywiście potrzebujesz dostęp do poprzednio rozpakowanych danych i żaden paker nie wspiera "pauzy" co ramkę. Rozpakuj wszystko (albo przynajmniej kilka kilobajtów) i przepisuj sobie co ramkę.
wydaje mi sie ze dosc prosto mozna przerobic depakera tak, zeby tworzyl tylko jedna strone danych wyjsciowych co iteracje ale dodanie do tego parametru czasowego czyli ze ma to zrobic np. w jedna ramke to juz nie wiem jak.
Chodzi mi dokładnie o to co napisał XXL w pierwszej części zdania, nie ma jednak znaczenia czas trwania (to był przykład który niepotrzebnie zaszumił moje pytanie) tylko ilość bajtów na iterację (nieważne ile trwa - bo to pewnie zależy)
Chodzi mi o to, ze mam spakowane np 16KB w pliku o rozmiarze x. Rozpakowuje sobie to do obszaru o wielkości 16KB (lub innego( ale w iteracjach co np. 256 bajtów, albo 32 bajty. Czyli rozpakowuje 256 bajtów robię coś i potem znowu kolejne 256 bajtów - i tak do końca (przy założeniu sprawdzania, że to już koniec :)
aha - zależy mi na tym aby co każdą iterację móc zmieniać dest dla kolejnych bajtów z ropakowywanej całości. Czyli np. rozpakowuje spakowane 16KB stronami zawsze w to samo miejsce przy każdej iteracji. Co oznacza dest o rozmiarze strony przy 256 bajtach na iterację. Czyli chcę mieć maksymalną wydajność kompresji a rozpakowywać używane bloczki o stałym rozmiarze sekewncyjnie.
Najbardziej popularny algorytm kompresji to LZ77. Przeczytaj chociaż pierwszy akapit. W Twoich skompresowanych danych może być informacja "powtórz 10 bajtów, które zostały rozkompresowane 500 bajtów wcześniej". Jeśli bufor wyjściowy ma tylko 256 bajtów, nie będziesz w stanie tego rozkompresować.
Można przerobić depakery, aby pauzowały co 256 bajtów, ale muszą one mieć dostęp do wcześniej rozkompresowanych bajtów.
Nie znam się to się wypowiem ;) Czy nie zadziała przypadkiem coś ze stałym słownikiem np. kompresja Huffmana (chyba jest w MADS). A może wystarczy ta najprostsza metoda ze zliczaniem powtarzających się elementów?
No tak - akapit z przykładem mówi wszystko o tym rodzaju kompresji. Niestety nie mam pamięci aby korzystać z danych wcześniej rozpakowanych - w swoim case - i świadomie bym je usuwał po użyciu. Także nici z tego.
Ale sam pomysł pauzowania co x bajtów i tak może się przydać w kilku rzeczach które przychodzą mi do głowy (np. rozpakowywanie tylko linii dużego obrazka do scrolla składającego się z 4 ekranów, każdy ekran ma osobno spakowany strumień). Dzięki temu można by oszczędzić na pamięci ekranu i zaoszczędzić czasu odbiorcy na depaking całość rozpakowując co przesuw tylko linię. Ale to dygresja.
Może poczytam o innych rodzajach kompresji - jak mi się sprawdzą i czy da radę tak ich użyć jak napisałem. Przyznam nie mam praktycznie powtarzających się bloków tych samych wartości przez co LZ77 raczej najbardziej by pasował (dopasowuje patterny danych)
Tak czy siak - bardzo dziękuję za wskazówki i wyjaśnienie. Zawsze diabeł tkwi w uproszczonej implementacji - być może są depakery które korzystają tylko ze z góry zaalokowanego bufora przy strumieniowej dekompresji co akurat by mi pasowało.
Dla metody Huffmana trzeba trzymać w pamięci słownik, a następnie mamy 1:1 przełożenie kod Huffmana bajtu->bajt. Możemy sobie rozkompresowywać co chcemy, odkąd chcemy, ile chcemy i gdzie chcemy, ale trzeba zadbać, żeby nie wskoczyć w środek pojedynczego kodu Huffmana.
Oczywiste. Najwięcej osiągnę pakując jednak jak najwięcej na raz. A na to obecnie nie będę mógł sobie pozwolić i będę kombinował z dzieleniem na mniejsze paczki (reużycie obszarów z danymi już rozpakowanymi zakładałem już wcześniej). Eksperymenty z RLE na razie wypadają mega słabo ze względu na specyfikę danych.
Obecnie zatem szukam kompromisu a to raczej oznacza ustępstwa i nieco gorszy efekt niż planowałem. Oczywiście włączenie dodatkowych banków pamięci od razu rozwiąże moje problemy pstryknięciem, jednakże rozwiązanie nie będzie chodzić na stockowym 64KB na czym mi zależy.
Jak to i się uda to przedstawię może jak do tego podchodziłem w tym wątku i ocenicie chłodnym okiem czy dałoby się inaczej i lepiej :) Jak znam życie pewnie tak będzie :)
ja bym podzielil dane, spakowal i trzymal w osobnych plikach doczytywanych w razie potrzeby i dopiero depakowal - bedziesz mial 16kb praktycznie caly czas wolne. uzylbym inflate foxa (najmocniejsza kompreska dostepna dla atari).
Potrzebujesz strumieniowej wersji depakera. Każdą procedurę dekompresującą da się przerobić do takiej wersji. To kwestia odpowiednio napisanej maszyny stanu. Wersja taka jest atrakcyjna w sytuacjach, kiedy rozmiar rozpakowywanej tablicy przekracza wyraźnie rozmiar zdekompresowanego kawałka i nie ma potrzeby swobodnego dostępu do całej zdekompresowanej tablicy.
Będę musiał skorzystać z tego rozwiązania w Ryszardzie. Zamiast rozkompresowywać całą komnatę (makrobloki 4x4 - max 256 bajtów) do pomocniczego bufora, wystarczy, że rozkompresuję jeden wiersz (8 makrobloków - 8 bajtów). To jest wystarczające do wypakowania bufora graficznego całej komnaty. W tym przypadku nie jest to wielki zysk (256-8 bajtów), ale mam kilka innych takich sytuacji, np. paleta VBXE, której nie ma potrzeby przechowywać na stałe w pamięci - można nakarmić zdekompresowanymi w locie danymi HW.
Taka procedura posiadałaby interfejs iteratora.
Jeśliby wczytywać na bieżąco takie dane z medium, to nie ma potrzeby ich w ogóle wczytywać całościowo do pamięci. W przypadku fizycznego dysku może to spowolnić odczyt, ale gdyby władowywać dane z CART'a, byłoby to już atrakcyjne.
LZ77 w xBIOS'ie działa jako filtr IO na podobnej zasadzie, jeśli się nie mylę.
a używasz pamięci pod ROM? propozycja Konopa też jest dobre, wymaga tylko specyficznego pakowania. jeszcze taki pomysl, jesli dane zrodlowe wczesniej rozpakowane nie beda uzywane (nie depakujesz tego samego dwa razy) to mozna by zwalniac miejsce na biezaco...
