Niezalogowany (Zaloguj się)

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.

G2F: Limitation parameters error - błąd ładowania pliku

Od 1 do 15 z 15

- 1:
  
  CommentAuthorMaW
- CommentTime6 May 2022 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.
- itkilledme.2.PNG
- 2: CommentAuthor0xF
- CommentTime7 May 2022
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 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
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
Niestety, mam błąd "decoding error" nawet na tych plikach, które G2F otwiera :(

Podeślij te pliki.
- 6:
  
  CommentAuthorMaW
- CommentTime7 May 2022 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
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
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 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?
- G2F_format_analysis.txt
- 10:
  
  CommentAuthorMaW
- CommentTime7 Jun 2022
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
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
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 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.
- tyle_prob_ile_wariatow.png
- 14: CommentAuthortebe
- CommentTime9 Jun 2022
zmiana 1 piksela może wpływać na kompresję
- 15:
  
  CommentAuthorMaW
- CommentTime9 Jun 2022 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.

Od 1 do 15 z 15