atarionline.pl Pliki w formacie .GR8 - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1: CommentAuthorTheTom
    • CommentTime3 Dec 2018
     
    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?

    Plik 7682 bajtów, autor MotionRide
    ->link<-

    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.
    • 2: CommentAuthormono
    • CommentTime3 Dec 2018 zmieniony
     
    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).
    • 3:
       
      CommentAuthormiker
    • CommentTime3 Dec 2018
     
    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ą.
    • 4:
       
      CommentAuthormiker
    • CommentTime3 Dec 2018
     
    O, no właśnie, mono mnie ubiegł. Dzięki! :)
    • 5: CommentAuthorTheTom
    • CommentTime3 Dec 2018
     
    @mono
    Dzięki! Zaprogramuję tak i zobaczę czy daje to dobre wyniki. W Recoilu ten obrazek z linka ma odwrócone kolory.
    • 6:
       
      CommentAuthorKaz
    • CommentTime4 Dec 2018
     
    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 :)
    • 7: CommentAuthortebe
    • CommentTime4 Dec 2018
     
    równie dobrze plik .MIC może przechowywać .GR8

    G2F w plikach .MIC zapisuje 240 linii, obraz wąski 32*240+4, 40*240+4, 48*240+4

    rozpoznanie szerokości obrazu dokonywane jest na podstawie długości pliku
    • 8: CommentAuthor0xF
    • CommentTime4 Dec 2018
     
    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
    • 9: CommentAuthorTheTom
    • CommentTime4 Dec 2018 zmieniony
     
    @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
  1.  
    Well,

    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)...
    • 11: CommentAuthorTheTom
    • CommentTime11 Feb 2019
     
    Małe podsumowanie.

    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.
    • 12: CommentAuthor0xF
    • CommentTime12 Feb 2019 zmieniony
     
    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.
    • 13: CommentAuthor0xF
    • CommentTime12 Feb 2019
     
    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?
    • 14: CommentAuthortebe
    • CommentTime12 Feb 2019
     
    sprawdzę, o jeden bajt tyle szumu ;)
    • 15: CommentAuthor0xF
    • CommentTime19 Feb 2019
     
    tebe rozwiązał usuwając kolory w GR8 w AGS 3.4.9. :)
    • 16: CommentAuthorTheTom
    • CommentTime24 Feb 2019
     
    Dzięki za informację, 0xF. No, to teraz wszystko pasuje!