01.04.2022 16:35
[#1]
GrafX 2.8 crash
Gdy uruchamiam GrafX 2.8 albo 2.7 to zawsze gdy użyję przycisku Load albo Save (albo F2, F3) to program się wiesza. Tak jakby problemem była próba otwarcia tego jego filerequestera.
Kontaktowałem się z autorem portu i okazuje się, że u niego się nie wiesza. Zbudował nawet dla mnie najnowszą wersję 2.8 przy użyciu najnowszego MOS SDK. Niestety ciągle to samo. A pamiętam, że kiedyś działał.
Próbowałem wykumać z czego jeszcze program korzysta, od czego zależy, co ładuje. Ale nie wyczaiłem niczego dziwnego.
Mam najnowsze SDL 2, MorphOS 3.16 na PowerBooku G4 1,67GHz.
Czy ktoś mógłby sprawdzić czy GrafX2 (z MorphOS Storage) też się wiesza po użyciu Load albo Save?
Kontaktowałem się z autorem portu i okazuje się, że u niego się nie wiesza. Zbudował nawet dla mnie najnowszą wersję 2.8 przy użyciu najnowszego MOS SDK. Niestety ciągle to samo. A pamiętam, że kiedyś działał.
Próbowałem wykumać z czego jeszcze program korzysta, od czego zależy, co ładuje. Ale nie wyczaiłem niczego dziwnego.
Mam najnowsze SDL 2, MorphOS 3.16 na PowerBooku G4 1,67GHz.
Czy ktoś mógłby sprawdzić czy GrafX2 (z MorphOS Storage) też się wiesza po użyciu Load albo Save?
02.04.2022 19:47
[#5]
Re: GrafX 2.8 crash
@Ponki1986, post #3
Dla programisty to jest coś co zdecydowanie powinien mieć włączone. Ale dla użytkownika to jest trochę strzał w kolano. Co zresztą widać po tym przypadku. 
Mając tę opcję ustawioną, gdy jakiś program odwołuje się do pamięci o adresie 0 to pojawia się informacja o tym w debuglogu. Programista pisząc swoje wypociny powinien o tym wiedzieć, bo na pewno jest to błąd w programie i jest to sytuacja niedopuszczalna. Autor powinien poszukać przyczyny takiego odwołania żeby to się nie zdarzało. Można też coś ustawić żeby w takim przypadku program od razu się wywalał.
Sytuacje bywają różne i takie odwołanie może nie być tragiczne w skutkach, program jakimś amigowym cudem przeżyje i się nie wywali. Dla użytkownika jest to sytuacja lepsza, że się nie wywali. Ale ja pod MorphOSem najczęściej coś swojego klepię i mam to włączone na stałe od prawie 10 lat. I prawdę mówiąc zupełnie o tym zapomniałem.
Gdy autor portu morphosowego GrafX2 zobaczył, że to mam ustawione to też sobie ustawił i dzięki temu poprawił błąd w GrafX2. Jak widać przydaje się mieć to ustawione gdy się coś takiego robi.
Niestety starzy programiści amigowi mieli to serdecznie w nosie, bo system amigowy jest niestety bardzo "tolerancyjny", pozwala na wszystko i masa starego softu to straszny śmietnik. Moim zdaniem to frywolne programowanie w czasach świetności Amigi jest powodem tego, że do Amigi przylgnęła łatka, że jest "wiechliwa" i że wszystkiemu winny jest brak ochrony pamięci. A prawdę mówiąc gdyby to wszystko było napisane poprawnie to i bez ochrony pamięci byłoby stabilnie. To jest takie trochę tłumaczenie swojej nieudolności niedostatkami AmigaOS. Pamiętam jak strasznie niestabilne były niektóre klasy MUI na starym amigowym MUI 3.8. Jakoś dzisiaj tego nie ma w MorphOS na MUI 5. Z bardzo niestabilnych bibliotek zrobiły się bardzo stabilne. No ale to jest wynikiem grubo ponad 10 lat pracy mózgowców z MOSTeam. Trzeba było ten cały amigowy śmietnik mocno oczyścić...
Mając tę opcję ustawioną, gdy jakiś program odwołuje się do pamięci o adresie 0 to pojawia się informacja o tym w debuglogu. Programista pisząc swoje wypociny powinien o tym wiedzieć, bo na pewno jest to błąd w programie i jest to sytuacja niedopuszczalna. Autor powinien poszukać przyczyny takiego odwołania żeby to się nie zdarzało. Można też coś ustawić żeby w takim przypadku program od razu się wywalał.
Sytuacje bywają różne i takie odwołanie może nie być tragiczne w skutkach, program jakimś amigowym cudem przeżyje i się nie wywali. Dla użytkownika jest to sytuacja lepsza, że się nie wywali. Ale ja pod MorphOSem najczęściej coś swojego klepię i mam to włączone na stałe od prawie 10 lat. I prawdę mówiąc zupełnie o tym zapomniałem.
Gdy autor portu morphosowego GrafX2 zobaczył, że to mam ustawione to też sobie ustawił i dzięki temu poprawił błąd w GrafX2. Jak widać przydaje się mieć to ustawione gdy się coś takiego robi.
Niestety starzy programiści amigowi mieli to serdecznie w nosie, bo system amigowy jest niestety bardzo "tolerancyjny", pozwala na wszystko i masa starego softu to straszny śmietnik. Moim zdaniem to frywolne programowanie w czasach świetności Amigi jest powodem tego, że do Amigi przylgnęła łatka, że jest "wiechliwa" i że wszystkiemu winny jest brak ochrony pamięci. A prawdę mówiąc gdyby to wszystko było napisane poprawnie to i bez ochrony pamięci byłoby stabilnie.
To jest takie trochę tłumaczenie swojej nieudolności niedostatkami AmigaOS. Pamiętam jak strasznie niestabilne były niektóre klasy MUI na starym amigowym MUI 3.8. Jakoś dzisiaj tego nie ma w MorphOS na MUI 5. Z bardzo niestabilnych bibliotek zrobiły się bardzo stabilne. No ale to jest wynikiem grubo ponad 10 lat pracy mózgowców z MOSTeam. Trzeba było ten cały amigowy śmietnik mocno oczyścić... 02.04.2022 20:30
[#6]
Re: GrafX 2.8 crash
@Ponki1986, post #3
Do powyższych dodam, że pomimo tego, że MorphOS nie ma ochrony pamięci to ma wykrywanie nielegalnych dostępów do wolnej pamięci + własnie do pamięci o adresie 0.
w kodzie Ansi C
char *a = NULL;
*a = 5;
przy włączonym invzeropage wywali błąd do debuglogu bo to nielegalna konstrukcja
Dodatkowo wykrywany (mniej wiecej) dostęp do wolnej pamieci więc jeśli zaalokujemy
char *b = (char *)malloc(10);
i zrobimy
b[20] = 5;
to większosci wypadków dostaniemy czerwony wpis w debuglogu i po paru takich wpisach proces zawisnie i nie bedzie psuł dalej systemu.
Dodatkowo dla programistów dodane także PermMemTrack w opcjach bootowania, które włącza jeszcze bardziej dokładne śledzenie pamięci.
Ostatnia aktualizacja: 02.04.2022 20:31:42 przez michal_zukowski
w kodzie Ansi C
char *a = NULL;
*a = 5;
przy włączonym invzeropage wywali błąd do debuglogu bo to nielegalna konstrukcja
Dodatkowo wykrywany (mniej wiecej) dostęp do wolnej pamieci więc jeśli zaalokujemy
char *b = (char *)malloc(10);
i zrobimy
b[20] = 5;
to większosci wypadków dostaniemy czerwony wpis w debuglogu i po paru takich wpisach proces zawisnie i nie bedzie psuł dalej systemu.
Dodatkowo dla programistów dodane także PermMemTrack w opcjach bootowania, które włącza jeszcze bardziej dokładne śledzenie pamięci.
Ostatnia aktualizacja: 02.04.2022 20:31:42 przez michal_zukowski
02.04.2022 21:05
[#8]
Re: GrafX 2.8 crash
@waldiamiga, post #7
No i bardzo fajnie. To całkiem zgrabny program do robienia retro-grafiki.
Jest jedna śmieszostka w GrafX2. Aż trudno uwierzyć, że taki niedostatek istnieje od wielu lat. I nie chodzi tutaj o wersję dla MorphOS tylko generalnie o GrafX2 dla wszystkich platform. Chodzi o to, że właściwie nie ma tam funkcji odtwarzania animacji.
Można sobie nacisnąć prawy klawisz myszy na przycisku Next w animacji i jakoś się tam odtwarza. Ale trzeba trzymać przycisk i to zupełnie nie bierze pod uwagę czasu trwania każdej klatki. Właściwie podczas rysowania nie ma to wielkiego znaczenia i mnogość innych funkcji rekompensuje ten niedostatek. Podczas rysowania animacji ważne jest łatwe, szybkie przeskakiwanie między klatkami, a otworzy się później animację w np. RNOAnim, który z tego co widziałem działa bardzo fajnie. Pozwala nawet zmienić czasy dla każdej klatki i zapisać animację do AnimGIF (który mnie akurat teraz interesuje).
No to lecę pixlować retro-animację (mało kolorów, niska rozdzielczość). Nie jestem w tym fachowcem ale akurat mam potrzebę taką zrobić i uparłem się, że będę robił pod MorphOS (mogłem przecież użyć GrafX2 dla dzisiejszego macOS). GrafX2, Brilliance, Deluxe Paint, albo Personal Paint wydają się idealne do tego celu. Chociaż nie ukrywam, że GrafX2 najbardziej. Deluxe Paint i Brilliance raczej odpadają, bo wymagają układów graficznych Amigi i musiałbym użyć UAE. Poza tym DPaint ma jedno Undo i to mnie strasznie irytuje. Personal Paint nieźle się krzaczy pod MorphOSem. Poza tym zawsze mnie denerwowała, GUI, wielkość ekranu, rozdzielczość jest bardzo uzleżnione od rozdzielczości i liczby kolorów obrabianego obrazka/animacji. GrafX2 nie ma tych wszystkich ułomności, a ma sporo fajnych funkcji, jest w mocno retro-stylu, jest specjalizowany do grafiki max. 256 kolorów. A o to w tym przypadku mi chodzi (dlatego odpadają: TVPaint, ArtEffect, Photogenics, ImageFX, fXPaint).
Ostatnia aktualizacja: 02.04.2022 21:05:56 przez MDW
Jest jedna śmieszostka w GrafX2. Aż trudno uwierzyć, że taki niedostatek istnieje od wielu lat. I nie chodzi tutaj o wersję dla MorphOS tylko generalnie o GrafX2 dla wszystkich platform. Chodzi o to, że właściwie nie ma tam funkcji odtwarzania animacji.
Można sobie nacisnąć prawy klawisz myszy na przycisku Next w animacji i jakoś się tam odtwarza. Ale trzeba trzymać przycisk i to zupełnie nie bierze pod uwagę czasu trwania każdej klatki. Właściwie podczas rysowania nie ma to wielkiego znaczenia i mnogość innych funkcji rekompensuje ten niedostatek. Podczas rysowania animacji ważne jest łatwe, szybkie przeskakiwanie między klatkami, a otworzy się później animację w np. RNOAnim, który z tego co widziałem działa bardzo fajnie. Pozwala nawet zmienić czasy dla każdej klatki i zapisać animację do AnimGIF (który mnie akurat teraz interesuje). No to lecę pixlować retro-animację (mało kolorów, niska rozdzielczość). Nie jestem w tym fachowcem ale akurat mam potrzebę taką zrobić i uparłem się, że będę robił pod MorphOS (mogłem przecież użyć GrafX2 dla dzisiejszego macOS). GrafX2, Brilliance, Deluxe Paint, albo Personal Paint wydają się idealne do tego celu. Chociaż nie ukrywam, że GrafX2 najbardziej. Deluxe Paint i Brilliance raczej odpadają, bo wymagają układów graficznych Amigi i musiałbym użyć UAE. Poza tym DPaint ma jedno Undo i to mnie strasznie irytuje. Personal Paint nieźle się krzaczy pod MorphOSem. Poza tym zawsze mnie denerwowała, GUI, wielkość ekranu, rozdzielczość jest bardzo uzleżnione od rozdzielczości i liczby kolorów obrabianego obrazka/animacji. GrafX2 nie ma tych wszystkich ułomności, a ma sporo fajnych funkcji, jest w mocno retro-stylu, jest specjalizowany do grafiki max. 256 kolorów. A o to w tym przypadku mi chodzi (dlatego odpadają: TVPaint, ArtEffect, Photogenics, ImageFX, fXPaint).
Ostatnia aktualizacja: 02.04.2022 21:05:56 przez MDW