Komentowana treść: Dungeon Keeper coraz bliżej
10.05 11:57
[#62]
Re: Dungeon Keeper coraz bliżej
@MagicSN, post #60
Istnieje wersja Diablo na Mac PPC a nie na Maca 68k.
Kolejnosc bajtow w grach PC-towych, zawsze jest taka sama, czyli odwrotna niz na Amidze i to zawsze trzeba brac pod uwage jak sie przerabia/portuje cos z PC-ta.
I nie, nawet majac oryginalne zrodla gry nie oznacza to, ze nie bedzie z LE zadnych problemow po kompilacji.
Prosty przyklad to HOMM2, oryginalna wersja na Maca 68k ma pare bledow LE, poprawionych dopiero w wersji Amigowej przez meynafa.
Dla MacOS 10.15 tez istnieje Dungeon Keeper.
link
Wiec nie powinienies miec wiekszego problemu.
Kolejnosc bajtow w grach PC-towych, zawsze jest taka sama, czyli odwrotna niz na Amidze i to zawsze trzeba brac pod uwage jak sie przerabia/portuje cos z PC-ta.
I nie, nawet majac oryginalne zrodla gry nie oznacza to, ze nie bedzie z LE zadnych problemow po kompilacji.
Prosty przyklad to HOMM2, oryginalna wersja na Maca 68k ma pare bledow LE, poprawionych dopiero w wersji Amigowej przez meynafa.
Dla MacOS 10.15 tez istnieje Dungeon Keeper.
link
Wiec nie powinienies miec wiekszego problemu.
10.05 19:59
[#66]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #62
Tak, ale łatwiej to zrobić, mając czytelny kod źródłowy. Jak wyjaśniłem powyżej – powodem powolnego portu Keeperfx są właśnie zdekompilowane źródła 
A do wszystkich, którzy naśmiewali się z mojego portu Dungeonkeepera z 13 fps:
Aktualna wersja Beta8:
35 fps w rozdzielczości 640x480 na procesorze PiStorm CM4 1,5 GHz.
Powinniście nauczyć się różnicy między wersją beta a wersją bez bety (a to wciąż beta – spodziewam się, że będzie jeszcze szybsza, choć prawdopodobnie nie będzie to już TAK duża zmiana, jak z 13 do 35 fps).
Dla porównania, port MorphOS na sprzęcie Mirari osiąga 40 fps w rozdzielczości 640x480. Chcę to pobić – na PiStorm Zobaczymy, czy mi się uda.
Ostatnia aktualizacja: 10.05.2026 20:01:03 przez MagicSN
A do wszystkich, którzy naśmiewali się z mojego portu Dungeonkeepera z 13 fps:
Aktualna wersja Beta8:
35 fps w rozdzielczości 640x480 na procesorze PiStorm CM4 1,5 GHz.
Powinniście nauczyć się różnicy między wersją beta a wersją bez bety (a to wciąż beta – spodziewam się, że będzie jeszcze szybsza, choć prawdopodobnie nie będzie to już TAK duża zmiana, jak z 13 do 35 fps).
Dla porównania, port MorphOS na sprzęcie Mirari osiąga 40 fps w rozdzielczości 640x480. Chcę to pobić – na PiStorm
Zobaczymy, czy mi się uda.Ostatnia aktualizacja: 10.05.2026 20:01:03 przez MagicSN
10.05 20:43
[#67]
Re: Dungeon Keeper coraz bliżej
@MagicSN, post #66
Dla porównania, port MorphOS na sprzęcie Mirari osiąga 40 fps w rozdzielczości 640x480. Chcę to pobić – na PiStorm Zobaczymy, czy mi się uda.
Port na MorphOS robi Yannick "Papiosaur", który, jak mi się wydaje nie ma dużego doświadczenia w portowaniu. Gdyby tego podjął się BeWorld to sprawa wyglądała by pewnie zupełnie inaczej.
Port na MorphOS robi Yannick "Papiosaur", który, jak mi się wydaje nie ma dużego doświadczenia w portowaniu. Gdyby tego podjął się BeWorld to sprawa wyglądała by pewnie zupełnie inaczej.
11.05 14:52
[#71]
Re: Dungeon Keeper coraz bliżej
@MagicSN, post #66
No chyba nie w tym problem.
"Originally, KeeperFX started out as a decompilation project, where we took the original game executables and reversed them back into usable code. Currently the whole codebase of Dungeon Keeper is remade and all code has been rewritten."
Tam nie powinno byc juz zdekompilowanych zrodel.
Tylko przerobione.
Raczej autor KeeperFX nie ma doswiadczenia w programowaniu na czyms innym jak Linux i PC, co widac po ilosci pamieci potrzebnej wczesniej.
W kazdym razie gratulacje za poprawki.
"Originally, KeeperFX started out as a decompilation project, where we took the original game executables and reversed them back into usable code. Currently the whole codebase of Dungeon Keeper is remade and all code has been rewritten."
Tam nie powinno byc juz zdekompilowanych zrodel.
Tylko przerobione.
Raczej autor KeeperFX nie ma doswiadczenia w programowaniu na czyms innym jak Linux i PC, co widac po ilosci pamieci potrzebnej wczesniej.
W kazdym razie gratulacje za poprawki.
11.05 19:34
[#72]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #57
Z tego co ja wiem to gry na PC-cie, byly tworzone glownie w Borland C.
A dlaczego?
Bo to byl bardzo dobry kompilator, generujacy duzo lepszy kod niz owczesne Amigowe kompilatory C.
Tak twierdzi meynaf, bo ja sie na C nie znam.
Tylko z tego co można sobie sprawdzić historycznie to właśnie nie Borland C był tym najpopularniejszym w GameDevie DOSosowym w tamtym okresie ale Watcom "Around 1993–1996, nearly all DOS games were developed with Watcom C". Ale to nie ma znaczenia.
Wiem, ze troche gier na PC-cie bylo pisanych w ASM x86, ale bardzo malo. Z pamieci to Biing czy TeenAgent.
Oczywiscie, ze nie da sie odzyskac identycznych zrodel C, bo nie bedzie komentarzy, inne beda nazwy itp
Ale dzialajacy tak samo kod da sie w pelni odtworzyc.
I właśnie tutaj widać różnicę między: "program działa" a "odzyskaliśmy kod źródłowy".
Kod źródłowy w C/C++ to nie jest tylko semantycznie działający ciąg instrukcji. Ogromną częścią wartości projektu są: struktura kodu, podział logiki, abstrakcje, czytelność, nazewnictwo zmiennych i funkcji, komentarze, oraz sam sposób implementacji algorytmów. To wszystko w dużym stopniu ginie podczas kompilacji i optymalizacji.
A jak wspominasz już któryś raz
bo ja sie na C nie znamto właśnie mogą Ci takie aspekty umykać, a dla mnie i w pewnie większości programistów z wieloletnim stażem w C/C++ (i innych języków wysokiego poziomu) to są fundamentalne sprawy o których nieraz wspominają/wspominali twórcy tych języków (jak choćby Bjarne Stroustrup, polecam zapoznać się z określeniem "Clean Code").
Prosty przyklad to Diablo, dzialajacy kod zostal odtworzony z exeka gry.
Ten kto to odtwarzal mial o tyle latwiej, ze do exeka byl dolaczony hunk z nazwami procedur, czyli exek byl bodaj w trybie debug.
Tylko przykład Diablo akurat bardziej potwierdza moje argumenty. To był wielomiesięczny, ręczny reverse engineering, dodatkowo mocno ułatwiony przez obecność symboli/debug info w binarce. I właśnie fakt, że symbole/debug hunki tak bardzo pomagają, pokazuje ile informacji normalnie ginie podczas kompilacji.
Ostatnia aktualizacja: 11.05.2026 19:49:04 przez Rafael/ARMO
11.05 20:47
[#73]
Re: Dungeon Keeper coraz bliżej
@Rafael/ARMO, post #72
Zawsze mozna na poczatek zajac sie dekompilacja gier/programow, ktore maja symbole/hunki dolaczone do exeka, troche ich bylo, czasami niestandardowej wersji jezykowej trzeba poszukac, bo angielskie zwykle nie maja.
Kiedys na EAB bodaj pisali, ze francuska wersja jakiejs znanej gry PC miala debug dolaczony.
Lista gier na PSX z debug symbols, chyba te zrodla Diablo to z PSX byly:
link
Dzieki Tobie znalazlem te strone, ma calkiem ciekawe informacje:
link
Nawet Viewer do ILBM pod WWW ta strona posiada.
Oczywiscie na PC, zawsze mozna tez deasemblowac exeki:
link
A co do Diablo, to dekompilowal exek czlowiek, a nie AI, dlatego to tyle trwalo.
A mi chodzi o dekompilacje przez AI lub przez program napisany przez AI.
Obecnie to jak patrze jak szybko dziala ten deasembler 68k (Amiga, ST, moze Mac tez bedzie) napisany w 2 miesiace przez AI, to wole nie tracic czasu na pelna deasemblacje.
W 1 sekunde robi wiecej, niz ja recznie przez wiele godzin.
A Watcom C to raczej juz pozniejsze czasy, pewnie po 1996 roku, kiedy Microsoft wykonczyl juz Borland C, przejmujac najlepszych programistow.
link
Ostatnia aktualizacja: 11.05.2026 20:48:53 przez Don_Adan
Kiedys na EAB bodaj pisali, ze francuska wersja jakiejs znanej gry PC miala debug dolaczony.
Lista gier na PSX z debug symbols, chyba te zrodla Diablo to z PSX byly:
link
Dzieki Tobie znalazlem te strone, ma calkiem ciekawe informacje:
link
Nawet Viewer do ILBM pod WWW ta strona posiada.
Oczywiscie na PC, zawsze mozna tez deasemblowac exeki:
link
A co do Diablo, to dekompilowal exek czlowiek, a nie AI, dlatego to tyle trwalo.
A mi chodzi o dekompilacje przez AI lub przez program napisany przez AI.
Obecnie to jak patrze jak szybko dziala ten deasembler 68k (Amiga, ST, moze Mac tez bedzie) napisany w 2 miesiace przez AI, to wole nie tracic czasu na pelna deasemblacje.
W 1 sekunde robi wiecej, niz ja recznie przez wiele godzin.
A Watcom C to raczej juz pozniejsze czasy, pewnie po 1996 roku, kiedy Microsoft wykonczyl juz Borland C, przejmujac najlepszych programistow.
link
Ostatnia aktualizacja: 11.05.2026 20:48:53 przez Don_Adan
12.05 16:26
[#74]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #73
Oto aktualna wersja Dungeonkeepera dla AmigaOS4: https://www.youtube.com/watch?v=9X9w1tXu590
Działa na AmigaOne x5000 w rozdzielczości 1440x900.
Następne prace będą dotyczyć wersji Warpos.
Uwaga: Stworzyłem eksperymentalną wersję wieloosobową (nie jestem pewien, czy jeszcze działa).
Działa na AmigaOne x5000 w rozdzielczości 1440x900.
Następne prace będą dotyczyć wersji Warpos.
Uwaga: Stworzyłem eksperymentalną wersję wieloosobową (nie jestem pewien, czy jeszcze działa).
14.05 21:37
[#75]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #30
Przeniosłem zmiany w kodzie z Dungeonkeepera 1.3.2 Stable do wersji 1.4 Alpha (head-of-git). Spowodowało to zmianę w zużyciu pamięci. Wczytanie pierwszego poziomu wymaga teraz tylko 204 MB zamiast 230 MB. To nie są optymalizacje, które sam wprowadziłem; po prostu wydaje się, że 1.4 Alpha potrzebuje mniej pamięci. Jednak 1.4 Alpha obecnie nie obsługuje trybu wieloosobowego dla AmigaOS. Biblioteka enet jest do tego wymagana od wersji 1.4 Alpha; muszę sprawdzić, czy jest przenośna.
Podczas instalacji kolejnej wersji beta Dungeonkeepera będziesz mieć możliwość zainstalowania wersji 1.3.2 Stable lub 1.4.0 Alpha.
Dlaczego wersja Papiosaur na MorphOS, według niego, potrzebuje tylko 128 MB, nie mam pojęcia. A kiedy go zapytałem, powiedział, że nie zrobił nic specjalnego, aby zmniejszyć zapotrzebowanie na pamięć.
Następnym krokiem dla mnie będzie wersja WarpOS i wersja AROS64 (wersja 1.4.0 Alpha obsługuje architekturę 64-bitową).
Podczas instalacji kolejnej wersji beta Dungeonkeepera będziesz mieć możliwość zainstalowania wersji 1.3.2 Stable lub 1.4.0 Alpha.
Dlaczego wersja Papiosaur na MorphOS, według niego, potrzebuje tylko 128 MB, nie mam pojęcia. A kiedy go zapytałem, powiedział, że nie zrobił nic specjalnego, aby zmniejszyć zapotrzebowanie na pamięć.
Następnym krokiem dla mnie będzie wersja WarpOS i wersja AROS64 (wersja 1.4.0 Alpha obsługuje architekturę 64-bitową).
14.05 22:58
[#76]
Re: Dungeon Keeper coraz bliżej
@MagicSN, post #75
Wedlug mnie sa najbardziej prawdopodobne 3 mozliwosci:
1. alokujesz pamiec, ktora jest nieuzywana przez gre
2. port na MorphOS uzywa tego samego obszaru pamieci wielokrotnie na dane, ktore sa dedykowane tylko danemu poziomowi gry, czyli po prostu dane z levelu 2, wczytywane sa w miejsce danych levelu 1, a dane levelu 1 wczytywane sa w miejsce intra gry.
To samo moze dotyczyc przerywnikow miedzy poziomami, o ile takie sa w tej grze.
3. jakas bardzo duza tablica lub tablice da sie skrocic o polowe przy odpowiedniej kompilacji zrodel
1. alokujesz pamiec, ktora jest nieuzywana przez gre
2. port na MorphOS uzywa tego samego obszaru pamieci wielokrotnie na dane, ktore sa dedykowane tylko danemu poziomowi gry, czyli po prostu dane z levelu 2, wczytywane sa w miejsce danych levelu 1, a dane levelu 1 wczytywane sa w miejsce intra gry.
To samo moze dotyczyc przerywnikow miedzy poziomami, o ile takie sa w tej grze.
3. jakas bardzo duza tablica lub tablice da sie skrocic o polowe przy odpowiedniej kompilacji zrodel
15.05 20:27
[#77]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #76
Ani AmigaOS, ani MorphOS (w międzyczasie miałem też kod źródłowy wersji MorphOS) nie dotyka żadnego z wymienionych przez Ciebie obszarów. Moje najprawdopodobniejsze podejrzenie jest takie, że to coś wewnętrznego SDL lub innej biblioteki. Przy okazji, poza AmigaOS, w międzyczasie uruchomiłem również wersję AROS 64-bit.
17.05 13:51
[#80]
Re: Dungeon Keeper coraz bliżej
@MagicSN, post #79
Jak dla mnie potrzebne ~128MB wiecej RAM w implementacji SDL w podobnych systemach operacyjnych, swiadczy albo o bardzo slabej implementacji SDL , albo o jakims bledzie typu "memory leak".
I tyle, po prostu bezsensowne marnowanie pamieci, chyba ze wersja SDL dla AmigaOS ma cos czego nie ma wersja MorphOS.
Ostatnia aktualizacja: 17.05.2026 13:52:28 przez Don_Adan
I tyle, po prostu bezsensowne marnowanie pamieci, chyba ze wersja SDL dla AmigaOS ma cos czego nie ma wersja MorphOS.
Ostatnia aktualizacja: 17.05.2026 13:52:28 przez Don_Adan
19.05 08:55
[#81]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #73
Tylko zauważ, że od kilku postów dyskutujemy już o trochę różnych rzeczach.
Ja od początku odnosiłem się głównie do: GameDevu DOS-owego lat 90., odzyskiwania jakościowego kodu źródłowego, utrzymywalności projektu i realności szybkiego odtworzenia dużej gry pokroju Dungeon Keeper.
Natomiast Ty coraz częściej mówisz bardziej o: samej deasemblacji, analizie EXE, debug symbols i AI pomagającym w reverse engineeringu.
I tutaj się częściowo zgadzam. AI już dziś potrafi bardzo pomagać przy: analizie binarek, deasemblacji, rozpoznawaniu struktur, czy nawet generowaniu pseudo-C, który za pomocą AI może zostać zrefaktorowany ("upiększony").
Tylko to nadal nie jest to samo co: "odzyskanie pełnych, jakościowych i utrzymywalnych źródeł projektu".
A co do Watcoma - on był bardzo popularny w DOS-owym GameDevie już wcześniej, a nie dopiero "po 1996". Wystarczy zobaczyć czym budowano wiele dużych gier DOS-owych z lat 1993–1996: Doom, Descent, Duke Nukem 3D, Rise of the Triad, System Shock, Tomb Raider, Warcraft 1 i 2, Mortal Kombat itd. Zresztą dobrym wyznacznikiem jest DOS/4GW który pojawiał się masowo przy grach, a to W na końcu to właśnie oznaczenie, że ta wersja DOS/4G pochodzi z pakietu Watcom.
Ja od początku odnosiłem się głównie do: GameDevu DOS-owego lat 90., odzyskiwania jakościowego kodu źródłowego, utrzymywalności projektu i realności szybkiego odtworzenia dużej gry pokroju Dungeon Keeper.
Natomiast Ty coraz częściej mówisz bardziej o: samej deasemblacji, analizie EXE, debug symbols i AI pomagającym w reverse engineeringu.
I tutaj się częściowo zgadzam. AI już dziś potrafi bardzo pomagać przy: analizie binarek, deasemblacji, rozpoznawaniu struktur, czy nawet generowaniu pseudo-C, który za pomocą AI może zostać zrefaktorowany ("upiększony").
Tylko to nadal nie jest to samo co: "odzyskanie pełnych, jakościowych i utrzymywalnych źródeł projektu".
A co do Watcoma - on był bardzo popularny w DOS-owym GameDevie już wcześniej, a nie dopiero "po 1996". Wystarczy zobaczyć czym budowano wiele dużych gier DOS-owych z lat 1993–1996: Doom, Descent, Duke Nukem 3D, Rise of the Triad, System Shock, Tomb Raider, Warcraft 1 i 2, Mortal Kombat itd. Zresztą dobrym wyznacznikiem jest DOS/4GW który pojawiał się masowo przy grach, a to W na końcu to właśnie oznaczenie, że ta wersja DOS/4G pochodzi z pakietu Watcom.
19.05 13:01
[#82]
Re: Dungeon Keeper coraz bliżej
@Rafael/ARMO, post #81
Pelnych zrodel nigdy nie odzyskasz, o ile autor nie dolaczyl kodu zrodlowego do programu.
Zawsze beda roznice typu nazwa procedury, struktury lub brak komentarzy czy ilosc uzytych plikow zrodlowych.
To jest raczej oczywiste dla kazdego kto choc troche programuje lub koduje.
Ale da sie odtworzyc zrodla w C, ktore po kompilacji beda dawaly taki sam plik wynikowy co oryginal.
I o to mi chodzi.
Tylko,, ze w C to jest duzo trudniejsze niz zwykla deasemblacja exeka.
Ale z pomoca AI duzo latwiej odtworzyc takie zrodla C, ktore po kompilacji beda dzialaly jak oryginal.
Na Amidze, Bruce Abbott bodaj stworzyl deasembler, ktory nie tylko deasembluje exeka, ale podobno potrafi rozpoznawac kod C, uzyty kompilator i bodaj procedury C.
Wiec dekompilacja jest do zrobienia (szczegolnie dla programow uzytkowych) , jesli kod programu jest standardowy.
Zawsze beda roznice typu nazwa procedury, struktury lub brak komentarzy czy ilosc uzytych plikow zrodlowych.
To jest raczej oczywiste dla kazdego kto choc troche programuje lub koduje.
Ale da sie odtworzyc zrodla w C, ktore po kompilacji beda dawaly taki sam plik wynikowy co oryginal.
I o to mi chodzi.
Tylko,, ze w C to jest duzo trudniejsze niz zwykla deasemblacja exeka.
Ale z pomoca AI duzo latwiej odtworzyc takie zrodla C, ktore po kompilacji beda dzialaly jak oryginal.
Na Amidze, Bruce Abbott bodaj stworzyl deasembler, ktory nie tylko deasembluje exeka, ale podobno potrafi rozpoznawac kod C, uzyty kompilator i bodaj procedury C.
Wiec dekompilacja jest do zrobienia (szczegolnie dla programow uzytkowych) , jesli kod programu jest standardowy.
22.05 10:26
[#83]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #82
Chodzi mi o to, że tego typu tłumaczenie powoduje – nawet jeśli jest to możliwe, co jest wątpliwe w projekcie takim jak Dungeonkeeper – kilka spadków wydajności. Zobacz keeperfx. Problemy z wydajnością, które mamy, wynikają głównie z użycia sztucznej inteligencji do odzyskiwania mapowania tekstur, to moje założenie. I znam o wiele więcej kodu niż ty ^^
22.05 12:24
[#84]
Re: Dungeon Keeper coraz bliżej
@MagicSN, post #83
Przeciez keeperfx to projekt z okolo 2013 roku, patrzac po datach na GitHub-ie.
link
Czyli zdecydowanie sprzed czasu ery AI.
Wiec to nie wina AI tylko czlowieka, ze cos nie dziala lub zle dziala w tym porcie.
A co do kodu to watpie, ze znasz wiecej kodu niz ja.
Oryginalnych zrodel to znasz wiecej, bo ja nigdy ich nie lubilem, i bardzo rzadko z nich korzystalem (moze z 1% moich projektow uzywa oryginalnych zrodel).
Ale co do kodu 68k to bardzo watpie, ze znasz go wiecej.
Ostatnia aktualizacja: 22.05.2026 12:25:46 przez Don_Adan
link
Original issue reported on code.google.com by stanislas.dolcini on 19 Aug 2013 at 10:52
Czyli zdecydowanie sprzed czasu ery AI.
Wiec to nie wina AI tylko czlowieka, ze cos nie dziala lub zle dziala w tym porcie.
A co do kodu to watpie, ze znasz wiecej kodu niz ja.
Oryginalnych zrodel to znasz wiecej, bo ja nigdy ich nie lubilem, i bardzo rzadko z nich korzystalem (moze z 1% moich projektow uzywa oryginalnych zrodel).
Ale co do kodu 68k to bardzo watpie, ze znasz go wiecej.
Ostatnia aktualizacja: 22.05.2026 12:25:46 przez Don_Adan