07.08 07:42
[#91]
Re: PiStorm and Warp3D
@abcdef, post #90
GemRB nie wymaga akceleracji sprzętowej 3D. Mam działającą wersję pre-alpha dla procesorów 68k, która na PiStorm osiąga 25 kl./s (co stanowi limit silnika, przynajmniej w starszych wersjach wynikający z jego konstrukcji). Problem polega na kwestiach związanych z typem `wchar`, z którymi kompilator gcc dla 68k sobie nie radzi (kwestia biblioteki linkera C++), dlatego nie kontynuowałem prac nad tą wersją.
Gdy pojawi się obsługa WarpOS (EmuPPC), będzie można uruchomić mój port GemRB 0.8.7 dla tego systemu. Obsługuje on gry: Baldur's Gate 1 i 2, Planescape: Torment oraz Icewind Dale 1.
Obecnie portuję GemRB 0.9.5 (najnowszą stabilną wersję) na AmigaOS 4. Robię to tylko dla AmigaOS 4, ponieważ wersja 0.9.5 wymaga Pythona 3 (korzystam z wersji beta Pythona 3 dla OS4), więc aktualizacja portu dla WarpOS również wymagałaby Pythona 3 (wersja 0.8.7 używała Pythona 2.7). Wersja 0.9.5 wprowadza obsługę Icewind Dale 2 oraz Baldur's Gate w edycji Enhanced (przynajmniej podstawowej wersji BG2, bez dodatku). Warto zauważyć, że w wersji 0.9.5 znacznie zmieniono kod odpowiedzialny za obsługę `wchar`. Choć nadal występuje tam `wchar` (głównie wewnątrz biblioteki libfmt), możliwe, że problemy występujące w wersji 0.8.7 przy kompilacji na 68k już nie wystąpią (choć nie mam pewności). Jednak z racji braku Pythona 3 na 68k, nie ma jak tego sprawdzić.
Autorzy portu Pythona 3 na AmigaOS 4 wspominali, że teoretycznie możliwe będzie stworzenie wersji dla 68k i WarpOS po ukończeniu wersji dla OS4. Zajmie to jednak sporo czasu (prace są na tyle zaawansowane, że pozwalają uruchomić GemRB, ale nie jest to jeszcze kompletny port Pythona 3, a GemRB wymaga jedynie niewielkiej części jego funkcjonalności).
Gdy pojawi się obsługa WarpOS (EmuPPC), będzie można uruchomić mój port GemRB 0.8.7 dla tego systemu. Obsługuje on gry: Baldur's Gate 1 i 2, Planescape: Torment oraz Icewind Dale 1.
Obecnie portuję GemRB 0.9.5 (najnowszą stabilną wersję) na AmigaOS 4. Robię to tylko dla AmigaOS 4, ponieważ wersja 0.9.5 wymaga Pythona 3 (korzystam z wersji beta Pythona 3 dla OS4), więc aktualizacja portu dla WarpOS również wymagałaby Pythona 3 (wersja 0.8.7 używała Pythona 2.7). Wersja 0.9.5 wprowadza obsługę Icewind Dale 2 oraz Baldur's Gate w edycji Enhanced (przynajmniej podstawowej wersji BG2, bez dodatku). Warto zauważyć, że w wersji 0.9.5 znacznie zmieniono kod odpowiedzialny za obsługę `wchar`. Choć nadal występuje tam `wchar` (głównie wewnątrz biblioteki libfmt), możliwe, że problemy występujące w wersji 0.8.7 przy kompilacji na 68k już nie wystąpią (choć nie mam pewności). Jednak z racji braku Pythona 3 na 68k, nie ma jak tego sprawdzić.
Autorzy portu Pythona 3 na AmigaOS 4 wspominali, że teoretycznie możliwe będzie stworzenie wersji dla 68k i WarpOS po ukończeniu wersji dla OS4. Zajmie to jednak sporo czasu (prace są na tyle zaawansowane, że pozwalają uruchomić GemRB, ale nie jest to jeszcze kompletny port Pythona 3, a GemRB wymaga jedynie niewielkiej części jego funkcjonalności).
07.08 08:55
[#92]
Re: PiStorm and Warp3D
@MagicSN, post #91
Infinity Engine też nie, ale jak się walnie trochę efektów czarów obszarowych to wyraźnie zwalnia bez akceleracji. Nie żeby akceleracja rozwiązywała wszystkie problemy. A czarów obszarowych jak kwasowa chmura, trująca chmura, śmierdząca chmura, śliskość, pajęczyna... no trochę tego można zestackować. W każdym razie czekam niecierpliwie bo jeśli generalnie jakąkolwiek grę z pc na amidze z pistormem bym chciał ogrywać to gry iwd/bg właśnie (no i może hiroski)
07.08 12:03
[#93]
Re: PiStorm and Warp3D
@abcdef, post #92
Problemy, o których wspominam, dotyczyły błędów w bibliotekach konsolidatora. Silnik wykorzystuje 16-bitowe znaki typu *wchar*, podczas gdy kompilator dla architektury 68k obsługuje jedynie wersję 32-bitową (a może było odwrotnie? Nie pamiętam dokładnie, w każdym razie chodziło o jedną z tych dwóch opcji). Z kolei w systemach OS4 i WarpOS obsługiwane są obie wersje.
Skutkowało to tym, że tekst w oknach dialogowych był praktycznie nieczytelny. Oczywiście istniałaby możliwość przebudowania całego kodu tak, aby zrezygnować z typu *wchar*. Z drugiej strony, gdy tylko pojawi się EmuPPC, będzie można uruchomić wersję dla systemu WarpOS.
Skutkowało to tym, że tekst w oknach dialogowych był praktycznie nieczytelny. Oczywiście istniałaby możliwość przebudowania całego kodu tak, aby zrezygnować z typu *wchar*. Z drugiej strony, gdy tylko pojawi się EmuPPC, będzie można uruchomić wersję dla systemu WarpOS.
16.08 11:56
[#96]
Re: PiStorm and Warp3D
@abcdef, post #90
Niezależnie od kwestii 3DHW – pytałeś na forum GemRB o wersję dla procesorów 68k. Prawdopodobnie wkrótce wejdzie ona w fazę beta-testów. Dzisiaj nastąpił przełom w kwestii pozostałych problemów 
Wciąż nie działa wczytywanie zapisanych stanów gry (to pewnie drobny błąd związany ze ścieżkami do plików; obecnie system zawsze komunikuje brak zapisów, nawet jeśli jakiś utworzyłem – powinno dać się to łatwo naprawić).
Jeśli chodzi o pytanie innego użytkownika dotyczące PiStorm3D – zobaczymy, czy Q3 będzie działać wystarczająco szybko. Na pewno podejmę taką próbę (mam już wersję Q3, która się kompiluje, choć jeszcze nie przechodzi etapu linkowania; to samo dotyczy Jedi Knight Outcast i Serious Sam).
Wciąż nie działa wczytywanie zapisanych stanów gry (to pewnie drobny błąd związany ze ścieżkami do plików; obecnie system zawsze komunikuje brak zapisów, nawet jeśli jakiś utworzyłem – powinno dać się to łatwo naprawić).Jeśli chodzi o pytanie innego użytkownika dotyczące PiStorm3D – zobaczymy, czy Q3 będzie działać wystarczająco szybko. Na pewno podejmę taką próbę (mam już wersję Q3, która się kompiluje, choć jeszcze nie przechodzi etapu linkowania; to samo dotyczy Jedi Knight Outcast i Serious Sam).
pewnie BSzili nie będzie chętny do aktualizacji Carmageddon pod WOS'a 
20.08 16:55
[#106]
Re: PiStorm and Warp3D
@Mirq, post #105
Lepsza optymalizacja nie polega na zmniejszaniu rozdzielczości ekranu (co w przypadku układu VideoCore VI nie robi wielkiej różnicy), lecz na zmianie silnika (o ile to w ogóle możliwe – może to wymagać mnóstwa pracy) tak, aby nie wysyłał on zaledwie trzech wielokątów naraz, lecz przesyłał większe ich partie za jednym razem (to właśnie dlatego Quake 2 nie działa znacznie szybciej niż Quake 3 – Quake 2 również często wysyła małe partie wielokątów).
W przypadku VideoCore VI głównym obciążeniem nie jest samo renderowanie grafiki 3D, lecz przygotowywanie danych wierzchołkowych. Im bardziej dane są rozdrobnione, tym gorzej; Carmageddon stanowi w zasadzie najgorszy możliwy scenariusz.
Mimo to Arczi wykonał kawał dobrej roboty, uruchamiając to bez docelowego sprzętu (dysponował biblioteką minigl.library dla Warp3D/MiniGL, która jest zgodna z API, więc mógł przeprowadzić testy na Voodoo 3 czy czymś podobnym).
Ostatnia aktualizacja: 20.08.2026 16:57:53 przez MagicSN
Ostatnia aktualizacja: 20.08.2026 17:00:14 przez MagicSN
W przypadku VideoCore VI głównym obciążeniem nie jest samo renderowanie grafiki 3D, lecz przygotowywanie danych wierzchołkowych. Im bardziej dane są rozdrobnione, tym gorzej; Carmageddon stanowi w zasadzie najgorszy możliwy scenariusz.
Mimo to Arczi wykonał kawał dobrej roboty, uruchamiając to bez docelowego sprzętu (dysponował biblioteką minigl.library dla Warp3D/MiniGL, która jest zgodna z API, więc mógł przeprowadzić testy na Voodoo 3 czy czymś podobnym).
Ostatnia aktualizacja: 20.08.2026 16:57:53 przez MagicSN
Ostatnia aktualizacja: 20.08.2026 17:00:14 przez MagicSN
20.08 22:19
[#110]
Re: PiStorm and Warp3D
@Mirq, post #108
To nie zmiana rozdzielczości ekranu zapewnia wzrost wydajności; w przypadku PiStorm rozdzielczość ma znikomy wpływ. Kluczowe znaczenie ma liczba wielokątów wyświetlanych jednocześnie oraz częstotliwość tych operacji. Przy architekturze takiej jak VideoCore VI samo wyświetlanie grafiki 3D nie jest zbyt obciążające – to przygotowanie danych wierzchołkowych pochłania najwięcej zasobów. Dlatego właśnie Quake 2 ma stosunkowo wysokie wymagania w porównaniu do Quake'a 1 czy 3: często przesyłane są w nim niewielkie zestawy wierzchołków. W przypadku Carmageddona sytuacja wygląda jeszcze gorzej, gdyż przesyła on grupy składające się z trzech wielokątów, co stanowi najmniej korzystny scenariusz. Najlepszą optymalizacją byłaby zmiana tego mechanizmu; rozdzielczość ekranu może pozostać bez zmian.
21.08 00:14
[#111]
Re: PiStorm and Warp3D
@MagicSN, post #110
Kluczowe znaczenie ma liczba wielokątów wyświetlanych jednocześnie oraz częstotliwość tych operacji. Przy architekturze takiej jak VideoCore VI samo wyświetlanie grafiki 3D nie jest zbyt obciążające – to przygotowanie danych wierzchołkowych pochłania najwięcej zasobów.
Jak dobrze rozumię zajmuje się tym jakiś osobny proces uruchomiony bezpośrednio AmigaOS który musi obrobić te dane i przekazać dalej ?
Ostatnia aktualizacja: 21.08.2026 00:16:43 przez markusg
21.08 09:15
[#112]
Re: PiStorm and Warp3D
@markusg, post #111
i nie znam szczegółów implementacji, ale wiem, że ten typ sprzętu (nie „natychmiastowy”) wymaga większego wysiłku w zakresie konfigurowania danych i to jest do zrobienia przez cou. dla nowoczesnych silników, takich jak quake3, nie stanowi to problemu, ponieważ robią to już dobrze dla tej architektury (używając vertexarrays lub po prostu nie tworząc zbyt wielu małych grup begin/end). ale silnik carmaggeddon robi to źle w extreme i quake2 również ma tutaj wady. quake2 nadal działa 35 fps w 1024x768 z nim (ale q3 jest niewiele wolniejszy, mimo że jest znacznie cięższym silnikiem - ponieważ jest zaimplementowany w sposób bardziej przyjazny dla tbdr
21.08 20:36
[#114]
Re: PiStorm and Warp3D
@koczis, post #113
Zgadza się. W przypadku nowszych układów 3D zazwyczaj tak jest, na OS4 z radeonhd jest tak samo. Chociaż radeonhd jest nadal architekturą bezpośrednią, w przypadku układów tbdr, takich jak videocore iv/vi (używany w pi3/4) lub układ mali (jak w thea1200 lub a1200ng) efekt jest jeszcze silniejszy. Ważniejsze jest zmniejszenie liczby grup begin/end na klatkę, a także użycie vertexarray zamiast pojedynczych wpisów. Na przykład quake3 bardzo dobrze sobie z tym radzi.
