Komentowana treść: Dungeon Keeper coraz bliżej
08.05 13:27
[#31]
Re: Dungeon Keeper coraz bliżej
@rondoval, post #26
Skad takie dziwne dane wziales? Wymysliles?
Bo z tego co ja widze, to ktos (kto raczej slabo zna ASM 68k, ale ma duza motywacje) stworzyl w 2 miesiecy z pomoca platnego AI disassembler 68k, ktory wedlug mnie wyglada lepiej niz przez lata rozwijana IRA.
link
Oczywiscie dekompilator to cos bardziej skomplikowanego niz deasembler.
Dlatego potrzebny jest dobry programista do kontroli pracy AI.
Bo z tego co ja widze, to ktos (kto raczej slabo zna ASM 68k, ale ma duza motywacje) stworzyl w 2 miesiecy z pomoca platnego AI disassembler 68k, ktory wedlug mnie wyglada lepiej niz przez lata rozwijana IRA.
link
Oczywiscie dekompilator to cos bardziej skomplikowanego niz deasembler.
Dlatego potrzebny jest dobry programista do kontroli pracy AI.
08.05 15:27
[#32]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #31
Lot na Marsa można zorganizować znacznie szybciej, niż się powszechnie uważa.
To w końcu stosunkowo świeży kierunek badań, więc nie ma tam żadnych archaicznych komplikacji.
Wszystkie parametry lotu są do odtworzenia bez większego wysiłku.
Sama inżynieria rakietowa nie jest tu szczególnie istotna.
Ale powiem Ci, jak ja bym to zrobił, gdybym miał przygotować taką wyprawę.
1. Najpierw wybrałbym jakąś prostą misję orbitalną, najlepiej taką, której dokumentacja jest dostępna w archiwach.
2. Odtworzyłbym ją możliwie wiernie, korzystając z tych samych podzespołów, materiałów i procedur, żeby zachować pełną zgodność z oryginałem.
3. Następnie sprawdziłbym, czy rakieta zachowuje się identycznie jak pierwowzór — co do sekundy w zapłonie, co do metra w trajektorii.
Jeśli nie, to znaczy, że trzeba skorygować jedną z mniej istotnych zmiennych.
4. Gdy już uzyskałbym pełną zgodność, przeszedłbym do analizy konstrukcji i przebiegu lotu, krok po kroku odtwarzając wszystkie zależności.
5. Na tej podstawie odtworzyłbym kompletny projekt misji, łącznie z dynamiką lotu, charakterystyką silników i profilem wejścia w atmosferę.
To wbrew pozorom nie jest trudne — wymaga jedynie cierpliwego prześledzenia wszystkich parametrów.
6. Dla pewności powtórzyłbym to z jedną lub dwiema innymi misjami, żeby upewnić się, że metoda jest poprawna.
7. Dopiero wtedy przeszedłbym do misji marsjańskiej, mając już gotowy, sprawdzony zestaw procedur umożliwiających pełne odtworzenie lotu międzyplanetarnego.
To w końcu stosunkowo świeży kierunek badań, więc nie ma tam żadnych archaicznych komplikacji.
Wszystkie parametry lotu są do odtworzenia bez większego wysiłku.
Sama inżynieria rakietowa nie jest tu szczególnie istotna.
Ale powiem Ci, jak ja bym to zrobił, gdybym miał przygotować taką wyprawę.
1. Najpierw wybrałbym jakąś prostą misję orbitalną, najlepiej taką, której dokumentacja jest dostępna w archiwach.
2. Odtworzyłbym ją możliwie wiernie, korzystając z tych samych podzespołów, materiałów i procedur, żeby zachować pełną zgodność z oryginałem.
3. Następnie sprawdziłbym, czy rakieta zachowuje się identycznie jak pierwowzór — co do sekundy w zapłonie, co do metra w trajektorii.
Jeśli nie, to znaczy, że trzeba skorygować jedną z mniej istotnych zmiennych.
4. Gdy już uzyskałbym pełną zgodność, przeszedłbym do analizy konstrukcji i przebiegu lotu, krok po kroku odtwarzając wszystkie zależności.
5. Na tej podstawie odtworzyłbym kompletny projekt misji, łącznie z dynamiką lotu, charakterystyką silników i profilem wejścia w atmosferę.
To wbrew pozorom nie jest trudne — wymaga jedynie cierpliwego prześledzenia wszystkich parametrów.
6. Dla pewności powtórzyłbym to z jedną lub dwiema innymi misjami, żeby upewnić się, że metoda jest poprawna.
7. Dopiero wtedy przeszedłbym do misji marsjańskiej, mając już gotowy, sprawdzony zestaw procedur umożliwiających pełne odtworzenie lotu międzyplanetarnego.
08.05 16:03
[#33]
Re: Dungeon Keeper coraz bliżej
@michal_zukowski, post #28
skoro amiga to komputer retro to amiga 4000 jako część zbioru amiga to też komputer retro, więc 040 i fast można uznać za golasa
Zamieniam "komputer retro" na komputerEK retro" - może być?
"KomputerEK retro" -> "komputer domowy" ew. "komputer 16-bit", oraz "sprzedał się detalicznie co najmniej w ~1mln egzemplarzy [+/- kilkaset tysięcy]" (inaczej: ktoś statystycznie go miał w bliższym lub dalszym otoczeniu, a jego dzieciaki grały na nim). Tak więc IMO Falcon, TT, NeXT, SGI, A2x00, A3000?, A4000?, nawet Pentium Pro + NT4 -> wylatują.
Jak miałeś u siebie w otoczeniu 32-bitową stację roboczą max w 1994 roku na biurku jako "komputer domowy", to gratuluję (no chyba, że mieszkałeś w otoczeniu CERNu).
08.05 16:31
[#35]
Re: Dungeon Keeper coraz bliżej
@amikoksu, post #34
IMO tak (z ECS 1MB CHIP / 020/14MHz + AGA) - tylko dodać twardziela, Goteka, CD-ROM czy coś takiego, jako pamięć masową. IMO lepsze nowe gry na prawie-golasa 68k, niż 30-letnie na PiStorma. Jak retro to retro.
Ostatnia aktualizacja: 08.05.2026 16:33:51 przez freak_outXP
Ostatnia aktualizacja: 08.05.2026 16:33:51 przez freak_outXP
08.05 16:38
[#36]
Re: Dungeon Keeper coraz bliżej
@MagicSN, post #23
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),
Istnieje nieskończona liczba rzeczywistości ale tylko w tej amigowej - 13fps jest naprawdę grywalne.
08.05 16:48
[#38]
Re: Dungeon Keeper coraz bliżej
@rondoval, post #32
No nie, to tak nie dziala.
Jest cos takiego jak okienko startowe do lotu na Marsa.
I to dopiero te okienko z konca 2028 rok jest realne.
I wtedy dopiero odbeda sie loty na Marsa, jak wszystko pojdzie dobrze.
W tym roku jakas sonda lub sondy poleca.
I mylisz programowanie komputerowe z projektowaniem sprzetu.
Cos w stylu skoro Amerykanie wyladowali na Ksiezycu 58 lat temu to maja juz technologie i nie potrzebuja jej od nowa odtwarzac, a jednak wszystko tworza od nowa.
Widzisz ja w swoim zyciu troche kodu 68k zdeasemblowalem i/lub przerobilem, tak jak chcialem.
Nie dekompilowalem kodu bo dla mnie zrodla w C sa nieprzydatne.
Poza tym zapominasz o najwazniejszym.
To ma robic AI, nie czlowiek.
Czlowiek ma tylko AI nadzorowac.
AI jest w stanie zrobic blyskawicznie to co czlowiekowi zajeloby wiele miesiecy.
Wiec po prostu sie mylisz.
Jest cos takiego jak okienko startowe do lotu na Marsa.
I to dopiero te okienko z konca 2028 rok jest realne.
I wtedy dopiero odbeda sie loty na Marsa, jak wszystko pojdzie dobrze.
W tym roku jakas sonda lub sondy poleca.
I mylisz programowanie komputerowe z projektowaniem sprzetu.
Cos w stylu skoro Amerykanie wyladowali na Ksiezycu 58 lat temu to maja juz technologie i nie potrzebuja jej od nowa odtwarzac, a jednak wszystko tworza od nowa.
Widzisz ja w swoim zyciu troche kodu 68k zdeasemblowalem i/lub przerobilem, tak jak chcialem.
Nie dekompilowalem kodu bo dla mnie zrodla w C sa nieprzydatne.
Poza tym zapominasz o najwazniejszym.
To ma robic AI, nie czlowiek.
Czlowiek ma tylko AI nadzorowac.
AI jest w stanie zrobic blyskawicznie to co czlowiekowi zajeloby wiele miesiecy.
Wiec po prostu sie mylisz.
08.05 18:08
[#39]
Re: Dungeon Keeper coraz bliżej
@amikoksu, post #37
IMO nie nie nie. IMO only Amiga 500 rulez do 94.
To tylko moja opinia: Dla mnie Amiga rulezuje zawsze! A jak chcę nieamigowego rulezowania, to od tego mam Pentium IV, smartfona, Pegazusa, PS5Pro, latam dronem czy odpalam Netflixa. Po co mam grać w bardzo starą grę w 13 klatkach na sekundę, i płacić za to kilka tysięcy złotych?
08.05 19:15
[#41]
Re: Dungeon Keeper coraz bliżej
@amikoksu, post #40
Nie czuję sie oburzony. Wiem, że mam prawo mieć własne zdanie.
Fajnie, że takie rzeczy ktoś robi - ale ja sam wolałbym, żeby robili lepsze gry na klasyka-golasa, korzystając z lepszej, większej i tańszej pamięci masowej. Nie widzę jakiejś większej wartości w tym, że uruchomię sobie port 30-letniej gry w 13 fps-ach na pseudo-dopalonej Amidze.
Fajnie, że takie rzeczy ktoś robi - ale ja sam wolałbym, żeby robili lepsze gry na klasyka-golasa, korzystając z lepszej, większej i tańszej pamięci masowej. Nie widzę jakiejś większej wartości w tym, że uruchomię sobie port 30-letniej gry w 13 fps-ach na pseudo-dopalonej Amidze.
09.05 02:38
[#43]
Re: Dungeon Keeper coraz bliżej
@amikoksu, post #42
Tych gier akurat wychodzi tak dużo, że nie sposób w nie wszystkie zagrać — mówię tu tylko o tych, które uważam za najlepsze, oczywiście według mojego gustu. Do tego jest tyle staroci do ogrania/masterowania, że brakuje czasu na ambitniejsze działania. Chyba że zacznę męczyć Cloda, czy jak to IS tam ma — zapłacę i w związku z tym będę musiał coś robić, żeby kasa się nie zmarnowała. 
09.05 03:28
[#44]
Re: Dungeon Keeper coraz bliżej
@rbej1977, post #36
Pamiętaj, że 20 fps to maksymalna liczba fps w oryginalnym Dungeonkeeperze (zrobiono tak, aby stworzenia nie poruszały się zbyt szybko). Z tego powodu 13 kl./s to całkiem nieźle (warto zauważyć, że 13 kl./s to wynik przed optymalizacją – obecnie pracuję nad optymalizacją, która powinna to jeszcze poprawić).
Przy okazji, jednym z powodów niskiej prędkości jest wykorzystanie dekompilowanego kodu z ulepszoną sztuczną inteligencją (projekt Keeperfx zrobił to, aby pozbyć się ASM x86 – problem polega na tym, że ten zdekompilowany kod zachowuje wiele z architektury x86, co jest dość kiepskie dla 68k – chociaż na AmigaOne x1000 nadal działa z 50 kl./s w rozdzielczości 640x480, ponieważ ta maszyna ma wystarczającą moc obliczeniową). Problemem jest zwłaszcza masowe wykorzystanie matematyki 64-bitowej.
Mimo to, 13 kl./s w Dungeonkeeperze jest tak blisko maksymalnej liczby klatek na sekundę w oryginalnej grze, że nie jest źle (chociaż sam wolę grać z wyższą liczbą klatek na sekundę – „bardzo grywalna” to komentarz beta testera, a nie mój).
Odnośnie wcześniejszych komentarzy Don_Adana na temat kompilatorów C – co To, jaki kompilator jest używany, jest zupełnie nieistotne. To tak, jakbyś powiedział: „Potrafię rysować jak wielki artysta, bo mam te same kolory, których używa artysta”. Właściwie to, czy używany jest Borland C++, GCC czy cokolwiek innego, jest zupełnie nieistotne. Bardziej istotne są biblioteki – i w wielu przypadkach styl kodowania (jak wyjaśniłem powyżej w przypadku zdekompilowanego kodu, który powoduje problemy z szybkością – i nie, samo przepisanie tego kodu też nie pomoże, szybciej byłoby napisać całą grę od nowa).
Przy okazji, jednym z powodów niskiej prędkości jest wykorzystanie dekompilowanego kodu z ulepszoną sztuczną inteligencją (projekt Keeperfx zrobił to, aby pozbyć się ASM x86 – problem polega na tym, że ten zdekompilowany kod zachowuje wiele z architektury x86, co jest dość kiepskie dla 68k – chociaż na AmigaOne x1000 nadal działa z 50 kl./s w rozdzielczości 640x480, ponieważ ta maszyna ma wystarczającą moc obliczeniową). Problemem jest zwłaszcza masowe wykorzystanie matematyki 64-bitowej.
Mimo to, 13 kl./s w Dungeonkeeperze jest tak blisko maksymalnej liczby klatek na sekundę w oryginalnej grze, że nie jest źle (chociaż sam wolę grać z wyższą liczbą klatek na sekundę – „bardzo grywalna” to komentarz beta testera, a nie mój).
Odnośnie wcześniejszych komentarzy Don_Adana na temat kompilatorów C – co To, jaki kompilator jest używany, jest zupełnie nieistotne. To tak, jakbyś powiedział: „Potrafię rysować jak wielki artysta, bo mam te same kolory, których używa artysta”. Właściwie to, czy używany jest Borland C++, GCC czy cokolwiek innego, jest zupełnie nieistotne. Bardziej istotne są biblioteki – i w wielu przypadkach styl kodowania (jak wyjaśniłem powyżej w przypadku zdekompilowanego kodu, który powoduje problemy z szybkością – i nie, samo przepisanie tego kodu też nie pomoże, szybciej byłoby napisać całą grę od nowa).
09.05 03:39
[#45]
Re: Dungeon Keeper coraz bliżej
@amikoksu, post #42
Nowe gry, poza nielicznymi wyjątkami, nie wchodzą w grę. Owszem, jest KILKA świetnych nowych gier, ale stanowią one wyjątek. Potrzebne są zasoby, których Amiga po prostu nie ma (graficy, dźwiękowcy, projektanci map...).
Lepiej wziąć dostępne świetne tytuły i je przenieść.
Osobiście bardziej zależy mi na nowoczesnych Amigach niż na serii 030-060 (choć moim wydawcom bardziej na nich zależy ^^ Mówią, że wersja 68k jest najważniejsza ze względu na wyniki sprzedaży), ale nadal staram się tworzyć gry, które dobrze na nich działają. Nadal w większości przypadków nie jest to możliwe.
Gry, które chcę tworzyć, często po prostu nie mają wystarczającej mocy. A w przyszłości pojawią się gry z grafiką 16-bitową, więc systemy AGA już odpadają.
Z OS4 i PiStorm masz dobrą prędkość. A PiStorm jest na tyle tani, że praktycznie każdy posiadacz Amigi mógłby go bez problemu kupić (niestety, cena to osobny problem na OS4 :( ).
Jeśli chodzi o porty gier (poza kilkoma świetnymi wyjątkami, jedynym sposobem na zdobycie gier w miarę współczesnych), „dobry okres” to gry z lat 1996-2006. Starsze gry będą miały zbyt dużo ASM x86 lub innych bardzo trudnych do portowania elementów. Nowsze gry potrzebują zbyt dużej mocy obliczeniowej.
Ale już od 1996 roku jesteś na poziomie 040+, czasami 060+. To smutne, że to, co jest dobre dla Amigi i to, co ma najwięcej aktywnych systemów, idzie w różnych kierunkach.
Moje podejście jest zawsze takie – portuję i sprawdzam, gdzie da się to uruchomić (wliczając optymalizacje). Nie skupiam się na konkretnych systemach.
Ale jak już wspomniałem, dobry zakres portów dla Amigi to 1996-2006. To zazwyczaj wyklucza już 030. W czasie portowania gry od „030 do dobrego czasu” mógłby przenieść 3 lub 4 gry 060+. I NIE mam na myśli bezpośrednich rekompilacji. Mam na myśli dobrze wykonane porty.
Mam szczerą nadzieję, że ci, którzy nadal używają 030 lub 040, przejdą na 060, a najlepiej na PiStorm.
Myślę też, że PiStorm PPC zmieni zasady gry. Na PPC narzędzia kompilatora są znacznie lepsze (mniej błędów). I podobno będzie działać szybciej niż Emu68.
Lepiej wziąć dostępne świetne tytuły i je przenieść.
Osobiście bardziej zależy mi na nowoczesnych Amigach niż na serii 030-060 (choć moim wydawcom bardziej na nich zależy ^^ Mówią, że wersja 68k jest najważniejsza ze względu na wyniki sprzedaży), ale nadal staram się tworzyć gry, które dobrze na nich działają. Nadal w większości przypadków nie jest to możliwe.
Gry, które chcę tworzyć, często po prostu nie mają wystarczającej mocy. A w przyszłości pojawią się gry z grafiką 16-bitową, więc systemy AGA już odpadają.
Z OS4 i PiStorm masz dobrą prędkość. A PiStorm jest na tyle tani, że praktycznie każdy posiadacz Amigi mógłby go bez problemu kupić (niestety, cena to osobny problem na OS4 :( ).
Jeśli chodzi o porty gier (poza kilkoma świetnymi wyjątkami, jedynym sposobem na zdobycie gier w miarę współczesnych), „dobry okres” to gry z lat 1996-2006. Starsze gry będą miały zbyt dużo ASM x86 lub innych bardzo trudnych do portowania elementów. Nowsze gry potrzebują zbyt dużej mocy obliczeniowej.
Ale już od 1996 roku jesteś na poziomie 040+, czasami 060+. To smutne, że to, co jest dobre dla Amigi i to, co ma najwięcej aktywnych systemów, idzie w różnych kierunkach.
Moje podejście jest zawsze takie – portuję i sprawdzam, gdzie da się to uruchomić (wliczając optymalizacje). Nie skupiam się na konkretnych systemach.
Ale jak już wspomniałem, dobry zakres portów dla Amigi to 1996-2006. To zazwyczaj wyklucza już 030. W czasie portowania gry od „030 do dobrego czasu” mógłby przenieść 3 lub 4 gry 060+. I NIE mam na myśli bezpośrednich rekompilacji. Mam na myśli dobrze wykonane porty.
Mam szczerą nadzieję, że ci, którzy nadal używają 030 lub 040, przejdą na 060, a najlepiej na PiStorm.
Myślę też, że PiStorm PPC zmieni zasady gry. Na PPC narzędzia kompilatora są znacznie lepsze (mniej błędów). I podobno będzie działać szybciej niż Emu68.
09.05 10:35
[#47]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #38
To ma robic AI, nie czlowiek.
Dokładnie. A jak już powstaną sztuczne łapy do kibla sterowane przez jejaj, to człowiek ma tego nie robić a tylko nadzorować coby nie złapało gdzie nie trzeba. Człowiek ma tylko leżeć i pachnieć.
Ostatnia aktualizacja: 09.05.2026 10:45:41 przez amikoksu
09.05 11:49
[#48]
Re: Dungeon Keeper coraz bliżej
@amikoksu, post #47
Czlowiek ma nadzorowac prace AI, a nie lezec i pachniec.
Masz tutaj przyklad takiego modelowego dzialania:
link
Czlowiek to pomysl i sprawdzanie tego co stworzyl AI, czyli kontrola pracy AI.
Im czlowiek ma wieksze doswiadczenie w danej dziedzinie, tym praca wykonana przez AI powinna byc lepsza.
Po prostu nawet zwykle wklepywanie kodu programu do edytora zajmuje czlowiekowi zbyt duzo czasu.
AI zrobi to w zasadzie blyskawicznie.
Wedlug mnie szkoda czasu na bardzo skomplikowana prace czlowieka, ale moze to dlatego, ze leniwy i stary jestem.
Masz tutaj przyklad takiego modelowego dzialania:
link
Czlowiek to pomysl i sprawdzanie tego co stworzyl AI, czyli kontrola pracy AI.
Im czlowiek ma wieksze doswiadczenie w danej dziedzinie, tym praca wykonana przez AI powinna byc lepsza.
Po prostu nawet zwykle wklepywanie kodu programu do edytora zajmuje czlowiekowi zbyt duzo czasu.
AI zrobi to w zasadzie blyskawicznie.
Wedlug mnie szkoda czasu na bardzo skomplikowana prace czlowieka, ale moze to dlatego, ze leniwy i stary jestem.
09.05 16:44
[#50]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #48
Im czlowiek ma wieksze doswiadczenie w danej dziedzinie, tym praca wykonana przez AI powinna byc lepsza.Ale młodzi ludzie będą używać AI zamiast zdobywać doświadczenie i za jakiś czas nie będzie ludzi z doświadczeniem. AI zacznie się więc "karmić" sama sobą, a to, jak wykazały przeprowadzone eksperymenty, prowadzi do degeneracji.
09.05 18:59
[#52]
Re: Dungeon Keeper coraz bliżej
@Krashan, post #50
Przeciez juz teraz spora czesc mlodych ludzi uzywa wszelkiego rodzaju gotowcow z netu, bo tak latwiej i szybciej.
Wiec bedzie roslo pokolenie bez doswiadczenia, ewentualnie technika pojdzie juz tak do przodu, ze bedzie mozliwe zainstalowac "delikwentom" implant z doswiadczeniem do mozgu.
A co do AI to byc moze tak jak w Highlander "moze byc tylko jeden".
Wiec beda sie nawzajem konsumowaly, i powstanie Super AI, amerykanski lub chinski.
Ja obstawiam ze to bedzie amerykanski, ten co ma byc w Kosmosie.
Wiec bedzie roslo pokolenie bez doswiadczenia, ewentualnie technika pojdzie juz tak do przodu, ze bedzie mozliwe zainstalowac "delikwentom" implant z doswiadczeniem do mozgu.
A co do AI to byc moze tak jak w Highlander "moze byc tylko jeden".
Wiec beda sie nawzajem konsumowaly, i powstanie Super AI, amerykanski lub chinski.
Ja obstawiam ze to bedzie amerykanski, ten co ma byc w Kosmosie.
09.05 19:22
[#54]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #30
To, że plik EXE zawiera identyfikator kompilatora, mówi jedynie tyle, że końcowy etap budowania (linkowanie/scalanie) został wykonany tym konkretnym narzędziem. Nie mówi natomiast, jakimi kompilatorami budowano poszczególne OBJ/LIB, z jakich języków pochodziły moduły, ani jak wyglądał cały proces budowania projektu.
W latach 90. bardzo często mieszano różne narzędzia. Przykładowo: Turbo C/Borland C++, Turbo Pascal/Borland Pascal, ASM,
Watcom, własne biblioteki. OBJ można było ze sobą normalnie linkować.
Do tego dochodzi jeszcze problem optymalizacji. Po kompilacji różne konstrukcje źródłowe potrafią dać identyczny kod wynikowy. Informacja semantyczna zostaje utracona.
Dlatego nie istnieje coś takiego jak "odzyskanie oryginalnego kodu źródłowego" z EXE. Można odzyskać logikę programu albo stworzyć semantycznie podobny kod, ale nie "cofnąć kompilacji". Kompilator po optymalizacji "spłaszcza" wiele różnych konstrukcji do podobnej postaci maszynowej.
Dlatego z EXE można odzyskać działanie programu, ale nie da się wiernie odzyskać oryginalnego kodu źródłowego, procesu myślowego autora, zastosowanych abstrakcji czy nawet pierwotnego nazewnictwa zmiennych i komentarzy.
C/C++ czy Pascal to nie assembler - ten proces nie jest odwracalny 1:1.
Akurat w latach 90tych. jak najbardziej analizowałem EXE i różne formaty plików, robiłem reverse engineering i pisałem na Amidze/PC prywatne narzędzia na podstawie takich analiz.
Zajmowałem się też teorią kompilatorów i efektem tego był m.in. mój własny, w pełni funkcjonalny kompilator języka Object Pascal wraz z optymalizacjami kodu.
Dlatego właśnie jestem sceptyczny wobec tezy, że z samego EXE można po prostu "odzyskać oryginalne źródła", szczególnie po optymalizacjach kompilatora. To niestety tak nie działa.
W latach 90. bardzo często mieszano różne narzędzia. Przykładowo: Turbo C/Borland C++, Turbo Pascal/Borland Pascal, ASM,
Watcom, własne biblioteki. OBJ można było ze sobą normalnie linkować.
Do tego dochodzi jeszcze problem optymalizacji. Po kompilacji różne konstrukcje źródłowe potrafią dać identyczny kod wynikowy. Informacja semantyczna zostaje utracona.
Dlatego nie istnieje coś takiego jak "odzyskanie oryginalnego kodu źródłowego" z EXE. Można odzyskać logikę programu albo stworzyć semantycznie podobny kod, ale nie "cofnąć kompilacji". Kompilator po optymalizacji "spłaszcza" wiele różnych konstrukcji do podobnej postaci maszynowej.
Dlatego z EXE można odzyskać działanie programu, ale nie da się wiernie odzyskać oryginalnego kodu źródłowego, procesu myślowego autora, zastosowanych abstrakcji czy nawet pierwotnego nazewnictwa zmiennych i komentarzy.
C/C++ czy Pascal to nie assembler - ten proces nie jest odwracalny 1:1.
Widac, ze nie przegladales nigdy starych exekow z PC-ta.
Akurat w latach 90tych. jak najbardziej analizowałem EXE i różne formaty plików, robiłem reverse engineering i pisałem na Amidze/PC prywatne narzędzia na podstawie takich analiz.
Zajmowałem się też teorią kompilatorów i efektem tego był m.in. mój własny, w pełni funkcjonalny kompilator języka Object Pascal wraz z optymalizacjami kodu.
Dlatego właśnie jestem sceptyczny wobec tezy, że z samego EXE można po prostu "odzyskać oryginalne źródła", szczególnie po optymalizacjach kompilatora. To niestety tak nie działa.
09.05 22:39
[#57]
Re: Dungeon Keeper coraz bliżej
@Rafael/ARMO, post #54
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.
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.
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.
Nawet na Amidze niektore gry czy programy majja dolaczany taki hunk, np TFX (ktoras tam wersja).
Nazwy procedur bardzo duzo ulatwiaja, ale nie sa niezbedne ani do deasemblacji, ani do dekompilacji.
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.
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.
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.
Nawet na Amidze niektore gry czy programy majja dolaczany taki hunk, np TFX (ktoras tam wersja).
Nazwy procedur bardzo duzo ulatwiaja, ale nie sa niezbedne ani do deasemblacji, ani do dekompilacji.
10.05 05:24
[#58]
Re: Dungeon Keeper coraz bliżej
@MUFA-amigaone-pl, post #56
po tym co widzę u siebie na X5000.
Na SAM440ep 667Mhz/512mb/ATI RADEON Mobility M9 64 MB RAM i AmigaOS4- gra działa bardzo szybko,
Jest płynniej niż na filmiku z Mirari - nie ma tego efektu doczytywania/dorysowywania się - chyba, że to wina YT,
Ostatnia aktualizacja: 10.05.2026 05:35:48 przez Amig_OS
10.05 08:36
[#59]
Re: Dungeon Keeper coraz bliżej
@Amig_OS, post #58
Jedną z różnic między wersją na AmigaOS4 a wersją na MorphOS jest to, że zmieniłem oryginalny kod SDL2 na SDL1, co dało pewien wzrost wydajności. Zaimplementowałem również kod timera w sposób bardziej kompatybilny z Amigą (ostatnia część może być również w wersji na MOS; przekazałem ten kod autorowi wersji na MOS, ponieważ miał wtedy problemy z wydajnością). Ale tak, po obejrzeniu filmu odniosłem takie samo wrażenie jak ty – w porównaniu z wersją na OS4, wersja na MOS wydawała się nieco wolniejsza.
Wczoraj wysłał mi swój kod, żebym mógł go porównać, ale jeszcze go nie sprawdziłem.
Wersje OS4/68k potrzebują teraz faktycznych testów.
I podejrzewam, że „Niezbyt szybka, przynajmniej sądząc po tym filmiku z Mirari i po tym co widzę u siebie na X5000.” Mufa oznacza „w porównaniu z wersją AmigaOS4 na moim x5000”
Ostatnia aktualizacja: 10.05.2026 08:39:04 przez MagicSN
Ostatnia aktualizacja: 10.05.2026 08:49:04 przez MagicSN
Wczoraj wysłał mi swój kod, żebym mógł go porównać, ale jeszcze go nie sprawdziłem.
Wersje OS4/68k potrzebują teraz faktycznych testów.
I podejrzewam, że „Niezbyt szybka, przynajmniej sądząc po tym filmiku z Mirari i po tym co widzę u siebie na X5000.” Mufa oznacza „w porównaniu z wersją AmigaOS4 na moim x5000”
Ostatnia aktualizacja: 10.05.2026 08:39:04 przez MagicSN
Ostatnia aktualizacja: 10.05.2026 08:49:04 przez MagicSN
10.05 08:45
[#60]
Re: Dungeon Keeper coraz bliżej
@Don_Adan, post #57
Diablo to gra, w której kolejność bajtów nie stanowi większego problemu, ponieważ istnieje wersja na Maca. Została opracowana z uwzględnieniem kolejności bajtów. W przypadku Dungeonkeepera mogę powiedzieć, że NIE zostało to zrobione. Diablo nie jest również grą 3D, lecz izometryczną, co ułatwia rozgrywkę.
I znowu – użyty kompilator nie ma znaczenia. Kod dla Borland C++ wygląda dokładnie tak samo, jak kod dla gcc. Oba to kod w C.
A teraz mogę też powiedzieć, dlaczego KeeperFX ma tak niską wydajność, ponieważ jego rdzeń tkwi w wywołaniach mapowania tekstur, które najprawdopodobniej zostały przejęte (ponad 13 lat temu) przez dekompilację z oryginalnego Dungeonkeepera (przynajmniej takie jest moje podejrzenie na podstawie wyglądu kodu).
Te fragmenty kodu są bardzo zbliżone do oryginalnego x86 ASM (wciąż mam kopię wersji ASM – około rok temu to był jeszcze ASM).
I myślę, że widziałem więcej „komercyjnych” źródeł gier niż ty. Mogę zapewnić, że gry sprzed 1996 roku w dużej mierze korzystały z ASM. ry na PC.
Znów – gry z 1996 roku i nowsze (te, które zazwyczaj wymagają 60+) są bardziej atrakcyjne do portowania.
Ostatnia aktualizacja: 10.05.2026 08:46:38 przez MagicSN
I znowu – użyty kompilator nie ma znaczenia. Kod dla Borland C++ wygląda dokładnie tak samo, jak kod dla gcc. Oba to kod w C.
A teraz mogę też powiedzieć, dlaczego KeeperFX ma tak niską wydajność, ponieważ jego rdzeń tkwi w wywołaniach mapowania tekstur, które najprawdopodobniej zostały przejęte (ponad 13 lat temu) przez dekompilację z oryginalnego Dungeonkeepera (przynajmniej takie jest moje podejrzenie na podstawie wyglądu kodu).
Te fragmenty kodu są bardzo zbliżone do oryginalnego x86 ASM (wciąż mam kopię wersji ASM – około rok temu to był jeszcze ASM).
I myślę, że widziałem więcej „komercyjnych” źródeł gier niż ty. Mogę zapewnić, że gry sprzed 1996 roku w dużej mierze korzystały z ASM. ry na PC.
Znów – gry z 1996 roku i nowsze (te, które zazwyczaj wymagają 60+) są bardziej atrakcyjne do portowania.
Ostatnia aktualizacja: 10.05.2026 08:46:38 przez MagicSN