Dobra... Ale ładniej jest w zmniejszonym okienku na forum, gdzie dithering jest akceptowalny. Czy na real ATARI gdzie piksele ditheringu to jakieś wielkie kropy.
Dajcie XEXy to zobaczymy na real ATARI jak to w zasadzie wygląda. :)
@Tebe zwrócił uwagę na ciekawą cechę algorytmu. FWA wyglądają całkiem dobrze. No ale te obrazki nie mają "falujących gradientów". Kontur, płaszczyzna, kolor i czuć retro.
Pojawila sie nowa wersja beta z poprawiona paleta altirra 128kolorowa i opcja konwersji do 4kolorow. Niestety G2F dalej nie poprawnie rozpoznaje kolory wynikowych PNG. Mimo ze wybiera sie mu palete Altirra, czesci kolorów w obrazkach nawet 4colorowych nie widzi... Jest wielka prosba do autorów G2F zeby ustalili czego to przyczyna. Zalaczam przykladowy obrazek
Hmm, albo ja tu czegos nie zrozumialem albo cos rzeczywiscie zle dziala w bmp2mic2. W zalaczniku jest zrodlo w postaci png obrazka i jego 5 kolorowej palety zmienianej co linie, jak i plik wynikowy. W tej palecie kolor tla jest czarny przez dlugi okres czasu czyli plik col powinien sie zaczynac od 00 i co 5 bajtow przez dlugi czas byc 00, a juz w drugiej linii zmienia sie na 26
Jak rozumiem twoj program radzi sobie takze z 5kolorami. Rozumiem ze przez restrykcje moge wystepowac jakies bledy w 4 i 5 kolorze, ale nie jesli chodzi o kolor tla???!!!!!! Na moj gust program zle odczytuje kolory.
program najlepiej działa dla 4 kolorów, plik z paletą musi mieć wtedy szerokość 4 pikseli, oraz wszystkie pliki PNG muszą być !!! 8bit per pixel !!!, inaczej będzie źle odczytywał kolory
dla 5 kolorów przestawia paletę wybierając tak aby najmniej "glitchy" było, więc paleta możę być przestawiana co linię
ok, rzeczywiscie w przypadku 4kolorow to byl problem. Standardowo ham_convert robi 24bitowe PNG i konwersja ich na indeksowe zalatwila problem. Natomiast jesli chodzi o 5kolorowe to dalej sobie nie radzi. Mozesz mi powiedziec dlaczego juz w drugiej linijce konwerter pozbywa sie czarnego koloru tla??? Wydaje mi sie ze nadal algorytm potrzebowalby poprawy. Zalaczam pliki testowe
