Komentowana treść: Dungeon Keeper coraz bliżej
06.05 22:11
[#1]
Re: Dungeon Keeper coraz bliżej
Na UAE? Jak to "najlepsza Amiga" nie wyrabia z dziesiątkami rdzeni i niezliczoną ilością ram-u ? 
06.05 23:35
[#2]
Re: Dungeon Keeper coraz bliżej
niemniej zapotrzebowanie na ilość pamięci prawdopodobnie całkowicie przekreśla szansę uruchomienia gry na sprzęcie z chipsetem AGA
Dziwne, to 1.8 GiB pamięci to za mało, czy chodzi o gołą Amigę
Dziwne, to 1.8 GiB pamięci to za mało, czy chodzi o gołą Amigę
07.05 05:21
[#3]
Re: Dungeon Keeper coraz bliżej
@koczis, post #2
According to the authors of the PC version this should also reduce the memory footprint. Currently we are beyond 900 MB RAM. They think it should reduce it to 512 MB, with some luck to 256 MB RAM. Lower than 256 MB RAM will be impossible, so while it might be possible to get an AGA version with step 3, most AGA systems will still be locked out (independent of performance) due to memory requirements.
07.05 07:44
[#5]
Re: Dungeon Keeper coraz bliżej
@TomcioPaluszek, post #4
Tymczasem autor najprawdopodobniej portuje KeeperFX, a nie wersję z DOSa ...
A sprawdzając wymagania na GOG/KeeperFX mamy:
Ostatnia aktualizacja: 07.05.2026 07:45:29 przez Rafael/ARMO
A sprawdzając wymagania na GOG/KeeperFX mamy:
Minimum system requirements:
System: Windows (10, 11)
Processor: 1.8 GHz
Memory: 2 GB RAM
Graphics: 3D graphics card compatible with DirectX 9.0c
DirectX: DirectX 9.0c
Storage: 1 GB available space
Ostatnia aktualizacja: 07.05.2026 07:45:29 przez Rafael/ARMO
07.05 10:04
[#7]
Re: Dungeon Keeper coraz bliżej
@TomcioPaluszek, post #4
Ech. Dostępny kod źródłowy NIE MA NIC WSPÓLNEGO z tamtą wersją. Co zresztą wyjaśniałem już na a1k.org (niemieckim forum). Wybór sprowadza się do: „nie portujemy tego wcale” albo „portujemy, ale przy zachowaniu tych konkretnych wymagań”. Co wolicie?
Wymagania dotyczące wydajności prawdopodobnie wykluczą też większość sprzętu klasy AGA. Obecnie gra wydaje się w pełni grywalna na PiStorm CM4, ale nie mam pewności co do słabszych konfiguracji. Być może ostatecznie uda się ją uruchomić na Pi3 lub Vampire, ale na pewno nie na niczym słabszym.
To NIE jest problem mojego kodu, lecz kodu oryginalnego (KeeperFX). Wersja beta na MorphOS-a jeszcze do niedawna osiągała zaledwie 13 klatek na sekundę (FPS) na systemie z procesorem 1 GHz (podsunąłem autorowi kilka wskazówek, jak to poprawić, bazując na własnych doświadczeniach z portowaniem). U mnie gra osiągała 50 FPS na x1000 oraz 13 FPS na CM4 (w rozdzielczości 640x480; w 320x240 lub 320x200 powinno być szybciej, choć tam jeszcze nie mierzyłem liczby klatek).
W międzyczasie udało mi się zmniejszyć zapotrzebowanie na pamięć (o czym pisałem już w wątku dyskusyjnym) – moja konfiguracja w emulatorze UAE wskazuje obecnie na zużycie rzędu 280 MB (pierwotnie było to 950 MB); wynik ten osiągnąłem, rezygnując z bibliotek SDL2 i OpenAL oraz wprowadzając system buforowania plików dźwiękowych. Mimo to systemy wyposażone w 512 MB pamięci wciąż zdawały się mieć problemy, gdy tylko w grę wchodziły muzyka i dialogi głosowe – w przypadku mniejszej ilości pamięci konieczne może więc okazać się ich wyłączenie (udostępniłem w tym celu odpowiednią zmienną środowiskową).
Czasy ładowania wciąż stanowią problem (system plików PFS3 kiepsko sprawdza się w przypadku portów z PC – SFS radzi sobie znacznie lepiej), ale zajmę się tą kwestią w najbliższym czasie.
W międzyczasie przygotowałem również wersję wykonywalną pod system WarPPC (WarPOS), brakuje mi jednak chętnych do jej przetestowania. Proszę mieć na uwadze, że wersja ta wymaga co najmniej karty rozszerzeń z procesorem G3/G4 oraz 300 MB pamięci RAM.
Wymagania dotyczące wydajności prawdopodobnie wykluczą też większość sprzętu klasy AGA. Obecnie gra wydaje się w pełni grywalna na PiStorm CM4, ale nie mam pewności co do słabszych konfiguracji. Być może ostatecznie uda się ją uruchomić na Pi3 lub Vampire, ale na pewno nie na niczym słabszym.
To NIE jest problem mojego kodu, lecz kodu oryginalnego (KeeperFX). Wersja beta na MorphOS-a jeszcze do niedawna osiągała zaledwie 13 klatek na sekundę (FPS) na systemie z procesorem 1 GHz (podsunąłem autorowi kilka wskazówek, jak to poprawić, bazując na własnych doświadczeniach z portowaniem). U mnie gra osiągała 50 FPS na x1000 oraz 13 FPS na CM4 (w rozdzielczości 640x480; w 320x240 lub 320x200 powinno być szybciej, choć tam jeszcze nie mierzyłem liczby klatek).
W międzyczasie udało mi się zmniejszyć zapotrzebowanie na pamięć (o czym pisałem już w wątku dyskusyjnym) – moja konfiguracja w emulatorze UAE wskazuje obecnie na zużycie rzędu 280 MB (pierwotnie było to 950 MB); wynik ten osiągnąłem, rezygnując z bibliotek SDL2 i OpenAL oraz wprowadzając system buforowania plików dźwiękowych. Mimo to systemy wyposażone w 512 MB pamięci wciąż zdawały się mieć problemy, gdy tylko w grę wchodziły muzyka i dialogi głosowe – w przypadku mniejszej ilości pamięci konieczne może więc okazać się ich wyłączenie (udostępniłem w tym celu odpowiednią zmienną środowiskową).
Czasy ładowania wciąż stanowią problem (system plików PFS3 kiepsko sprawdza się w przypadku portów z PC – SFS radzi sobie znacznie lepiej), ale zajmę się tą kwestią w najbliższym czasie.
W międzyczasie przygotowałem również wersję wykonywalną pod system WarPPC (WarPOS), brakuje mi jednak chętnych do jej przetestowania. Proszę mieć na uwadze, że wersja ta wymaga co najmniej karty rozszerzeń z procesorem G3/G4 oraz 300 MB pamięci RAM.
07.05 10:15
[#8]
Re: Dungeon Keeper coraz bliżej
@BULI, post #6
Osobiście uważam, że kierunkiem, w którym podąży rynek 68k – przynajmniej w przypadku gier – będzie PiStorm. Vampire może wciąż być sensownym wyborem dla niektórych tytułów, ale nie dla wszystkich (mieli swoją szansę przy projekcie A6000, lecz ją zmarnowali – obecność gniazda PCI zmieniłaby wszystko, umożliwiając instalację karty graficznej Radeon lub karty z procesorem PPC; karta Radeon pozostawiłaby również otwartą furtkę do rezygnacji z powolnego układu „Maggie” i wykorzystania zwolnionego miejsca na przyszłe rozszerzenia procesora).
Drugim projektem, który bacznie obserwuję, jest Demon 060 – mówi się, że osiąga on taktowanie powyżej 100 MHz. Wątpię jednak, by dorównał on prędkością rozwiązaniom opartym na PiStorm.
Jeśli chodzi o warpos – standardem dla przyszłych gier staną się procesory G3/G4. Dzięki łatwej dostępności płyt rozszerzających z magistralą PCI (tzw. *busboards*) obsługa tego standardu nie stanowi problemu i zamierzam ją zapewnić.
Złotym standardem dla deweloperów pozostają obecnie AmigaOS 4 oraz MorphOS. Ten drugi ma jednak tę wadę, że nie może być uwzględniany w umowach licencyjnych (w przypadku AmigaOS 4 oraz AmigaOS 3 – zarówno w wersji 68k, jak i warpos – system otrzymuje się w tej samej cenie co podstawową wersję AmigaOS 3).
Poważnym problemem w procesie licencjonowania gier z epoki 68k (a to właśnie w nich tkwią największe pieniądze ^^) jest fakt, że tytuły wydane przed rokiem 1996 są znacznie trudniejsze do przeniesienia na nowe platformy. Zazwyczaj zawierają one ogromne ilości kodu w asemblerze x86 oraz inne elementy, których adaptacja nastręcza wielu trudności. W czasie potrzebnym na przeniesienie jednej takiej gry można przygotować porty trzech innych tytułów dla systemów OS 4 i PiStorm (a być może nawet dla Vampire). I nie mam tu na myśli prostych, bezpośrednich konwersji, lecz porty wzbogacone o liczne optymalizacje.
Dla rynku gier na Amigę najlepszym scenariuszem byłoby jak najszersze przyjęcie standardów AmigaOS 4, PiStorm oraz warpos (w wariantach G3/G4). System MorphOS wciąż może być wspierany za pośrednictwem warpos (czyli w trybie AmigaOS 3.x ^^). Przynajmniej dopóty, dopóki nie wchodzą w grę gry trójwymiarowe (choć – bądź co bądź – wszystkie tytuły, które w obecnych realiach mają sens na tej platformie, i tak będą grami dwuwymiarowymi).
Nie faworyzuję jednak żadnego konkretnego systemu. Po prostu przenoszę daną grę na nową platformę, wprowadzam optymalizacje w takim zakresie, na jaki pozwala rozsądny nakład pracy – a następnie sprawdzam, na jakich konfiguracjach sprzętowych gra ta działa poprawnie. Właśnie z tego powodu minimalne wymagania sprzętowe dla moich gier bywają zróżnicowane.
W projekcie warpos pokładam zresztą OGROMNE nadzieje.
Drugim projektem, który bacznie obserwuję, jest Demon 060 – mówi się, że osiąga on taktowanie powyżej 100 MHz. Wątpię jednak, by dorównał on prędkością rozwiązaniom opartym na PiStorm.
Jeśli chodzi o warpos – standardem dla przyszłych gier staną się procesory G3/G4. Dzięki łatwej dostępności płyt rozszerzających z magistralą PCI (tzw. *busboards*) obsługa tego standardu nie stanowi problemu i zamierzam ją zapewnić.
Złotym standardem dla deweloperów pozostają obecnie AmigaOS 4 oraz MorphOS. Ten drugi ma jednak tę wadę, że nie może być uwzględniany w umowach licencyjnych (w przypadku AmigaOS 4 oraz AmigaOS 3 – zarówno w wersji 68k, jak i warpos – system otrzymuje się w tej samej cenie co podstawową wersję AmigaOS 3).
Poważnym problemem w procesie licencjonowania gier z epoki 68k (a to właśnie w nich tkwią największe pieniądze ^^) jest fakt, że tytuły wydane przed rokiem 1996 są znacznie trudniejsze do przeniesienia na nowe platformy. Zazwyczaj zawierają one ogromne ilości kodu w asemblerze x86 oraz inne elementy, których adaptacja nastręcza wielu trudności. W czasie potrzebnym na przeniesienie jednej takiej gry można przygotować porty trzech innych tytułów dla systemów OS 4 i PiStorm (a być może nawet dla Vampire). I nie mam tu na myśli prostych, bezpośrednich konwersji, lecz porty wzbogacone o liczne optymalizacje.
Dla rynku gier na Amigę najlepszym scenariuszem byłoby jak najszersze przyjęcie standardów AmigaOS 4, PiStorm oraz warpos (w wariantach G3/G4). System MorphOS wciąż może być wspierany za pośrednictwem warpos (czyli w trybie AmigaOS 3.x ^^). Przynajmniej dopóty, dopóki nie wchodzą w grę gry trójwymiarowe (choć – bądź co bądź – wszystkie tytuły, które w obecnych realiach mają sens na tej platformie, i tak będą grami dwuwymiarowymi).
Nie faworyzuję jednak żadnego konkretnego systemu. Po prostu przenoszę daną grę na nową platformę, wprowadzam optymalizacje w takim zakresie, na jaki pozwala rozsądny nakład pracy – a następnie sprawdzam, na jakich konfiguracjach sprzętowych gra ta działa poprawnie. Właśnie z tego powodu minimalne wymagania sprzętowe dla moich gier bywają zróżnicowane.
W projekcie warpos pokładam zresztą OGROMNE nadzieje.
07.05 10:54
[#9]
Re: Dungeon Keeper coraz bliżej
@MagicSN, post #7
Ech. Dostępny kod źródłowy NIE MA NIC WSPÓLNEGO z tamtą wersją. Co zresztą wyjaśniałem już na a1k.org (niemieckim forum). Wybór sprowadza się do: „nie portujemy tego wcale” albo „portujemy, ale przy zachowaniu tych konkretnych wymagań”. Co wolicie?
Nie portować wcale. Ile znajdzie się chętnych na taką grę z takimi wymaganiami? Pewno można policzyć na palcach jednej ręki drwala z 25 letnim stażem pracy.
Jeśli ktoś już "upiera się o portowanie to tylko dla sportu/nauki".
07.05 11:54
[#11]
Re: Dungeon Keeper coraz bliżej
@Tomski, post #9
Cóż, oczywiście chodzi o wszystkich, którzy dysponują sprzętem o takich parametrach (czyli – jak sądzę – niemal wszystkich użytkowników Amigi, których obecnie znam). Właściwie miałem to na myśli jako pytanie retoryczne, na które odpowiedź brzmi: „zrobić port o wysokich wymaganiach”. Jak zarysowałem w moim innym wpisie, uważam, że rozwój systemów tego typu (68k i WarpOS) i tak będzie zmierzał w tym kierunku.
Rezygnacja z portowania tylko dlatego, że oprogramowanie zadziała jedynie na pewnym odsetku systemów, wydaje mi się kompletnym szaleństwem.
To naprawdę pytanie retoryczne.
Rezygnacja z portowania tylko dlatego, że oprogramowanie zadziała jedynie na pewnym odsetku systemów, wydaje mi się kompletnym szaleństwem.
To naprawdę pytanie retoryczne.
07.05 12:57
[#14]
Re: Dungeon Keeper coraz bliżej
@BULI, post #10
Ogolnie to taki port dobry programista ze wsparciem dobrego (czyli raczej platnego) AI potrafilby pewnie stworzyc w pare miesiecy, a wymagania pewnie by byly typu 128MB fast jako max.
Ale widze tez pozytywy.
W koncu moze Thor przestanie marudzic, ze pamiec HiMem jest niepotrzebna klasykowi.
link
link
Te 2GB potencjalnego RAM sie po prostu marnuja w Amiga OS.
A jak Juen sie rozpedzi to pewnie moze sie tez przydac Amelinium 1.0, czyli dobrej przegladarce WWW.
Ale widze tez pozytywy.
W koncu moze Thor przestanie marudzic, ze pamiec HiMem jest niepotrzebna klasykowi.
link
link
Te 2GB potencjalnego RAM sie po prostu marnuja w Amiga OS.
A jak Juen sie rozpedzi to pewnie moze sie tez przydac Amelinium 1.0, czyli dobrej przegladarce WWW.
07.05 13:26
[#15]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #14
Nie, nie udałoby się. Wymagania pamięciowe są bardzo wysokie (choć faktycznie udało mi się je nieco zredukować – z 950 MB do około 300 MB).
Należy również pamiętać, że zbyt duże odstępstwa od wersji PC powodują problemy przy aktualizacji do przyszłych wydań (rozwój KeeperFX jest bardzo dynamiczny). Istnieje kilka elementów, które chcielibyśmy uwzględnić w przyszłych wersjach, w tym obsługa 3DHW.
Owszem, można by napisać grę od nowa (co w zasadzie zrobili twórcy KeeperFX), ale zajęłoby to znacznie więcej czasu niż „kilka miesięcy”.
Należy również pamiętać, że zbyt duże odstępstwa od wersji PC powodują problemy przy aktualizacji do przyszłych wydań (rozwój KeeperFX jest bardzo dynamiczny). Istnieje kilka elementów, które chcielibyśmy uwzględnić w przyszłych wersjach, w tym obsługa 3DHW.
Owszem, można by napisać grę od nowa (co w zasadzie zrobili twórcy KeeperFX), ale zajęłoby to znacznie więcej czasu niż „kilka miesięcy”.
07.05 13:28
[#16]
Re: Dungeon Keeper coraz bliżej
@Tomski, post #12
Dla osób dysponujących odpowiednim sprzętem nie jest to strata czasu. Twój argument jest w zasadzie taki sam, jak twierdzenia ludzi mówiących: „Gier nie powinno się portować na AmigaOS, skoro istnieje już wersja na Windowsa”.
I pamiętajcie – platforma wciąż ewoluuje. Pociąg 68k wyrusza w kierunku PiStorm+Vampire...
Ale nie o to w ogóle chodzi. Sedno sprawy sprowadza się do tego, że gra faktycznie wymaga około 300 MB pamięci. Jeśli chcesz w nią zagrać, musisz zaktualizować system. Jeśli powiesz: „nie chcę w nią grać” – to twoja decyzja. Ale nie mów, że nie powinienem tworzyć tego portu tylko dlatego, że ty nie chcesz przeprowadzać aktualizacji. Inni dysponują wymaganym sprzętem i ucieszą się z tej konwersji. Tak to właśnie działa. I nie będzie to ostatnia gra o podwyższonych wymaganiach sprzętowych.
Nie tworzę oprogramowania pod z góry narzucone wymagania – czasem jednak okazuje się, że takie wymagania po prostu wynikają z charakteru projektu.
Twoje stanowisko, zgodnie z którym „nie powinno się tworzyć portów gier, które nie uruchomią się na moim komputerze”, jest skrajnie egoistyczne.
Ostatnia aktualizacja: 07.05.2026 13:28:59 przez MagicSN
Ostatnia aktualizacja: 07.05.2026 13:36:03 przez MagicSN
I pamiętajcie – platforma wciąż ewoluuje. Pociąg 68k wyrusza w kierunku PiStorm+Vampire...
Ale nie o to w ogóle chodzi. Sedno sprawy sprowadza się do tego, że gra faktycznie wymaga około 300 MB pamięci. Jeśli chcesz w nią zagrać, musisz zaktualizować system. Jeśli powiesz: „nie chcę w nią grać” – to twoja decyzja. Ale nie mów, że nie powinienem tworzyć tego portu tylko dlatego, że ty nie chcesz przeprowadzać aktualizacji. Inni dysponują wymaganym sprzętem i ucieszą się z tej konwersji. Tak to właśnie działa. I nie będzie to ostatnia gra o podwyższonych wymaganiach sprzętowych.
Nie tworzę oprogramowania pod z góry narzucone wymagania – czasem jednak okazuje się, że takie wymagania po prostu wynikają z charakteru projektu.
Twoje stanowisko, zgodnie z którym „nie powinno się tworzyć portów gier, które nie uruchomią się na moim komputerze”, jest skrajnie egoistyczne.
Ostatnia aktualizacja: 07.05.2026 13:28:59 przez MagicSN
Ostatnia aktualizacja: 07.05.2026 13:36:03 przez MagicSN
07.05 14:50
[#17]
Re: Dungeon Keeper coraz bliżej
@MagicSN, post #15
Ja nie pisalem, ze ten programista ma w calosci, uzywac silnika KeeperFX.
Wykorzystujac odpowiednio AI da sie zrobic mix wersji PC z ta wersja.
I to sie da zrobic, uzywajac AI do transcodingu logiki gry z x86 na 68k.
Pewnie do C tez by mozna transkodowac, tylko to raczej zwiekszy wymagania portu.
AI dziala w zasadzie blyskawicznie, tylko musi byc kontrola kogos kto sie dobrze zna na programowaniu.
Wiec w pare miesiecy bez problemu to jest do osiagniecia.
Ta gra, oryginal PC (cala) miesci sie w 128MB fast, i sporo zostanie.
Wykorzystujac odpowiednio AI da sie zrobic mix wersji PC z ta wersja.
I to sie da zrobic, uzywajac AI do transcodingu logiki gry z x86 na 68k.
Pewnie do C tez by mozna transkodowac, tylko to raczej zwiekszy wymagania portu.
AI dziala w zasadzie blyskawicznie, tylko musi byc kontrola kogos kto sie dobrze zna na programowaniu.
Wiec w pare miesiecy bez problemu to jest do osiagniecia.
Ta gra, oryginal PC (cala) miesci sie w 128MB fast, i sporo zostanie.
07.05 15:41
[#18]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #17
Potrzebowałbyś kodu źródłowego oryginalnej gry, który nie jest dostępny. Ponadto takie rozwiązanie nie obsługiwałoby systemów OS4 ani Warp OS, a także nie zapewniłoby dodatkowych funkcji oferowanych przez KeeperFX (takich jak, na przykład, wyższa rozdzielczość). Zatem nie – nie zgadzam się; nie jest to możliwe.
AI is not a magic wand.
Ostatnia aktualizacja: 07.05.2026 15:42:16 przez MagicSN
AI is not a magic wand.
Ostatnia aktualizacja: 07.05.2026 15:42:16 przez MagicSN
07.05 16:03
[#19]
Re: Dungeon Keeper coraz bliżej
@MagicSN, post #18
A niby co za trudnosc uzyc dobrego AI do dekompilacji oryginalnego exeka PC-towego?
Nawet taki dosc stary projekt jak Hex Rays to potrafi:
link
Wiekszosc starszych programow PC byla kompilowana bodaj z uzyciem Borland C++.
link
Wiec ze wsparciem AI to powinno byc dosc proste.
A dodatkowe funkcje (typu wieksza rozdzielczosc) mozna dodac pozniej samemu.
Nawet taki dosc stary projekt jak Hex Rays to potrafi:
link
Wiekszosc starszych programow PC byla kompilowana bodaj z uzyciem Borland C++.
link
Wiec ze wsparciem AI to powinno byc dosc proste.
A dodatkowe funkcje (typu wieksza rozdzielczosc) mozna dodac pozniej samemu.
07.05 17:15
[#20]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #19
"AI zrobi to w kilka miesięcy" zaczyna powoli brzmieć jak współczesna wersja: "wystarczy przepisać pod Amigę" ...
Ludzie często nie rozumieją różnicy między: dekompilacją, reverse engineeringiem, a utrzymywalnym portem działającym na kilku systemach i zgodnym z przyszłymi wersjami upstreamu.
Hex-Rays potrafi wygenerować pseudo-C, ale od tego do sensownego kodu produkcyjnego jest jeszcze bardzo długa droga - szczególnie przy starych grach pełnych asm-a, hacków czasowych i własnych systemów pamięci.
Gdyby to było takie proste, Internet byłby już pełen natywnych portów wszystkich gier DOS/Win95 na 68k ;)
No ale może się mylę i skoro to według Ciebie kwestia "paru miesięcy z AI", to może warto samemu spróbować i pokazać działający proof-of-concept?
Ludzie często nie rozumieją różnicy między: dekompilacją, reverse engineeringiem, a utrzymywalnym portem działającym na kilku systemach i zgodnym z przyszłymi wersjami upstreamu.
Hex-Rays potrafi wygenerować pseudo-C, ale od tego do sensownego kodu produkcyjnego jest jeszcze bardzo długa droga - szczególnie przy starych grach pełnych asm-a, hacków czasowych i własnych systemów pamięci.
Gdyby to było takie proste, Internet byłby już pełen natywnych portów wszystkich gier DOS/Win95 na 68k ;)
No ale może się mylę i skoro to według Ciebie kwestia "paru miesięcy z AI", to może warto samemu spróbować i pokazać działający proof-of-concept?
07.05 18:07
[#22]
Re: Dungeon Keeper coraz bliżej
@Rafael/ARMO, post #5
Tymczasem autor najprawdopodobniej portuje KeeperFX, a nie wersję z DOSa ...
No to tytuł newsa mnie wprowadził mocno w błąd, bo ta gra ma zupełnie inne wymagania i z tego co czytałem w tym wątku to autorom udało się sporo ośiągnąć by gra była grywalna na Emu68. Mój Pistorm czeka z niecierpliwością i nawet go podkręcę by mieć 14 fps, a nie 13, bo 13 to raczej pechowa liczba.
07.05 18:16
[#23]
Re: Dungeon Keeper coraz bliżej
@koczis, post #22
Chociaż nie przeprowadzono testu na podkręconych systemach, gra działa z prędkością 13 kl./s przy taktowaniu 1,5 GHz, więc na podkręconym systemie powinna być zauważalnie szybsza. Dotyczy to rozdzielczości 640x480 (chociaż mój beta tester stwierdził, że gra jest naprawdę grywalna przy takiej prędkości), a w rozdzielczości 320x240 lub 320x200 – jak w oryginale – spodziewam się szybszej. Obecnie mam problemy z moim systemem PiStorm, więc nie mogę sam tego przetestować (mój działa na 2,2 GHz). Na UAE uzyskuję 35 kl./s przy 320x240 i 22 kl./s przy 640x480, więc w niskiej rozdzielczości jest zauważalnie szybciej.
Oceniam również, jak łatwo byłoby zastąpić obecne ładowanie plików zip metodą „rozpakuj raz, a następnie załaduj jako pliki” – co byłoby łatwiejsze w systemach z systemem plików PFS3 (w systemie plików SFS jest to naturalnie szybsze ze względu na wyższą prędkość wyszukiwania). Myślę/mam nadzieję, że da się to zrobić bez zbytniego modyfikowania kodu (więc aktualizacja do nowszych wersji Keeperfx jest nadal możliwa).
Ostatnia aktualizacja: 07.05.2026 18:18:45 przez MagicSN
Oceniam również, jak łatwo byłoby zastąpić obecne ładowanie plików zip metodą „rozpakuj raz, a następnie załaduj jako pliki” – co byłoby łatwiejsze w systemach z systemem plików PFS3 (w systemie plików SFS jest to naturalnie szybsze ze względu na wyższą prędkość wyszukiwania). Myślę/mam nadzieję, że da się to zrobić bez zbytniego modyfikowania kodu (więc aktualizacja do nowszych wersji Keeperfx jest nadal możliwa).
Ostatnia aktualizacja: 07.05.2026 18:18:45 przez MagicSN
07.05 18:50
[#24]
Re: Dungeon Keeper coraz bliżej
@Rafael/ARMO, post #20
Dobre AI zrobi to duzo szybciej niz w pare miesiecy.
Dungeon Keeper to w miare nowa gra na PC, wstawek ASM x86 raczej tam nie ma.
Wiec czyste zrodla C sa do odzyskania jak najbardziej.
C w ogole mnie nie interesuje jako takie.
Ale powiem Ci jak ja bym sie za to zabral jesli bym cos takiego robil.
1. Bierzesz jakas w miare prosta gre PC ze zrodlami, np. polski RTS "Polanie".
2. Kompilujesz te zrodla starym kompilatorem (najlepiej oryginalnym od Borlanda czy jaki tam jest podany w zrodlach gry).
3. Sprawdzasz czy po kompilacji ten exek dziala i czy jest taki sam jak oryginal .
Najlepiej jakby sie dalo tak wszystkie opcje w kompilatorze ustawic, zeby uzyskac oryginalny plik exe.
4. Jak ten PC exek dziala, zaczynasz jego dekompilacje.
5. Dekompilujesz albo Hex Rays do pseudo C i poprawki robi AI, albo od razu tylko AI do C.
Czyli po prostu trenujesz AI az odtworzy kod C, ktory po kompilacji tworzy oryginalny exek.
Zajmie to AI troche czasu, ale jest do zrobienia.
6. Potem jeszcze z 1 lub 2 programy PC-towe ta sama metoda traktujesz.
7. Dopiero jak efekty takiej dekompilacji sa ok, czyli otrzymujesz prawidlowe zrodla w C, to bierzesz sie za dekompilacje Dungeon Keeper czy innej gry z PC.
Dungeon Keeper to w miare nowa gra na PC, wstawek ASM x86 raczej tam nie ma.
Wiec czyste zrodla C sa do odzyskania jak najbardziej.
C w ogole mnie nie interesuje jako takie.
Ale powiem Ci jak ja bym sie za to zabral jesli bym cos takiego robil.
1. Bierzesz jakas w miare prosta gre PC ze zrodlami, np. polski RTS "Polanie".
2. Kompilujesz te zrodla starym kompilatorem (najlepiej oryginalnym od Borlanda czy jaki tam jest podany w zrodlach gry).
3. Sprawdzasz czy po kompilacji ten exek dziala i czy jest taki sam jak oryginal .
Najlepiej jakby sie dalo tak wszystkie opcje w kompilatorze ustawic, zeby uzyskac oryginalny plik exe.
4. Jak ten PC exek dziala, zaczynasz jego dekompilacje.
5. Dekompilujesz albo Hex Rays do pseudo C i poprawki robi AI, albo od razu tylko AI do C.
Czyli po prostu trenujesz AI az odtworzy kod C, ktory po kompilacji tworzy oryginalny exek.
Zajmie to AI troche czasu, ale jest do zrobienia.
6. Potem jeszcze z 1 lub 2 programy PC-towe ta sama metoda traktujesz.
7. Dopiero jak efekty takiej dekompilacji sa ok, czyli otrzymujesz prawidlowe zrodla w C, to bierzesz sie za dekompilacje Dungeon Keeper czy innej gry z PC.
08.05 08:39
[#25]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #24
Samo założenie: "na pewno używali Borlanda i da się odtworzyć idealny pipeline kompilacji" jest już trochę życzeniowe.
W tamtym okresie DOS-owe gry powstawały przy użyciu bardzo różnych kompilatorów/środowisk: Watcom C/C++, Visual C++, Borland/Turbo C++, Symantec C++, DJGPP, a często także wewnętrznych narzędzi i własnych build-scriptów.
Do tego dochodzą: nieznane wersje kompilatora, różne poziomy optymalizacji, custom linkery, ręczne poprawki ASM, biblioteki (np. linkowane statycznie) oraz środowisko budowy, którego dziś już zwykle nie da się wiernie odtworzyć.
A bez identycznego pipeline’u nawet mając źródła często trudno wygenerować binarkę 1:1, więc oczekiwanie, że AI "odzyska idealne źródła z exe", jest mocno optymistyczne.
W tamtym okresie DOS-owe gry powstawały przy użyciu bardzo różnych kompilatorów/środowisk: Watcom C/C++, Visual C++, Borland/Turbo C++, Symantec C++, DJGPP, a często także wewnętrznych narzędzi i własnych build-scriptów.
Do tego dochodzą: nieznane wersje kompilatora, różne poziomy optymalizacji, custom linkery, ręczne poprawki ASM, biblioteki (np. linkowane statycznie) oraz środowisko budowy, którego dziś już zwykle nie da się wiernie odtworzyć.
A bez identycznego pipeline’u nawet mając źródła często trudno wygenerować binarkę 1:1, więc oczekiwanie, że AI "odzyska idealne źródła z exe", jest mocno optymistyczne.
08.05 09:56
[#27]
Re: Dungeon Keeper coraz bliżej
@MagicSN, post #16
Pociąg 68k wyrusza w kierunku PiStorm+Vampire
Nie sądzę. Jak nie znajdziesz programistów, to się skończy jak z Amigą NG. A nie znajdziesz programistów. Będziesz więc miał co najwyżej porty 30. letnich gier z wymaganiami z sufity.
Ja to mam nadzieję, że wrócą do golasów, może z CD-ROM-em lub inną niedyskietkową pamięcią masową. Albo co najwyżej z HDD. Ale ja uważam Amigę za komputer retro. A jak mam grać w "Dungeon Keepera", to mam od tego Pentium IV z 17'' CRT i Win9x obok. Kiedys takie zestawy można było kupić za dosłownie paczkę fajek i zgrzewkę piwa, ale dawno już ceny poszły w górę - ale to i tak rząd wielkości mniej, niż te nowoczesne wynalazki do Amigi.
Ostatnia aktualizacja: 08.05.2026 09:59:53 przez freak_outXP
08.05 13:11
[#30]
Re: Dungeon Keeper coraz bliżej
@Rafael/ARMO, post #25
Widac, ze nie przegladales nigdy starych exekow z PC-ta.
Bo niby skad ja wiem, ze to Borland, skoro PC-ta w zasadzie nie uzywalem?
Czesc programow kompilujacych lubi wstawiac swoj ID do programu.
I Borland wstawial taki swoj ID, cos tam "Borland 19xx"
Na Macu to CodeWarrior wstawial swoj ID.
A na Amidze niedawno znalazlem to:
GCC: (GNU) 14.2.0
Dlatego najpiierw sie zaczyna od prostszych programow, do ktorych sa oryginalne zrodla.
Na pewno AI z pomoca dobrego programisty moze odtworzyc zrodla w C, tylko kwestia jest czas jaki potrzebuje, zeby to zrobic.
W przypadku, gdyby chodzilo tylko o deasemblacje i transkoding na 68k, to w ogole jest juz dosc latwe.
No ale wiadomo PPC potrzebuje zrodel w C, wiec najprostsze rozwiazanie dla Amigi klasycznej odpada.
Bo niby skad ja wiem, ze to Borland, skoro PC-ta w zasadzie nie uzywalem?
Czesc programow kompilujacych lubi wstawiac swoj ID do programu.
I Borland wstawial taki swoj ID, cos tam "Borland 19xx"
Na Macu to CodeWarrior wstawial swoj ID.
A na Amidze niedawno znalazlem to:
GCC: (GNU) 14.2.0
Dlatego najpiierw sie zaczyna od prostszych programow, do ktorych sa oryginalne zrodla.
Na pewno AI z pomoca dobrego programisty moze odtworzyc zrodla w C, tylko kwestia jest czas jaki potrzebuje, zeby to zrobic.
W przypadku, gdyby chodzilo tylko o deasemblacje i transkoding na 68k, to w ogole jest juz dosc latwe.
No ale wiadomo PPC potrzebuje zrodel w C, wiec najprostsze rozwiazanie dla Amigi klasycznej odpada.