atarionline.pl G2F: Limitation parameters error - błąd ładowania pliku - 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:
         
        CommentAuthorMaW
      • CommentTime6 May 2022 23:05 zmieniony
       
      Hej, wątek chyba tylko do Tebe - po zapisie do dwóch plików przy próbie ponownego załadowania został mi tylko komunikat "Invalid charset limitation parameters":


      Plik powinien wyglądać tak (XEX ładuje się poprawnie i tylko on mi został nienaruszony - ale nie ma części linii, w których ukryłem elementy, nad którymi pracowałem :(
      Czy coś da się z tym zrobić, oprócz wrzucenia parudziesięciu godzin pracy do kosza?

      Pliki w privie pod postem.
      • 2: CommentAuthor0xF
      • CommentTime7 May 2022 10:05
       
      Wstawiłeś screeny? Nie widzimy ich.
      W jakim formacie są pliki? RECOIL je otwiera?

      BTW. Google Docs też ma tego rodzaju problem: ->link<-
      • 3:
         
        CommentAuthorMaW
      • CommentTime7 May 2022 11:05 zmieniony
       
      Niestety, mam błąd "decoding error" nawet na tych plikach, które G2F otwiera :(

      Format uszkodzony: *.g2f - niestety skompresowany. No i *.xex - wyświetlający się, ale ma część linii niewidoczną - więc nie wiem, czy G2F wszystko w nich wyeksportował.

      Dzięki za tip o RECOIL!!! Plugin do XnView już zainstalowany ^^.

      Pliki dostępne na priv.
      • 4: CommentAuthor0xF
      • CommentTime7 May 2022 16:05
       
      Montezuma w hiresie?

      Odzyskany plik poszedł na priv.

      Nagłówek mówi o 3 fontach, z czego trzeci jest oznaczony w ostatnich czterech liniach. Natomiast zapisane są dwa fonty. Cztery ostatnie linie wyglądają dobrze z drugim fontem.

      TeBe, prosimy o poprawkę Graph2Fonta. :)
      • 5: CommentAuthor0xF
      • CommentTime7 May 2022 16:05
       
      Niestety, mam błąd "decoding error" nawet na tych plikach, które G2F otwiera :(

      Podeślij te pliki.
      • 6:
         
        CommentAuthorMaW
      • CommentTime7 May 2022 18:05 zmieniony
       
      YAY!!! DZIĘKI!!! Cieszę się jak dziecko! Otwiera się :D

      Imho nakryło się tu kilka parametrów: w liniach widocznych (1-25) jest na siłę upchnięty jeden zestaw znaków, w linii 0 i od linii 26 była ustawiona widoczność 0 ("Pixel = 0") i wymuszony drugi zestaw znaków.
      • 7: CommentAuthor0xF
      • CommentTime8 May 2022 07:05
       
      Dzięki za pliki!

      map_Y02_X11_k2.g2f
      - to jest uszkodzony plik, który najpierw wysłałeś

      map_Y02_X11_2k-.g2f
      - jak w pierwszym pliku: oznaczone trzy fonty w nagłówku, plik zawiera dwa.

      map_Y02_X11_k22.g2f
      - pod offsetem 0x29f63 w pliku instrukcja rastra 4. Nie wiem, co znaczy?

      map_Y02_X11_XXX.g2f
      - pod offsetem 0x24f6d w pliku instrukcja STA. Wygląda poprawnie, ale oznacza, że użyty został program rastra, którego RECOIL jeszcze nie obsługuje. Zamiast wyświetlać plik potencjalnie niepoprawnie, zgłasza więc błąd.
      • 8:
         
        CommentAuthorMaW
      • CommentTime8 May 2022 12:05
       

      0xf:

      map_Y02_X11_k22.g2f
      - pod offsetem 0x29f63 w pliku instrukcja rastra 4. Nie wiem, co znaczy?

      A, to zapewne modyfikacja tego pliku: ->link<- z tego wątku G2F a duszki na całą szerokość ekranu? ~ nie martw się, G2F też tego nie wyświetla ^v^
      • 9:
         
        CommentAuthorMaW
      • CommentTime7 Jun 2022 15:06 zmieniony
       
      No i mam następny plik, który się podobnie wypie*ścił...

      @Fox: który bajt zmieniałeś w pliku, żeby "wskoczył" prawidłowo?

      //EDIT: dołączam "przeliczarkę" formatu na bajty - czy ktoś mógłby sprawdzić, czy się gdzieś nie pomyliłem?
      • 10:
         
        CommentAuthorMaW
      • CommentTime7 Jun 2022 22:06
       
      Ok, udało mi się odzyskać zmieniając bajty:
      bajt $0002 ustawiłem na $81
      bajty $0cb3 do $0cb dekrementowałem o 1

      Plik odzyskany! ajm so prałd łof majself
      • 11:
         
        CommentAuthorMaW
      • CommentTime7 Jun 2022 23:06
       
      Gdyby ktoś był chętny (Tebe, Fox), mam feralny plik w n-wersjach, który x-razy próbowałem zapisać z "poprawnej" kopii i G2F nie był go w stanie załadować z powrotem.
      • 12:
         
        CommentAuthorMaW
      • CommentTime9 Jun 2022 15:06
       

      Tebe,DiscussionID=6554#Comment_158888:

      podaj proszę sprawny plik i przepis jak go "zepsuć", użyj żółtej kaczuszki

      Pliki masz w załączeniu. Gdybym wiedział, jak go zepsuć, to bym tego sposobu unikał :P

      Wg moich podejrzeń:
      1. Wymusiłem nowy zestaw znaków (_01_) pośrodku ekranu na 3 linie
      2. W czwartej (pierwszej po wymuszeniu _01_) wymusiłem _00_
      3. Po kilku liniach z _00_ G2F sam utworzył _02_ - jak rozumiem, brakło miejsca na znaki w zestawie _00_
      4. Zoptymalizowałem do mniejszej ilości znaków linie pomiędzy zestawem _01_ a _02_
      5. Usunąłem wymuszony zestaw _01_, _02_ - nie zniknął
      6. W liniach zestawu _02_ wymusiłem _01_
      7. _01_ (nadany automatycznie przez G2F) pojawił się także we wcześniej wymuszonych liniach pomimo tego, że znaków zestawu _00_ było mniej niż 60, a limitation ustawione na 0..128
      8. Zapis do pliku był nieodczytywalny

      Następnie już w naprawionym pliku (podgląd dostępny przez RECOILa) usunąłem całą grafikę, zostawiając tylko duszki - G2F zaczął numerować zestawy znaków od _01_ automatycznie! Plik z takim numerowaniem zestawów w linii już się nie czytał - ALE! Jak wymusiłem ręcznie _00_ w pierwszej linii, to taki plik już bezproblemowo się zaczytywał. Niestety, załadowanie tej samej grafiki (zapisanej wcześniej do bitmapy) do tego pliku też już zabijało zapis.
      • 13:
         
        CommentAuthorMaW
      • CommentTime9 Jun 2022 15:06 zmieniony
       
      Pikanterii dodaje fakt, że zapis z odzyskanego pliku raz się zapisywał poprawnie, a raz się wykrzaczał - tak jakby zmiana jednego piksela psuła plik.
      • 14: CommentAuthortebe
      • CommentTime9 Jun 2022 17:06
       
      zmiana 1 piksela może wpływać na kompresję
      • 15:
         
        CommentAuthorMaW
      • CommentTime9 Jun 2022 21:06 zmieniony
       
      Nie używam kompresji do zapisu plików - tylko dlatego udało mi się namierzyć miejsca, dzięki którym odzyskałem dane z tego feralnego pliku. I plik działający, i nie działający, mają tą samą wielkość 315 863 bajtów.
      Gdy pojawił się nowy zestaw znaków w pliku, plik zwiększył się odpowiednio do 316 887 bajtów. Z punktu założeń formatu wszystko wygląda prawidłowo.