Do tej pory myślałem, że .GR8 to po prostu zrzut z pamięci obrazka w trybie 8. Skoro taki obrazek ma 320x192 piksele i jest czarno biały to plik .GR8 powinien mieć dokładnie 7680 bajtów. I faktycznie większość plików .GR8 ma dokładnie taki rozmiar. Napotkałem jednak plik o rozmiarze 7682. Co jest zapisane w ostatnich 2 bajtach? Czy inne rozmiary też są OK?
Chciałbym zrobić konwerter z Atari .GR8 na Commodore 64 .ART i w drugą stronę, ale muszę najpierw wiedzieć czego jeszcze się spodziewać po formacie .GR8.
Zerknąłem w źródła RECOIL ale tam kolory są przypisywane na sztywno (więc pewnie nie jest obsługiwany rozszerzony format). Podejrzewam więc, że dodatkowe dwa bajty to kolejno COLPF1 i COLPF2 przy czym: 1. COLPF1 to kolor piksela zapalonego obliczana tak: (COLPF2 & $F0) | (COLPF1 & $0F) 2. COLPF2 to kolor piksela zgaszonego Najmłodszy bit tak obliczonych bajtów jest zawsze ignorowany (zakładana jest wartość 0). Skoro rozszerzony format ma tylko 2 dodatkowe bajty, to pewnie ramka zawsze jest czarna ($00).
Podejrzewam, że są to wartości komórek "pędzla" - $2c5 (tylko odcień) i tła - $2c6 (odcień + kolor). Trzeba spróbować wstawić te wartości do odpowiednich komórek i zobaczyć, w jakiej kolejności pasują.
Jest tak, ponieważ nie ma czegoś takiego jak standard formatu .GR8. Zwyczajowo programiści zapisują dane obrazu w pliku i czasem dodatkowo dołączają dane rejestrów kolorów. Zazwyczaj więc jest to 7680 albo 7684 bajty. 7682 też może być, zawsze to oszczędność dwóch bajtów, w niektórych projektach nawet bajt ma znaczenie :)
Pierwszy raz widzę 7682-bajtowy GR8. Z jakiego to programu?
Można się spodziewać: - ewentualnego początkowego 6-bajtowego nagłówka DOSowego - 1-240 linii po 40 bajtów (prawie zawsze 192) - że nie wiadomo, czy czarno na białym, czy biało na czarnym
@0xF Nie wiem jaki program to wygenerował. Trzebaby zapytać MotionRide'a albo Lucy. - początkowego nagłówka nie ma - linii jest 192, nie ma paddingów żadnych - to na pewno, bo Recoil otwiera ten plik, ale pokazuje kolory na odwrót. Mój Tom's Editor Desktop nie otwiera, bo plik ma "zły" rozmiar. Po ucięciu ostatnich 2 bajtów mój program otwiera plik poprawnie (jedynie z odwróconymi kolorami)
Plik testowy jest w moim poście na samej górze.
Poza ostatnimi 2 bajtami jest to typowy .GR8 Ostatnie 2 bajty w tym przypadku to: 0x0E 0x00
there are some BBS programs (e.g. Bobterm) that add "redundant" bytes to any program they transfer. Think there are also some converter programs that add additional bytes to gfx (e.g. Waseo converter). Most of the time it does not matter (e.g. ML-files have additional segments like 0000-0000 or something like that; gfx files are a few bytes longer which is often simply ignored), but there are a few programs which refuse to load or display such files then. For files transfered with the BBS programs and redundant bytes, there exist tools like Filefix-2 by CSS (Bob Puff) and Download-Doctor to remove the redundant bytes.
An Atari friend of mine did create a simple TB XL program for me that does remove redundant bytes from Gr. 15 and Gr. 9+11 pics, so they end up with standard 7680 or 7684 Bytes and not a single byte longer...
However I am wondering, Gr. 8 is normally black+white (grey in two lum.), but one could also use e.g. dark-green and light green (green in two lum.) - is there a register somewhere, where one can definitely set the wanted colour for Gr. 8 ? Think I have also seen several Gr. 9 pics that did not use standard 16 greys, but 16 blue or 16 red tones instead, so there must be some register to set this... (not every program checks this register it seems, some simply display standard b/w for Gr. 8 and 16 greys for Gr. 9)...
Obrazki o rozmiarze 7682 bajtów pochodzą z programu Atari Graphics Studio (AGS).
Bajt przedostatni zawiera kolor "pędzla". Najmniej znaczące 4 bity tego bajta definiują ten kolor. Kolejne 4 bity są najwyraźniej ignorowane.
Czyli jeżeli ten bajt ma wartość 0x08 albo 0x18 albo 0xF8 to znaczy, że kolor pędzla to 0x8, a więc #9D9D9D. Jeżeli jest to 0xE to pędzel ma kolor #F1F1F1. Oczywiście możliwe są tylko ocienie szarości (w końcu tryb 8).
Bajt ostatni zawiera kolor tła. Znowu tylko pierwsze (najmniej znaczące) 4 bity są używane.
Przedostatni bajt zawiera jasność tła w młodszym nibble. Ostatni bajt zawiera jasność pędzla w młodszym nibble i kolor całego obrazka w starszym. To nie po atarowemu.
Obrazek nie musi być czarno-biały, może być np. w dwóch odcieniach zielonego. Jest jednak problem: AGS pokazuje kolor zapisany w ostatnim bajcie, ale wyeksportowany XEX wyświetla kolor zapisany w przedostatnim bajcie. Wygląda na błąd w AGS. TeBe?
