atarionline.pl Informacje o Graph2Font (G2F) - 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:
       
      CommentAuthorKaz
    • CommentTime9 May 2008
     
    Oczywiscie najbardziej podstawowe i konieczne informacje sa na oficjalnej stronie programu Graph2Font:
    1. Strona glowna:
    ->link<-
    2. Instrukcja po polsku (zawsze swiezsza niz angielska):
    ->link<-
    3. Instrukcja po angielsku (troszke zdezaktualizowana):
    ->link<-
    4. Galeria uzbierana przez Tebego:
    ->link<-

    Jest tez linka zaczerpnieta ze stopki w programie. Prowadzi do dlugiego watku na forum Atari Age:
    ->link<-
    Sa tam tez inne:
    ->link<-
    ->link<-
    ->link<-
    ->link<-
    ->link<-

    Generalnie Atari Age to dobre miejsce do dyskusji o G2F, jest kilku zaawansowanych uzytkownikow z roznych krajow. Glownie udzielaja sie na tych podforum:
    ->link<-
    ->link<-
    ->link<-

    Ponizej prosze tylko dolaczac inne informacje (linki, cytaty) na temat programu G2F.
    • 2:
       
      CommentAuthorKaz
    • CommentTime30 Jan 2010
     
    A przed chwila TeBe podeslal info o nowej wersji:

    "v3.8.8.4
    - nowy tryb DLI+ z wierszami wysokości 4 linii (Special -> Mode -> DLI+)
    - CHARS LIMIT zastąpiony został przez Special -> Charset limitations,
    można ustawić pierwszy i ostatni znak zestawu znaków
    - poprawiony i przyspieszony kod przerwania DLI generowanego dla trybów
    DLI i DLI+ kosztem jego długości
    - poprawiony kod generowany dla grafik z ostatnim wierszem w trybie
    HiRes, teraz nie będą one zrywać synchronizacji
    - kółko myszki pod zoomem zmienia teraz skalę powiększenia
    - poprawiony odczyt plików *.ACT palety kolorów, poprzednio trzeba było
    potwierdzić wybór palety z każdym nowym uruchomieniem g2f
    - poprawione liczenie kolorów SHIFT+I (Info), poprzednio potrafił
    pomylić się o 1
    - poprawki w działaniu opcji CHECK (CTRL+C)
    - rozbudowana obsługa plików MCH (pamięć obrazu zapisana jako znaki +
    informacja o inwersie znaków + informacja o kolorach co linię)"

    Program oczywiscie na stronie g2f.atari8.info
    • 3:
       
      CommentAuthorKaz
    • CommentTime30 Jan 2010
     
    Dracon, to miedzy innymi dla Ciebie :)

    "- kółko myszki pod zoomem zmienia teraz skalę powiększenia"
    • 4:
       
      CommentAuthorDracon
    • CommentTime30 Jan 2010
     
    :D
    Lepiej pozno niz wcale... ;)
    Moze jeszcze kiedys popiksluje, zobaczymy...
    • 5: CommentAuthorpavros
    • CommentTime30 Jan 2010
     
    Pytanie do TeBe: Co oznacza "wiersz wysokosci 4 linii"? Czy chodzi o wiersz trybu tekstowego, gdzie przy pomocy jakiegos tricku jego wysokosc jest zmniejszona z 8 do 4 linii obrazu?
    • 6: CommentAuthortebe
    • CommentTime30 Jan 2010 zmieniony
     
    Fox pisał o tym w Atarynce

    ->link<-

    w trybie DLI+ ekran ma 60 wierszy wysokości, pamięć obrazu 2x większa w porównaniu ze standardowymi 30 wierszami jeśli chcemy wykorzystać "ciaśniejszy" inwers znaków, używając LMS można zejść do tego samego zużycia pamięci jak standardowe 30 wierszy, jednak nie będzie "ciaśniejszego" inwersu znaków
    • 7:
       
      CommentAuthorKaz
    • CommentTime5 Apr 2010
     
    TeBe, link do strony MadTeamu nie dziala. Bedzie dzialal?
    • 8:
       
      CommentAuthormiker
    • CommentTime5 Apr 2010
     
    Aktualnie wszystko, co na *.atari8.info nie działa, jest problem z serwerem. Jak naprawią, wszystko powinno być jak dawniej.
    • 9:
       
      CommentAuthorKaz
    • CommentTime18 Mar 2011
     
    Tebe, cos sie popsulo w najnowszym G2F (06.03.2011) jezeli chodzi o podswietlanie duszkow (wlaczona opcja flashing). Pokazuje mi duszki w jakis zupelnie przypadkowych miejscach, a nie tam, gdzie w rzeczywistosci sa.
    • 10:
       
      CommentAuthorjhusak
    • CommentTime19 Mar 2011
     
    Nie działa pod wine :(
    • 11: CommentAuthortebe
    • CommentTime16 Sep 2011 zmieniony
     
    parę uwag dotyczących zapisywania do XEX

    w nazwie ścieżki nie używać polskich znaków z ogonkami, mads wygeneruje wówczas komunikat

    ERROR: Cannot open or create file 'D:/Gry/Atari/--( G2F )--/Moje rysunki/nieukończone/Cursed WIP/plik.asm'

    mads zawsze załączony jest do pliku G2F.EXE, więc nie potrzeba dodatkowych ścieżek dostępu etc.

    mads.exe i inne pliki zostają zapisane do katalogu (Windows 7)

    C:\Users\tebe\AppData\Local\Graph2Font\Undo\

    gdzie 'tebe' to nazwa aktualnego użytkownika

    plik go$$$.bat to plik który realizował wywołanie mads-a, można uruchomić go z konsoli i podejrzeć efekt działania, pod warunkiem że plik ASM jeszcze istnieje na dysku

    p.s.
    problem stanowi strona kodowa podczas uruchamiania konsoli w tle, zmiana strony kodowej na 1250 rozwiązuje problem polskich literek, jednak nie mam pewności co ta zmiana uczyni na innych komputerach spoza Polski

    wniosek: w nazwach katalogów NIE UŻYWAĆ POLSKICH ZNAKÓW
    • 12: CommentAuthortebe
    • CommentTime18 Sep 2011
     
    nowa wersja 3.9.2.7 na ->link<-
    • 13:
       
      CommentAuthorlarek
    • CommentTime18 Sep 2011
     
    Dziękujemy :)
    • 14: CommentAuthortebe
    • CommentTime19 Sep 2011 zmieniony
     
    odnalazłem przyczynę problemów z XEX-em, aktualna wersja G2F też nie powinna zapisać XEX-a, dlaczego ?

    bo szukając rozwiązania problemu zmieniłem katalog roboczy G2F na nowy [USER]/Application data a to oznacza nowy czysty plik INI

    w zakładce Special -> DLI -> Fade effect musi być zaznaczony, a G2F domyślnie go nie ustawia

    podobnie z opcją ASM -> RUN | INI

    brak tej opcji spowoduje braki kodu w pliku ASM a w efekcie niepowodzenie asemblacji

    zawsze gdy plik XEX nie zostanie zapisany powinno istnieć podejrzenie o błędzie w ASM, wystarczy zapisać sam plik ASM i dokonać asemblacji ręcznie mads-em, wtedy przekonamy się jakie błędy występują

    problem z zapisem XEX wystąpi zawsze gdy uruchomimy G2F na nowym komputerze czy nowym użytkowniku, wówczas bowiem plik INI nie zawiera odpowiedniej konfiguracji

    starsze wersje G2F zapisują XEX bo nie dysponują zakładką SPECIAL, albo opcją Fade effect, albo korzystają z innej lokalizacji z której odczytują plik INI

    G2F wymaga poprawki, tak aby opcje SPECIAL ustawiał w przypadku ich braku domyślnie
    • 15:
       
      CommentAuthorlarek
    • CommentTime19 Sep 2011
     

    tebe:

    w zakładce Special -> DLI -> Fade effect musi być zaznaczony, a G2F domyślnie go nie ustawia


    Ano właśnie, a jak nie chcemy żadnego efektu?
    • 16: CommentAuthortebe
    • CommentTime19 Sep 2011 zmieniony
     
    to nie będzie pliku XEX

    ogólnie wybór możliwy na tak/nie jest tylko dla CHECKBOX-ów, tam gdzie są RADIOBUTTON-y musi być zawsze jedna z opcji zaznaczona, nie ma możliwości rezygnacji
    • 17: CommentAuthorlhuven
    • CommentTime19 Sep 2011
     
    Teraz (3.9.2.8) działa jak złoto :)
    • 18:
       
      CommentAuthorlarek
    • CommentTime19 Sep 2011
     

    tebe:

    tam gdzie są RADIOBUTTON-y musi być zawsze jedna z opcji zaznaczona, nie ma możliwości rezygnacji

    To trzeba to w programie zmienić i wtedy będzie możliwość. W poprzednich wersjach można było wygenerować xex'a, w którym obraz pojawiał się bez żadnej zwłoki na ekranie, a teraz musi być włączony efekt rozjaśniania... To żadne udogodnienie. Zamiast możliwości wyboru jesteśmy skazani na niechciany efekt... :(
    • 19: CommentAuthortebe
    • CommentTime20 Sep 2011
     
    ten temat był wałkowany setki razy, nie będzie efektu fade dla DLI jeśli w pierwszych 8 liniach występują jakieś zmiany, w pozostałych przypadkach będzie efekt fade
    • 20:
       
      CommentAuthorlarek
    • CommentTime20 Sep 2011
     
    I nic nie da się zorbić, żeby była możliwość wyłączenia tego efektu w normalny sposób a nie przez kombinowanie ze zmianami w pierwszych liniach obrazka? Tebe, przecież to kosmetyczna zmiana w programie, którą zrobisz w pięć minut...
    • 21: CommentAuthormarok
    • CommentTime20 Sep 2011
     
    Jeśli się nie mylę, to można stosunkowo łatwo wygenerować xex bez efektu fade w ten sposób że z poziomu g2f generujemy asm, a w nim wszystkie odwołania do podprocedur fade remujemy i tak asemblujemy.
    • 22:
       
      CommentAuthorDracon
    • CommentTime20 Sep 2011
     
    Z "renamowaniem" moze i byloby skuteczne, ale dla kogos, kogo nie pociaga asembler, wydawac sie moze zbyt nieporeczne - szczegolnie jesli np. ma pare obrazkow. :)
    • 23: CommentAuthorQTZ
    • CommentTime6 Dec 2011 zmieniony
     
    W wersji 3.9.2.9 gdy rysuję "pod lupą" w dwukolorowym trybie (często zmieniam kolor - tab) po pewnym czasie występuje błąd: "Stream write error." i nic nie pomaga - muszę zapisać obrazek i zrestartować G2F.
    Przeszedłem na starszą wersję 3.9.0.6 i w niej problem nie występuje.

    Jest problem z wczytaniem pary fnt/scr.

    Nie ma możliwości wyłączenia automatu sortującego znaki, usuwającego niewidoczne i duplikaty.

    Inna sprawa - nie można zminimalizować okna głównego zostawiając tylko "lupę" - to jest trochę niewygodne, gdy przerysowuję grafikę ze skanu, który mam otwarty w zewnętrznym programie - teraz można tylko np. przesunąć główne okno za ekran.
    • 24:
       
      CommentAuthorDracon
    • CommentTime7 Dec 2011 zmieniony
     
    @QTZ
    Wnikliwy raport, a jak chcesz miec wieksza gwarancje, iz autor programu na pewno sie z tym zapozna, to skontaktuj sie z nim via e-mail (kontakt z nim: ->link<- - pierwszy adres od góry).
    • 25:
       
      CommentAuthorKaz
    • CommentTime9 Apr 2012
     
    No wiec tak. Dotyczy to wersji 3.9.5.5:

    a) przygotowuje obrazek 9-kolorowy (4 bity, ale wykorzystane tylko pierwszych 9 kolorow) dla GR10: 320x240:



    b) wczytuje, ustawiam opcje Resize - juz tu widac, ze wszystko jest nieprawidlowo wczytane:



    c) w takim razie wlaczam Greyscale, ktore daje bardziej prawidlowa konwersje:



    d) i ustawiam sobie kolorki w rejestrach recznie, skoro nie da sie automatem:



    e) ale pod G2F widze to tak jak powyzej, a po wygenerowaniu XEX widze to tak:



    Wszystkie pliki, w tym G2F, w zalaczniku.
    • 26:
       
      CommentAuthorKaz
    • CommentTime9 Apr 2012
     
    Wyglada to tak, jakby cos bylo namieszane z rejestrami, z ich przyporzadkowaniem w niektorych opcjach (konwersji obrazka oraz edycji kolorow).
    • 27: CommentAuthortebe
    • CommentTime10 Apr 2012
     
    umieściłem poprawioną wersję g2f w wiadomym miejscu
    • 28:
       
      CommentAuthorKaz
    • CommentTime10 Apr 2012
     
    Dziekuje! A co bylo przyczyna?
    • 29: CommentAuthortebe
    • CommentTime11 Apr 2012
     
    przyczyną była interpretacja kolorów przez G2F spoza zakresu 0..8 jako kolor #0, GTIA takie kolory interpretuje w odpowiedni dla siebie sposób

    dodałem obsługę takich przypadków i jest OK, dodatkowo poprawiłem import bitmap, tak aby były trafniej interpretowane dla trybu GR10
    • 30: CommentAuthorilmenit
    • CommentTime11 Apr 2012
     
    W G2F jest przydatna dla programistow opcja wlaczenia LMS w kazdej linii. W trybie GED-- jest blad i jedna z linii jest niewlasciwie wyswietlana, w dolnej polowie ekranu. Mozna to sprawdzic rysujac pionowe paski na ekranie i generujac XEX. Wyglada na przekroczenie granicy 1KB w DList.
    • 31:
       
      CommentAuthorKaz
    • CommentTime11 Apr 2012
     
    Tebe - a to mialem dobre przeczucie. W takim razie sciagam i testuje nowsza wersje.
    • 32:
       
      CommentAuthorKaz
    • CommentTime11 Apr 2012 zmieniony
     
    Nie, jeszcze nie jest wszystko w porzadku z trybami GTIA.

    1. W trybach 16G i 16C pojawia sie okienko Edit Colors z piecioma kolorami do edycji, czyli z trybow 2x1.



    2. Jest jeszcze cos nie tak z wczytywaniem obrazka w trybie 9C i przyporzadkowaniem kolorow do rejestrow. Zobacz, ze tak wyglada ten moj obrazek testowy wczytany w trybie 16G (z opcja "Greyscale"), a potem przelaczony na 9C i 16C:







    Ale po wczytaniu do trybu 9C i przelaczeniu na 16C i 16G wyglada juz zupelnie inaczej!








    Mialoby to sens, gdyby moj testowy obrazek mial wiecej niz 9 kolorow. Ale tak... nie wiem, jaka metoda przyporzadkowujesz rejestry Atari do kolorow na obrazku, ale czy nie powinno byc to robione wprost: uzyte kolory przechodza po kolei do rejestrow Atari? Ewentualnie opisz mi, jak to dziala teraz, bo jest to dla mnie niezrozumiale.
    • 33: CommentAuthor0xF
    • CommentTime11 Apr 2012 zmieniony
     
    Ad. 1 W tych trybach ma sens tylko regulacja COLBAK i właśnie to widzę na tym zrzucie ekranu.

    Ad. 2 Na moje oko nie wygląda "zupełnie inaczej" - różni się tylko jasnością, którą steruje COLBAK. Jak rozumiem, przełączenie trybu GTIA nie oznacza konwersji (pikseli i kolorów).
    • 34:
       
      CommentAuthorKaz
    • CommentTime11 Apr 2012
     
    Fox:

    ad.1
    he he, racja. Wydawalo mi sie, ze te pozostale rejestry sa podswietlone, a nie sa :)

    ad.2.
    Tak, w przypadku 16C jest zmiana COLBAK i to widac (drugi obrazek jest jasniejszy niz pierwszy). Ale mnie chodzi o "zupelnie inne" nie w przypadku 16C, ale po zmianie do 9C. Widac to podczas ustawiania pozniejszego ustalania palety w trybie 9C. To wyglada tak, jakby inaczej byla grafika konwertowana z pc. Byc moze po prostu nie rozumiem, jak to dziala - i stad moje powyzsze pytanie.
    • 35: CommentAuthortebe
    • CommentTime12 Apr 2012
     
    v 3.9.5.8

    kolejne poprawki, znalazłem "durny" błąd powodujący błędną interpretację kolorów dla GR10 importowanej bitmapy

    dodatkowo poprawki dla CHECK, optymalizacje (prawy klawisz myszki -> OPTIMIZE PMG/BMP) zostały odblokowane, dodatkowo lepiej ustawia okno listy z aktualnie zaznaczonym elementem

    dla importowanej bitmapy i GR10 niekiedy nie potrafi załadować odpowiednich kolorów, pomaga wówczas zaznaczenie SORT COLORS
    • 36: CommentAuthorGonzo
    • CommentTime12 Apr 2012
     
    kaz - fajny obrazek, nie wiem czy udało ci się go skonwertować, więc puszczam to co mi z tego wyszło :)

    muza - nooly "summer" stereo



    tebe - hmm, z gr. 10 chyba dalej jest coś nie tak (obrazek jest skompilowany z asm'a)
    • 37: CommentAuthortebe
    • CommentTime12 Apr 2012
     
    w mojej ocenie aktualnie wszystko jest OK, jeśli tak nie jest to poproszę dowód w postaci cyfrowej
    • 38: CommentAuthorGonzo
    • CommentTime12 Apr 2012
     
    po ustawieniu gtia 9c i wczytaniu obrazka (z postu 36) wychodzi mi coś takiego (7 kolorów):

    • 39:
       
      CommentAuthorKaz
    • CommentTime12 Apr 2012
     
    Dzieki Tebe za kolejne poprawki. Jednak w tej chwili G2F zawieszam na kolku na jakis czas. Potem oczywiscie znowu wroce do GR10, bo mi sie ten tryb podoba.
    • 40: CommentAuthortebe
    • CommentTime13 Apr 2012
     
    po konwersji do palety Atari, wychodzi mniejsza liczba kolorów
    • 41:
       
      CommentAuthorKaz
    • CommentTime16 Apr 2012
     
    Gonzo - chodzi Ci o to, ze sa inne kolory czy ze jest ich mniej? Bo rzucam okiem i widze, ze raczej kolorow jest tyle samo, tylko sa inne.
    • 42: CommentAuthorilmenit
    • CommentTime30 Oct 2012
     
    Na stronie G2F ukazała się nowa wersja.
    • 43:
       
      CommentAuthorKaz
    • CommentTime22 Nov 2014
     
    Tebe o dzialaniu trybu GED z DISABLED BADLINES, moze sie komus przyda informacja:

    Tebe:

    Sennosc Vidola to przykład interlacu, linie przerywane to linie parzyste/nieparzyste, "bad lines" nie są tam ewidentnie widoczne bo maskują je te przerywane linie które są efektem interlacu, pozostałe błędy na grafice są efektem działania programu, którego nie udało mi się idealnie zsynchronizować, konkretnie moment startu programu zmian rastra (4 dziury na środku drogi)

    w załączniku plik Kaz-a Falcons w trybie GED+ DISABLED BADLINES, taki obrazek nie zajmuje 50 kb tylko 30KB, każdy wiersz obrazka to 1 zestaw znaków czyli 1024 bajty

    nowy G2F zapisuje już informację o trybach dodatkowych DLI+, GED- disabled badlines w pliku G2F, tak że nie będzie trzeba włączać takiego trybu w zakładce Special, od razu się załączy, to z myślą o mniej doświadczonych użytkownikach
    • 44:
       
      CommentAuthorKaz
    • CommentTime26 Nov 2014
     
    Blad raportowany w G2F:
    duży to problem palety, którą źle wczytuje (rozjaśnia ciemne barwy) np. w gr9 najciemniejszy szary na wartość RGB 59,59,59 zamiast 17,17,17.
    • 45:
       
      CommentAuthorKaz
    • CommentTime17 Jun 2015 zmieniony
     
    Istotne informacje od Irwina o tym, ktora czesc ekranu naprawde widac. Informacja z czerwca 2010 roku dotarla do kilku grafikow, ktorzy wtedy tego nie wiedzieli, teraz wiedza, ale przydac sie moze kazdemu, kto rysuje w G2F.

    Małe info dla aktywnych grafików. (...)

    Atari wyświetla obraz o 4 szerokościach:
    - nic czyli 0 cykli koloru czyli 0 pixli, ;)
    - narrow czyli 256 cykli koloru czyli 256/128/64 pixli,
    - normal czyli cykli koloru czyli 320/160/80 pixli,
    i
    - wide czyli cykli koloru czyli 384/192/96 pixli

    I tak np fenomenalne Nibiru Piesia ma pełne 384 pixli. Ale jest pewien feler, otóż tego nikt nie zobaczy. I nie dlatego, że większość TV czy monitorów zwykle pokazują max 42-44 kolumny czyli 336-352 pixli. Gdyż w teorii można znaleźć TV z dużym bocznym overscanem i pokazać to. Więcej: są przecież emulatory i pod nimi można wyświetlić i pokazać całość.
    Pamiętam że jakieś pół roku temu - z okazji mojego obrazka w 176x240 - pisałem o tym z Kazem:
    Irwin: "Przede wszystkim żaden TV czy monitor nie wyświetli więcej niż 176 piksli w linii"
    Kaz: "Wiesz to czy przypuszczasz? Mnie sie zdaje to nieprawda, poniewaz pamietam w starych czasach, ze testowalismy z Zyga szeroki tryb i bylo widac wiecej. Ile? tego nie pamietam, ale wiecej niz po 8 pikseli z kazdej strony napewno"

    Ja wtedy tak po prostu założyłem oglądając screenshoty z realnych TV i monitorów (m.in. podesłane przez Kaza). Nie znalech przyczyn tego, faktów, jedynie przypuszczenie - jak się poniżej okaże słuszne. Otóż prawdziwą przyczyną tego, że nie można nic wyświetlić ponad 88/176/352xXXX jest... same Atari. Mimo, iż tryb "Wide" ma 384 pixli to Atari wyświetla z nich jedynie 352/176/88. Atari w każdej linii wyświetli 228 cykli koloru. Wyświetlany obraz znajduje się w obszarze od 44 do 219 włącznie. Ponieważ każdy cykl koloru odpowiada pixlowi 2x1 mamy więc 176 pixli. Tak więc wiecej niż te 176 nie można wyświetlić.
    Aby to potwierdzić zapytałem się guru grafiki Atari, niejakiego Tebe ;) po co w takim razie w graph2font możliwa jest edycja 384/192/96 zamiast 352/176/88 pixli skoro jedynym miejscem gdzie taki obrazek będzie w całości wyświetlany to ... graph2font. Tebe odpisał, potwierdzając moje odkrycie koła na nowo ;) że co prawda Atari nie wyświetli powyżej 352/176/88 ale w graph2foncie jest możliwość edycji tych dodatkowych kolumn z uwagi na to że graph2font to nie tylko grafika ale i narzędzie dla koderów i mogą być w tych dodatkowych kolumnach np dane dla jakieś klatki animacji, czy dane do scrolla, itd.
    Kolejnym potwierdzeniem jest emulator Altirra który w trybie pokazywania pełnego obrazu Atari tj 228 cykli czyli 456x312 (więcej już się nie da) wyświetla dane graficzne na obszarze od 44 do 219 cykli. Pokazuje to screenshot z Nibiru - macie w zal. Można porównać obrazki i okaże się że ma on 176x240.
    Także tutaj jest o tym:
    ->link<-

    Po co to pisze? Otoż ja dopiero ostatnio do tego doszedłem drążąc temat cykli cpu i cykli koloru w linii (bo jest mi to potrzebne ;) - zakładam, może niesłusznie że i inni o tym nie wiedzą. Pokazuje to np nasza dyskusja z Kazem. Pokazują to obrazki np Fly'a czy Allas'a a także innych którzy rysują czasami ważne elementy obrazka (patrzcie zamek Allasa) na obszarze które Atari nigdy nie wyświetli. Być może i Piesiu też o tym nie wie/wiedział - vide Nibiru.
    • 46: CommentAuthorQTZ
    • CommentTime13 Mar 2016 zmieniony
     
    Bug: Gdy otworzę plik png i zamknę to zostaje on zamieniony na bitmapę (v.3.9.9.3). Generalnie coś dziwnego się dzieje - na niektórych obrazkach pojawiały mi się jakieś linie, być może to jakaś nowa optymalizacja, ale nie udało mi się tego wyłączyć i wróciłem do starszej wersji.
    • 47: CommentAuthortebe
    • CommentTime13 Mar 2016
     
    wrzuciłem nowszą wersję z 03.09.2015 (v4.0.1.3)
    ->link<-
    • 48: CommentAuthorQTZ
    • CommentTime13 Mar 2016
     
    Dzięki :)

    W nowej wersji źródłowy plik png pozostał bez zmian. Co do niechcianych poziomych linii to chyba też jest dobrze (na pliku który sprawdziłem się nie pojawiły, ale musiałbym sprawdzić inne, bo w poprzedniej wersji linie nie zawsze się pojawiały).
  1.  
    :)
    • 50: CommentAuthorGonzo
    • CommentTime1 Apr 2016 zmieniony
     
    tebe - czy dało by się dołożyć edytor map w G2F na takiej zasadzie, że .......