laoo/ng: faktycznie maximum perwersum. ;)

e chyba cos poknocilem. juz sam niewiem

hmm, a moze tak:

przyklad 1: 12 +1 bajtow
przyklad 2: 12 +1 bajtow

1. wypelniamy blok 192 bajtow kodem powtarzajacym sie najczesciej
2. rozkaz 1 bajt index w bloku, 2 bajt |M|T|D|D|P|P|P|P|W| gdzie
M - metoda fill, plot (plot stawia dana na poczatku i po przesunieciu, fill wypelnia)
T - tryb patrz P dla plot automatyczna zmiana na draw
D - dane - sa juz tyklko 3 rozne elementy
P - przesuniecie 1-16 lub index+x*16
W - jakas wartosc bitu 9

metoda wolna, zero tablic, dekompresor bardzo :-) krotki.

i tu sie zastanawiam czy to tylko na kartce tak fajnie wyglada?

zapisze jeszcze raz:

rozpakowane bloki maja po 192 bajty, wypelniamy go wartoscia wystepujaca najczesciej

pobieramy dlugosc 'programu z opisem dekompresji'
pobieramy kolejno 2 bajty

co zawieraja te dwa bajty:
pierwszy bajt - index - od ktorego miejsca w boku 192 b zaczynamy
drugi bajt bity od najstarszego:

|M|T|D|D|P|P|P|P|W|

M - metoda fill, plot
plot stawia dana na poczatku i po przesunieciu innymi slowy moze zrobic tak: ABBBBBA lub tak: A (A istotny),
fill wypelnia, moze zrobic tak:AAAbbbAAAbbbAAA (A istotny) - nie z przykladu powyzej

T - tryb patrz P dla plot automatyczna zmiana na draw
jesli M bylo plot to przy ustawieniu T mamy draw oraz zmiane interpretacji P

D - dane - sa juz tyklko 3 rozne elementy
dane: 01, 10, 11

P - przesuniecie 1-16 lub index+x*16
w zaleznosci od T mozemy zrobic przy plot tak: A lub AbbbbbA a przy draw tak: AAAAAA lub tak: AbbAbbA (A dane istotne)
to dekompresor musi zadbac i obliczac koniec dzialania rozkazow ale to jest akurat b.proste.

analogia w nazwie fill, draw i plot jest trafna w przypadku tego algorytmu i TYCH konkretnych danych.

W - jakas wartosc bitu 9
moj poprzedni post byl zaszumiony i to jest wlasnie ta niechciana tresc ;-)

Algorytm konkretnie pod zastosowanie, czyli rzeczywiscie w praktyce program i maszyna wirtualna ktora go wykonuje :)
Pobierannie po dwa bajty jest bardzo wygodne i faktycznie chyba juz nie ma co kombinowac dalej, bo kodujac na bitach moznaby uszczknac tylko z 2-3 bajty ale IMHO za duzym kosztem.

nie wiem tylko jak obliczana jest ta ilosc literek 'b' do pominiecia i od ktorego momentu pomijamy, ale wierzę, ze to jest zakodowane jakos w P :) Jezeli te kodowanie w P jest dobre, to powinno dzialac :P

Cyklujac najbardziej zagniezczone petle mamy

loopp   lda (ptr3),y    ;5
        sta (ptr2),y    ;6
        inc ptr3        ;5
        inc ptr2        ;5
        dex             ;2
        bne loopp       ;3

26 cykli

oraz

rle     sta (ptr2),y      ;6
        inc ptr2          ;5
        dex               ;2
        bne rle           ;3

16 cykli.

Dodatkowo zauwazylem, ze w mojej procce jest blad bo zapomnialem, ze iny tez ustawia bit N. Rozwiazaniem jest dodanie np lsr @ czyli

L   lda $ffff,y             ;4
    lsr @                   ;2
    sta bufor_docelowy,y    ;5
    iny                     ;2
    bcc L                   ;3

i mam 16 cykli zamiast 14 i moje obliczenia sredniego czasu zwiekszaja sie do  27 cykli (najmniej 18 cykli najwiecej 29) oczywisice pamietajac zeby dane byly przesuniete w lewo i konczacy znak miał ustawiony najmlodszy bit.

Reasumujac petlę ofsetującą masz bardzo dluga, a RLE jest identyczna. Nie wiem jak ulozy sie srednia, bo jest inna reprezentacja danych, ale chyba na moją korzysc :P

PS.: wydaje mi sie, ze

        asl @
        ror @

jest równoważne

        clc

wiem ze chciales skoczyc jesli najstarszy bit byl ustawiony ale tak sie nie da. (no i dodatkowo skaczac do rle jest ustawiony bit N i bedzie się krecilo troche dluzej :) ) Ale da sie samym lsr @ jesli bedzie sie inadzej pamietalo ten bajt w buforze.

xxl: bądź tak dobry i podaj dane wyjściowe (ciąg bajtów na wyjściu) dla drugiego przykładu, po spakowaniu go twoim sposobem. thx

xxl: Coś mi się nie zgadza, albo nie wszystko zrozumiałem :(

Dane wejściowe były następujące:

_1____________1_
_1____________1_
_1____________1_
_1___3____3___1_
_1_____11_____1_
_1_____44_____1_
_1____________1_
_1___3____3___1_
_1____________1_
_1____________1_
_1____________1_
_1____________1_

Po spakowaniu otrzymałeś  %10,%11011100,%1111,%11011100,%110110,%10110101,%1110110,%10110101,%1001000,%10010001,%1011000,%10100001.

M jest zawsze ustawione, a z analicy danych wychodzi mi, że zawsze robisz plot.
Zakładam, że pierwszy bajt równy zero kończy dekompresję, stad wartość pierwszego bajtu jest zwiększana o 1.
czyli:

%10,        - na poz $1 i +$c
%11011100,    - stawiasz znak 1

%1111,        - na poz $10 i +$c
%11011100,    - stawiasz znak 1

%110110,        - poz $35 i +$5
%10110101,    - stawiasz znak 3

%1110110,    - poz $75 i +$5
%10110101,    - stawiasz znak 3

%1001000,    - na poz $47 i $48
%10010001,    - wpisanie znaku 1

%1011000,    - na poz $57 i $58
%10100001    - wpisanie znaku 4

A co z resztą danych? Poza pierwszym i drugim wierszem brakuje mi jedynek występujących po lewej i prawej stronie...

Dobrze rozumiem ze chodzi o zadanie zadawane kandydatom do pracy informatyka? Czy chodzilo o napisanie takiej gierki? Ciekawy sposob szukania programistow :P

A gierka super!

rewelacja ....

moglbys spakowac i sprawdzic ile bajtow ma

przyklad5:
aaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaa
aaaaabbbbbaaaaaa
aaaabaaaaabaaaaa
aaabaababaabaaaa
aaabacaaacabaada
ddabaacccaabaadd
ddaabaaaaabaaada
daaaababbbaaaada
daaaaaaaaaaaaada
daaaaaaaaaaaadaa

moja metoda tu sie calkowicie wyklada : 34 bajty

i taka mala prosba  :-) czy mozna bezczelnie zapierniczyc Twoja procke do rozpakowania plansz w gierce? oczywiscie wymieniajac Cie na liscie plac ?