Jesli jakiemus uzytkownikowi Samanty opatrzyl sie juz obrazek startowy, to przygodotalem dwa zamienniki:
- taki prosty w klimacie anime nie zwiazany z tematem (bootimage1)
- nawiazujacy do tematu OS4 (bootimage2) - posklejalem kilka obrazkow znalezionych w googlu

Wyszly jak wyszly bo wyjsc inaczej nie mogly (sa pewne ograniczenia co do obrazka, a moje umiejetnosci pixelizacji grafy nie sa pierwszych lotow).

Jak zastosowac:
1. W katalogu SYS:Kickstart odnajdujemy plik bootimage.
2. Zmieniamy mu nazwe na inna (tak na wszelki wypadek)
3. Przegrywamy z archiwum wybrany plik
4. Zmieniamy nazwe na bootimage
5. Robimy zimny reset.

Endzoj.

http://blabla.ppa.pl/ftp/usr/Phibrizzo/bi.lha

Ooo, fajne. A możesz napisać coś więcej na temat przygotowania obrazków bootimage? Gdyby ktoś np. chciał zrobić własny?

Stowrzenie wlasnego obrazka nie jest takie trywialne niestety.
Aby zrozumiec dlaczego musialbym przedstawic sposob w jaki zostal umieszczony w pliku bootimage.

Informacje na temat tego pliku jakie posiadam nie powstaly w sposob jego dekompilcaji, lecz poprostu na analizie
wnetrza pliku zwyklym hexedytorem. A zmiana obrazka to zwykle podmienienie danych w odpowienim miejscu.

Ale od poczatku.
1. Plik bootimage to jakby biblioteka podobna do tej ktora byla w pakiecie CGX dzieki ktorej przy stacie systemu
pojawial sie ladny teczowy napis "CyberGraphiX".
2. Obrazek ma parametry 640x480 w 8 bitach.

I tu zaczynaka sie schody: jak latwo policzyc aby zapisac taki obrazek trzeba 307200 bajtow a plik bootimage to
tylko 138988. Czyli wniosek jest oczywisty: dane obrazka sa spakowane. Dlugosc danych oryginalnego obrazka
(ktory wyslalem do galerii) po spakowaniu wynosi tylko 69741. Czyli prawie 1:4.5 co nie jest wartoscia mala.

Jednak algorytm kompresji jest bardzo prosty i szybko rozpoznawalny. Zastosowano tutaj N-ta odmiane algorytmu RLE.

Napisalem wiec wlasny algorytm kompresujacy ta metoda. Przy probach okazalo sie jednak ze SAM buntowala sie
przy wyswietlaniu niektorych obrazkow wyswietlajac jakas sieczke. Dlatego nie jestem na 100% pewny czy oryginalna
metoda kompresuje kazda linie z osobna czy nie. Moj algorytm kompresuje calosciowo i byc moze tu jest problem,
bo okazalo sie po kompresji dostalem jeszcze krotszy plik z danym obrazka. Jednak da sie to obejsc odpowienio
preparujac obrazek aby byl kompresowany linia po linii (co oczywiscie nie jest to zadnym rozwiazaniem bo poprawniej
jest zmodyfikowac procedure kompresujaca).

Tak czy siak jest inny problem.
Dajmy na to ze mamy swoj extra obrazek ktory chcemi miec jako startowy. Kompresujemy i.... okazuje sie ze ma ponad
np 200kB. No i lipa... I co teraz? Niestety niewiele da sie zrobic. Zostaje nam tylko tak manipulowac obrazkiem zeby
piksele lezace obok siebie w linii jak najczesciej sie powtarzaly. Czyli mozna sobie odrazu wybic z glowy gradienty typu F-S.
Jesli juz musimy dawac rozne piksele (a tak zazwyczaj jest) to trzeba zminimalizowac takie fragmenty do minimum.
suma sumarum obrazek po kompresji nie moze wyjsc poza 69741 bajta (moze byc mniej).

Jest jednak mala szansa aby powiekszyc ten rozmiar. Jesli ktos sie przyjzy dokladnie plikowi bootimage to okaze sie ze
polowa tego pliku to same zera. Znalazlem pewnien offset w ktorym moze byc zapisana informacja na temat. od ktorego
offsetu znajduja sie w pliku dane graficzne i mozna by bylo powiekszyc ten obszar kosztem pustego miejsca w pliku.

Nie bede tu rozpisywal sie na temat dokladnej budowy struktury danych graficznych bo to pewnie malo kogo interesuje.
Jesli tak to na priva opisze co dokladnie znalazlem. Bo nic nie napisalem np o tablicy kolorow.