ZX Spectrum > SOFTWARE
On-the-fly Screen Compressor
Phonex:
--- Cytat: Klaud w 2018.12.25, 13:34:21 ---Mogę tylko popodziwiać i trzymać kciuki za chęci. Oby tak dalej.
--- Koniec cytatu ---
No nie wiem, czy będzie jeszcze jedna taka sytuacja. Jednym z powodów było to, że Tygrys zorganizował speccy party w Remoncie, drugim rozmowa z Dalthonem o kompresorach, trzecim Dalthona "wszystkie ręce na pokład" w związku z Remontem. A w książce "Jak blefować doskonale: programowanie" napisali, że co jakiś czas trzeba coś pokazać żeby ludzie uwierzyli że jestem w tym dobry ;D
Nie miałem pomysłu na demo jako demo, więc postanowiłem napisać użytka i do niego demo ;) Niestety nie udało się go wtedy pokazać.
Czwartym powodem powstania programu, był pomysł.
Pierwsze przemyślenia sugerowały, że rzecz jest niewykonalna. Nie było szans żeby wyrobić się czasowo. Wydawało mi się że jest to jeszcze trudniejsze niż napisanie np. kopiera z kompresją, bo tam jest tak: w czasie ładowania kopier liczy powtarzające się bajty i wynik wpisuje do pamięci (trzy wpisy: znacznik, licznik, bajt), w czasie zgrywania odczytuje ilość (do trzech odczytów z pamięci) a potem wysyła ileś bajtów na taśmę. A tu trzeba odczytać z taśmy jeden do trzech bajtów a potem z tego wykonać 1 do 128 wpisów do pamięci PRZED załadowaniem następnego bajta z taśmy!
To nie mogło się udać.
Aż wpadłem na pomysł, że przecież nie trzeba zakończyć PRZED załadowaniem następnego bajta - można ładować jak zawsze: skompresowany obrazek jak zwykle ładuje się pod 40000, a drugi proces sprawdza sobie czy są nowe bajty i je obrabia. I ponieważ jest jednak więcej nieskompresowanych niż skompresowanych bajtów, to spokojnie można na luzie wpisywać 1 może 2 powtarzające się bajty na raz! Do końca pliku się wyrówna.
To z kolei groziło tym, że jeśli skompresowane bajty będą pod koniec pliku (a często będą - na końcu są atrybuty) - program nie zdąży ich rozkompresować przed zakończeniem ładowania.
Zacząłem już nawet kombinować na ile bajtów przed końcem obrazka zaprzestać kompresji, aż wpadłem na następny pomysł - przecież nie musi skończyć przed zakończeniem ładowania! Po zakończeniu, dzięki temu że to niezależny proces, można wielokrotnie wywoływać dekompresję aż nie zasygnalizuje że już wszystkie bajty zrobione. Bez ładowania uwinie się dosłownie w mgnieniu oka i nawet nie będzie widać.
Żeby nawiązać do Fast Compressora (i może z lenistwa) nie zmieniałem interfejsu programu, dorobiłem tylko pulsującą nazwę, żeby go wyróżnić.
Ach! Teraz pisząc o tym, zrozumiałem dlaczego nie ma oczekiwanego przeze mnie efektu zmian szybkości w trakcie ;) Tego można by oczekiwać po tej pierwotnej "niewykonalnej" wersji.
trojacek:
Ahaaaaaa...! ;)
To teraz wszystko jasne :)
Phonex:
Nagle okazało się, że to już prawie pięc lat! To przez tą epidemię chyba...
Pora na upgrade.
Już wtedy, jak pisałem, wiadomo było że do napisania jest jeszcze jeden - oparty na moim Top Screen Compressor (ups, nie wysłałem go do Archiwum, chyba nie mogłem go kiedyś znaleźć...).
Top - jak nazwa sugeruje - kompresuje lepiej. Lepiej, bo nie analizuje po adresach, tylko kolumnami. A po drugie - ma dwa "najpopularniejsze bajty", które przy kompresji koduje na dwóch bajtach (zamiast trzech), a nie jeden jak "Fast". Pierwszym bajtem jest oczywiście zero, drugi sobie wybiera.
Używa do tego dwóch bitów licznika bajtów. W związku z tym licznik liczy tylko do 63, chociaż potrafi też zakodować 256 zer. Ale chyba się opłaca, bo obrazki kompresowane tym są prawie zawsze krótsze niż "Fastem".
Odłożyłem to na później, bo obliczanie adresu następnego bajta jest skomplikowane - już wyświetlanie z pamięci trwa chyba z pięć razy dłużej.
Ale po pięciu latach już nie ma co zwlekać i jak widać da się :D
Ten "stary" wpisuje dwa powtarzające się bajty przy jednym wywołaniu procedury, teraz dało się tylko jeden, a zamiast INC HL jest podprogram, który sam zajmuje jedno, a czasem aż dwa wywołania. Czyli w czasie jednego bajta z taśmy dostajemy czasem tylko 5 i ćwierć bajta obrazka, a nie 32!
Efekt? Nawet na takim dość pustym obrazku, wyświetlanie może być opóźnione względem ładowania o kilkadziesiąt bajtów. Przy uważnej obserwacji, widać że np. atrybuty są wyświetlane później niż je słychać z taśmy (o ~30 bajtów, czyli ~0,15 sekundy).
Na razie tylko loader, w zasadzie demo loadera, bo stałe czasowe jeszcze nie są przeliczone (w emulatorze działa).
Finalnie będzie nowy kompresor - w wersji ambitnej z wbudowanymi obydwoma sposobami kompresji i możliwością wyboru "najkrótszy(auto)/kolumnami/adresami" - co z kolei było w planie od zawsze czyli od 1990! Myślę że wyrobię się do pełnej 5 rocznicy (grudzień) ;)
Phonex:
A może zrobić pokazywanie od razu z atrybutami?
Bo patrzę na to ładowanie i nie podoba mi się. Tak wygląda dekompresja z pamięci, ale wtedy atrybuty pokazują się po sekundzie... Przy ładowaniu z dekompresją "po pamięci" też atrybuty są później, ale to niewiele odstaje od klasycznego sposobu ładowania, do którego przywykliśmy.
A skoro i tak trzeba przeliczać adresy, i wiem już jak upchnąć w czasie ładowania więcej operacji niż wydawało się możliwe, to może uda się i z kolorami od razu?
Wyglądałoby mniej więcej tak - tylko bez tych artefaktów na atrybutach na początku - to tylko demo, po prostu przestawiłem atrybuty na początek.
Tygrys:
Zawsze dane mogą zawierać adres pamięci dla pixeli i kolorów. Wtedy wprawdzie blok danych będzie trochę dłuższy, ale osiągniesz to co chcesz.
Nawigacja
[#] Następna strona
Idź do wersji pełnej