28.07 23:23
[#61]
Re: PiStorm and Warp3D
@Mirq, post #60
Rzeczywiście tak jest jak mówisz, że to by była reimplementacja wewnętrznego API pomiędzy biblioteką główną Warp3D a sterownikiem sprzętowym. Od strony technicznej brak DDK nie jest żadnym problemem bo ja już dużo wyciągnąłem (oczywiście w domowym zaciszu na własny użytek chyba mogę robić co mnie się podoba i nikt mnie nie będzie ścigał) na bazie samego śledzenia wywołań biblioteki Avenger przez bibliotekę główną. Można powiedzieć, że wszystko co potrzebne, jest dostępne :). Więc ktoś bieglejszy ode mnie ogarnąłby to szybko, mnie by to zajęło parę miesięcy na które zresztą nie mogę sobie pozwolić bo mam zobowiązania zawodowo/rodzinne.
Jeżeli jest tak jak mówisz w tym zapisie LEGAL to pewnie dlatego nikt tego nie ruszył wcześniej. I tutaj jedyną nadzieją jest nowy otwarty projekt (w rodzaju tego zaprezentowanego w tym wątku) i dostosowanie go do potrzeb klasycznej Amigi.
LEGAL NOTICE: Moje rozważania są czysto teoretyczne, mocno się zajarałem tematem podczas "analizy publicznie dostępnych materiałów" ale na tym się raczej skończy. Więc właściciele jakichkolwiek praw mogą spać spokojnie.
Jeżeli jest tak jak mówisz w tym zapisie LEGAL to pewnie dlatego nikt tego nie ruszył wcześniej. I tutaj jedyną nadzieją jest nowy otwarty projekt (w rodzaju tego zaprezentowanego w tym wątku) i dostosowanie go do potrzeb klasycznej Amigi.
LEGAL NOTICE: Moje rozważania są czysto teoretyczne, mocno się zajarałem tematem podczas "analizy publicznie dostępnych materiałów" ale na tym się raczej skończy. Więc właściciele jakichkolwiek praw mogą spać spokojnie.
29.07 10:09
[#62]
Re: PiStorm and Warp3D
@Mirq, post #60
Taki zapis jest tak samo wiążący jak zapis w umowie kredytowej "a jak nie będziesz mógł spłacić to zostaniesz moim niewolnikiem". Generalnie w EU reverse engineering API by zachować zgodność ze standardem twórcy jest dozwolony i ograniczony być nie może żadnym zapisem w terms of service. Natomiast co innego zrobić wrapper, który zamiast linkować funkcje do API będzie wywołania tłumaczył do czegoś innego (jak tłumaczy wywołania D3D do Vulkana DXVK, albo jak tłumaczył glide do D3D/OGL np. nGlide czy dgVoodoo), a co innego podpiąć się z własnym driverem do cudzego API. O ile zrobienie wrappera jest prawnie git majonez tak zrobienie własnego drivera do oryginalnego podsystemu W3D może być już co najmniej wątpliwe jeśli to byłoby zrobione przez disassemblację oryginalnych binarek czy wykorzystanie zastrzeżonego kodu z DDK. A nie wiem czy zrobienie drivera z "clean room process" jest osiągalne w zakładanym budżecie czasu i środków.
Inna sprawa - NDA w DDK - nie wiem jakie tam są zapisy, ale jeśli był zapis, że bez zgody HE nie można opracowywać innych sterowników to osoba która NDA podpisała zwyczajnie nie może, nawet w procesie cleanroom czyli nie bazując na DDK i pisząc od podstaw. Nie jest to złamanie praw autorskich, ale NDA.
Inna sprawa - NDA w DDK - nie wiem jakie tam są zapisy, ale jeśli był zapis, że bez zgody HE nie można opracowywać innych sterowników to osoba która NDA podpisała zwyczajnie nie może, nawet w procesie cleanroom czyli nie bazując na DDK i pisząc od podstaw. Nie jest to złamanie praw autorskich, ale NDA.
29.07 11:50
[#63]
Re: PiStorm and Warp3D
@abcdef, post #62
Masz absolutną rację, że API nie są chronione w UE, a prawnie AEON przegrałby każdy proces w tej sprawie.
Z rozmów z nimi jestem jednak dość świadomy, że „myślą”, że mają rację, twierdząc, że „nikt nie może odtworzyć Warp3D bez naszej zgody, bo za to zapłaciliśmy”. Z prawnego punktu widzenia to nieprawda, bo jak sam mówisz, API nie są chronione. Pytanie jednak brzmi: „czy jesteście gotowi wciągnąć się w proces sądowy, nawet taki, który z pewnością wygracie?”.
W przypadku PiStorm 3D zdecydowaliśmy się na MiniGL jako podstawę, nie dlatego, że sądziliśmy, że publiczne API Warp3D będzie chronione prawem (bo nie jest). Ale dlatego, że nie chcieliśmy wciągać się w proces sądowy, nawet taki, który wygralibyśmy. Zauważ, że AEON nigdy nie powiedział, że faktycznie wniesie pozew, a jedynie, że „nikt nie może stworzyć zamiennika Warp3D, bo zapłaciliśmy za Warp3D i go nie przyjmiemy” lub coś w tym stylu.
Sprawa staje się jeszcze bardziej absurdalna w przypadku PiStorm 3D. PiStorm to pierwsza w historii biblioteka 3D dla systemu AmigaOS obsługująca architekturę TBDR. Wszystkie pozostałe biblioteki i sterowniki 3D w tym systemie opierały się na architekturze typu „immediate” (tak, nawet sterowniki RadeonHD/RX!!!). TBDR to rozwiązanie całkowicie odmienne. Nawet osoba mająca dostęp do ich najnowszych sterowników (co w tym przypadku nie ma miejsca) nie dysponowałaby absolutnie żadnym kodem, który można by wykorzystać przy tworzeniu sterowników dla układu VideoCore VI. Sytuacja może wyglądać wręcz odwrotnie: gdyby firma AEON uzyskała dostęp do kodu źródłowego PiStorm 3D, zyskałaby przewagę przy tworzeniu biblioteki 3D dla Amigi 1200NG (korzysta ona z innego układu graficznego, ale również opartego na architekturze TBDR).
Jeśli chodzi o pisanie z wykorzystaniem API chronionego NDA (DDK), to oczywiście zupełnie inna kwestia. Takie API BYŁYby chronione (obowiązującą umową NDA).
Myślę, że korzystanie z MiniGL jest najlepsze dla obu stron (projektu PiStorm 3D i AEON), ponieważ nie pozostawia miejsca na ewentualne spory (sądowe lub pozasądowe). Większość oprogramowania i tak przechodzi przez GL (istotne jest również to, że tworząc grę zarówno dla 68k, jak i OS4, trzeba stworzyć wersję GL, ponieważ dla samego OS4 trzeba obsługiwać MiniGL/Warp3D i GLES/W3DNova – Warp3D i W3DNova to dwa zupełnie różne API, podczas gdy wersja GL obsługuje 68k za pomocą MiniGL68k/MiniGLOS4/GLESOS4, bez żadnych realnych niedogodności. Pamiętaj, że Warp3D to API jedynie z „dawnych czasów” (rasteryzator).
Ostatnia aktualizacja: 29.07.2026 11:57:10 przez MagicSN
Z rozmów z nimi jestem jednak dość świadomy, że „myślą”, że mają rację, twierdząc, że „nikt nie może odtworzyć Warp3D bez naszej zgody, bo za to zapłaciliśmy”. Z prawnego punktu widzenia to nieprawda, bo jak sam mówisz, API nie są chronione. Pytanie jednak brzmi: „czy jesteście gotowi wciągnąć się w proces sądowy, nawet taki, który z pewnością wygracie?”.
W przypadku PiStorm 3D zdecydowaliśmy się na MiniGL jako podstawę, nie dlatego, że sądziliśmy, że publiczne API Warp3D będzie chronione prawem (bo nie jest). Ale dlatego, że nie chcieliśmy wciągać się w proces sądowy, nawet taki, który wygralibyśmy. Zauważ, że AEON nigdy nie powiedział, że faktycznie wniesie pozew, a jedynie, że „nikt nie może stworzyć zamiennika Warp3D, bo zapłaciliśmy za Warp3D i go nie przyjmiemy” lub coś w tym stylu.
Sprawa staje się jeszcze bardziej absurdalna w przypadku PiStorm 3D. PiStorm to pierwsza w historii biblioteka 3D dla systemu AmigaOS obsługująca architekturę TBDR. Wszystkie pozostałe biblioteki i sterowniki 3D w tym systemie opierały się na architekturze typu „immediate” (tak, nawet sterowniki RadeonHD/RX!!!). TBDR to rozwiązanie całkowicie odmienne. Nawet osoba mająca dostęp do ich najnowszych sterowników (co w tym przypadku nie ma miejsca) nie dysponowałaby absolutnie żadnym kodem, który można by wykorzystać przy tworzeniu sterowników dla układu VideoCore VI. Sytuacja może wyglądać wręcz odwrotnie: gdyby firma AEON uzyskała dostęp do kodu źródłowego PiStorm 3D, zyskałaby przewagę przy tworzeniu biblioteki 3D dla Amigi 1200NG (korzysta ona z innego układu graficznego, ale również opartego na architekturze TBDR).
Jeśli chodzi o pisanie z wykorzystaniem API chronionego NDA (DDK), to oczywiście zupełnie inna kwestia. Takie API BYŁYby chronione (obowiązującą umową NDA).
Myślę, że korzystanie z MiniGL jest najlepsze dla obu stron (projektu PiStorm 3D i AEON), ponieważ nie pozostawia miejsca na ewentualne spory (sądowe lub pozasądowe). Większość oprogramowania i tak przechodzi przez GL (istotne jest również to, że tworząc grę zarówno dla 68k, jak i OS4, trzeba stworzyć wersję GL, ponieważ dla samego OS4 trzeba obsługiwać MiniGL/Warp3D i GLES/W3DNova – Warp3D i W3DNova to dwa zupełnie różne API, podczas gdy wersja GL obsługuje 68k za pomocą MiniGL68k/MiniGLOS4/GLESOS4, bez żadnych realnych niedogodności. Pamiętaj, że Warp3D to API jedynie z „dawnych czasów” (rasteryzator).
Ostatnia aktualizacja: 29.07.2026 11:57:10 przez MagicSN
29.07 13:19
[#64]
Re: PiStorm and Warp3D
@MagicSN, post #63
A to nie tak, że TheA1200 to nadal tylko jakiś custom linux z uae4arm lub czymś podobnym? Jeszcze rozumiem jakąś wirtualizację zasobów żeby od strony AOS był widoczny "jakiś" układ graficzny, ale całość byłaby tylko swoistym wrapperem do tego co oferuje sterownik linuksowy (zapewne binary blob producenta SoC który bazuje na elementach softu udostępnionego przez ARM). W podobny sposób zrealizowane zdaje się było RTG w Pistorm na musashi... To zupełnie inna bajka, bo wy bezpośrednio piszecie do rejestrów VideoCore z poziomu systemu 68k (nawet jeśli samo wykonanie instrukcji jest tłumaczone w locie do arm). Oczywiste jest też to, że nie każdego stać na pozwy z korporacjami nawet jeśli korpo nie ma racji (było wiele głośnych przypadków). To jest poza konkursem. Pisałem tylko o tym co ewentualnie mogłoby być argumentem w procesie a co z pewnością nie jest. Moje tłumaczenie wskazywało, że wrapper jest rozwiązaniem bezpieczniejszym i - kolejny raz - potwierdza, że pójście bezpośrednio w MiniGL jest optymalną opcją.
29.07 13:51
[#65]
Re: PiStorm and Warp3D
@abcdef, post #64
Nie wspominałem o TheA1200. Mówiłem o A1200NG. To różne maszyny (A1200NG pochodzi od firmy Aeon, a TheA1200 od innego producenta). Owszem, obie bazują na emulacji, ale A1200NG faktycznie umożliwia uruchamianie kodu natywnego.
I tak, stworzenie wrappera to bezpieczniejsze rozwiązanie. Poza tym może się tym zająć ktoś inny – jestem pewien, że prędzej czy później ktoś taki wrapper przygotuje. Właściwie to wczoraj ktoś pisał do mnie, że przyjrzał się QuarkTexowi i temu, jak można go skompilować na AmigaOS. W obecnej postaci PiStorm 3D nie zawiera absolutnie żadnych odniesień do Warp3D czy nawet Wazp3D, ani też żadnego kodu z nimi związanego. Mimo to zastanawiam się: czy kompatybilność z Warp3D jest w ogóle jeszcze potrzebna? Może i jest wygodna, ale spodziewam się, że z czasem odejdzie ona do lamusa. To OpenGL jest tu kluczowy.
To też jest poniekąd zabawne. Od stanowiska: „Musicie tworzyć swoją bibliotekę 3D jako rozwiązanie zamknięte (Closed Source), bo należy ona do nas i za nią zapłaciliśmy”, do sytuacji, w której: „W takim razie po prostu nie będziemy korzystać z niczego, co jest z nią związane, i i tak zrobimy to w modelu Open Source – a programiści mogą ostatecznie stracić zainteresowanie waszą biblioteką”
Ostatnia aktualizacja: 29.07.2026 13:53:26 przez MagicSN
I tak, stworzenie wrappera to bezpieczniejsze rozwiązanie. Poza tym może się tym zająć ktoś inny – jestem pewien, że prędzej czy później ktoś taki wrapper przygotuje. Właściwie to wczoraj ktoś pisał do mnie, że przyjrzał się QuarkTexowi i temu, jak można go skompilować na AmigaOS. W obecnej postaci PiStorm 3D nie zawiera absolutnie żadnych odniesień do Warp3D czy nawet Wazp3D, ani też żadnego kodu z nimi związanego. Mimo to zastanawiam się: czy kompatybilność z Warp3D jest w ogóle jeszcze potrzebna? Może i jest wygodna, ale spodziewam się, że z czasem odejdzie ona do lamusa. To OpenGL jest tu kluczowy.
To też jest poniekąd zabawne. Od stanowiska: „Musicie tworzyć swoją bibliotekę 3D jako rozwiązanie zamknięte (Closed Source), bo należy ona do nas i za nią zapłaciliśmy”, do sytuacji, w której: „W takim razie po prostu nie będziemy korzystać z niczego, co jest z nią związane, i i tak zrobimy to w modelu Open Source – a programiści mogą ostatecznie stracić zainteresowanie waszą biblioteką”
Ostatnia aktualizacja: 29.07.2026 13:53:26 przez MagicSN
30.07 15:20
[#71]
Re: PiStorm and Warp3D
@Sir_Lucas, post #67
Warto jednak pamiętać, że demo Gears dla WarpOS działało z 16-bitową głębią kolorów. PiStorm3D obsługuje obecnie tylko 32-bitową głębię kolorów (choć w wersji finalnej dostępna będzie również wersja 16-bitowa). Być może wersja 16-bitowa będzie jeszcze szybsza niż te 125 kl./s. Dzięki za konkretne wyniki dla zestawu CSPPC+CVPPC. Zakładam, że chodzi o plik wykonywalny dla WarpOS?
30.07 15:23
[#72]
Re: PiStorm and Warp3D
@BULI, post #70
Znam te liczby (choć słyszałem raczej o wartościach zbliżonych do 100). Trzeba jednak pamiętać, że to porównanie trybów 16-bitowego i 32-bitowego koloru. Niewykluczone też, że w przyszłości uda się jeszcze bardziej zoptymalizować działanie PiStorm3D (nie mam pewności, czy uda się uzyskać wyższą wydajność – czas pokaże).
30.07 17:41
[#73]
Re: PiStorm and Warp3D
@MagicSN, post #71
Może tak być, ale nie musi. Za czasów pierwszego Radeona praktycznie nie było żadnego zysku z przełączenia w 16bit, bo architektura była mocno nastawiona już na 32 i jakkolwiek wsparcie do 16bit było tak nic nie wnosiło. Trochę jak w nowoczesnych procesorach 64 bit. Dalej x86-64 może operować na 16bit rejestrach oryginalnego 8086 tylko co to zmienia? :)
30.07 19:45
[#74]
Re: PiStorm and Warp3D
@MagicSN, post #71
Warto jednak pamiętać, że demo Gears dla WarpOS działało z 16-bitową głębią kolorów. PiStorm3D obsługuje obecnie tylko 32-bitową głębię kolorów (choć w wersji finalnej dostępna będzie również wersja 16-bitowa). Być może wersja 16-bitowa będzie jeszcze szybsza niż te 125 kl./s. Dzięki za konkretne wyniki dla zestawu CSPPC+CVPPC. Zakładam, że chodzi o plik wykonywalny dla WarpOS?
W takim razie te 125 FPS robi jeszcze większe wrażenie.
Tak, to konkretne wyniki dla pliku wykonywalnego WarpOS przy full screenie.
Karta to CSPPC 200Mhz. W oknie mam 43 FPS. Podejrzewam, że PiStorm 3D w oknie dobije do 200 FPS.
.31.07 11:34
[#77]
Re: PiStorm and Warp3D
@bfgmatik, post #76
Tak, zdecydowanie. Jestem całkiem zadowolony z tych 125 kl./s, które do tej pory osiągnęliśmy A jeśli chodzi o dokumentację – sytuacja wyglądała tak, jak mówiłeś. Naszą dokumentacją był kod źródłowy MesaGL/Gallium dla Linuksa ^^ Mieliśmy jednak pewne wsparcie ze strony osób ze sceny „Bare Metal Pi”, które sporo eksperymentowały z Raspberry Pi, tworzyły na nie dema i tym podobne rzeczy, i mogły służyć radą. Do tego dochodził paraj (autor koncepcji sterownika 3D – choć stworzył go dla VideoCore IV, a nie VideoCore VI, czyli dla modelu Pi3), a w kwestiach specyficznych dla PiStorm doradzali nam Claude i mschulz.
A jeśli chodzi o dokumentację – sytuacja wyglądała tak, jak mówiłeś. Naszą dokumentacją był kod źródłowy MesaGL/Gallium dla Linuksa ^^ Mieliśmy jednak pewne wsparcie ze strony osób ze sceny „Bare Metal Pi”, które sporo eksperymentowały z Raspberry Pi, tworzyły na nie dema i tym podobne rzeczy, i mogły służyć radą. Do tego dochodził paraj (autor koncepcji sterownika 3D – choć stworzył go dla VideoCore IV, a nie VideoCore VI, czyli dla modelu Pi3), a w kwestiach specyficznych dla PiStorm doradzali nam Claude i mschulz. 
06.08 07:21
[#82]
Re: PiStorm and Warp3D
@betonumysłowy, post #81
Chcę zobaczyć, jak będą na tym działać gry oparte na silnikach Q2 i Q3, gdy obsługa PiStorm3D osiągnie odpowiedni poziom zaawansowania. Spodziewam się, że w obu przypadkach płynność będzie zadowalająca: w Q2 liczę na rozdzielczość zbliżoną do tej z Q1, a w Q3 – na co najmniej 640x480 (choć do ich uruchomienia potrzeba jeszcze trochę pracy).
06.08 07:54
[#83]
Re: PiStorm and Warp3D
@MagicSN, post #82
Nie spodziewałbym się raczej 999 fps ;) Jakkolwiek RPi4 pewnie ogarnia Q3 w FHD i super płynności tak trzeba pamiętać, że nawet Q3 sporo zadań związanych z geometrią dalej zostawia CPU (GPU nie robi wszystkiego), a tu mamy JIT, jeszcze się straci trochę czasu na obsługę samego API. Innymi słowy wydaje mi się, że hamulcowym nie będzie ani GPU ani nawet sterownik (choć sterownik swój narzut też ma).
06.08 11:02
[#85]
Re: PiStorm and Warp3D
@rbej1977, post #84
No to jest coś o czym na discord wspominałem, ale taka jest ich decyzja i nie będę nikogo do niczego zmuszał. Dla mnie równie dobrze można RPi olać, postawić to samo na Agilex 5 (z Cortex A76+A55) i wyprowadzić PCIe do m.in. kart graficznych gdzie można się znowuż posiłkować mesa z linux. No, ale to bym powiedział mogła być nawet nowa platforma, bo człon FPGA bez problemu mógłby stanowić emulację (tfu, re-implementację) AGA, a hard processor by śmigał jako emu68k i emuppc (cortex a 55 mógłby działać jako silnik geometrii prostego rtg 3D). Może... kiedyś. Może jak będą nowsze FPGA z jeszcze szybszymi hard processorami.
06.08 11:52
[#86]
Re: PiStorm and Warp3D
@abcdef, post #85
To chyba nie jest "ich decyzja", ale raczej problem sprzętowy. Z tego co pamiętem Pi5 nie nadaje się do Pistorma ze względu na brak bezpośredniego połączenia GPIO z procesorem co powoduje dodatkowe opóźnienia.
Wydaje mi się, że mschulz właśnie tak to tłumaczył kiedyś na discordzie.
Wydaje mi się, że mschulz właśnie tak to tłumaczył kiedyś na discordzie.
06.08 12:04
[#88]
Re: PiStorm and Warp3D
@TomcioPaluszek, post #86
To o czym mówisz jest prawdą, natomiast decyzja jest też taka, że poza ekosystem RPi i tak nie chcą wychodzić (mimo przedstawionej alternatywy która mogłaby spiąć to wszystko w jednym układzie, w każdym razie międzymordzie jakie robi Trion FPGA oraz to co robi Framethrower). Rozumiem decyzję, bo to zupełnie inny ekosystem gdzie trzeba by zaczynać od 0. Dla samego emu68 nie robi to aż tak dużej różnicy, ale cała reszta...
06.08 18:01
[#89]
Re: PiStorm and Warp3D
@abcdef, post #88
Gdy ostatnio rozmawiałem o tym z Claude’em, mówił, że wciąż szukają alternatyw, ale wszystkie one albo mają ten sam problem co Pi5, albo inne wady, które uniemożliwiają ich wykorzystanie. Zatem decyzja zdecydowanie jeszcze nie zapadła.
Jeśli chodzi o wydajność – Q1 działa już z prędkością ponad 50 kl./s. Na kartach PCI PPC z systemem WarpOS osiąga ponad 40 kl./s (wynik zbliżony do 50). Q2 w trybie renderowania programowego działa z prędkością 25–30 kl./s. Osobiście spodziewam się, że silnik Q3 z PiStorm3D zapewni płynną rozgrywkę w rozdzielczości 640x480, ale prawdopodobnie nie w wyższych rozdzielczościach. W przypadku Q2, porównując dane z innymi systemami Amigi, spodziewam się wyników zbliżonych do tych z Q1. To oczywiście tylko szacunki; wkrótce przekonamy się, jak to faktycznie będzie działać.
„Wkrótce” nie oznacza jednak tego tygodnia ani niczego w tym stylu.
Jeśli chodzi o wydajność – Q1 działa już z prędkością ponad 50 kl./s. Na kartach PCI PPC z systemem WarpOS osiąga ponad 40 kl./s (wynik zbliżony do 50). Q2 w trybie renderowania programowego działa z prędkością 25–30 kl./s. Osobiście spodziewam się, że silnik Q3 z PiStorm3D zapewni płynną rozgrywkę w rozdzielczości 640x480, ale prawdopodobnie nie w wyższych rozdzielczościach. W przypadku Q2, porównując dane z innymi systemami Amigi, spodziewam się wyników zbliżonych do tych z Q1. To oczywiście tylko szacunki; wkrótce przekonamy się, jak to faktycznie będzie działać.
„Wkrótce” nie oznacza jednak tego tygodnia ani niczego w tym stylu.
06.08 18:28
[#90]
Re: PiStorm and Warp3D
@MagicSN, post #89
Problem z Pi5 jest taki, że GPIO jest wystawione jako osobny chip na szynie PCIE która jakkolwiek ma dużą przepustowość ma też duże opóźnienia. Nie robiłem z układem, to nie wiem, natomiast AI po zapytaniu twierdzi, że w Agilex 5 SoC rdzeń "hard cpu" czyli fizyczny rdzeń ARM Cortex A76+A55 (+ peryferia jak USB) połączone są z FPGA inną szyną o dużo niższych opóźnieniach co teoretycznie powinno ogarnąć sprawę. Teoretycznie, bo jak pisałem nie jestem w to zaangażowany chociaż sam układ jest dla mnie ciekawy.
Jeśli zaś chodzi o rozwój 3D na PiStorm to dla mnie nie ma nic interesującego. No może jeśli będzie GemRB... "EE" co prawda mają swój urok, ale taki Baldur czy IWD na klasycznej Amidze... oj grałbym namiętnie jak w The Settlers II. A akurat GemRB (czy IE ogółem) wykorzystuje częściowo funkcje 3D choć sama gra jest w rzucie izometrycznym.
Jeśli zaś chodzi o rozwój 3D na PiStorm to dla mnie nie ma nic interesującego. No może jeśli będzie GemRB... "EE" co prawda mają swój urok, ale taki Baldur czy IWD na klasycznej Amidze... oj grałbym namiętnie jak w The Settlers II. A akurat GemRB (czy IE ogółem) wykorzystuje częściowo funkcje 3D choć sama gra jest w rzucie izometrycznym.