Witam, od ponad roku aktywnie uczę się programowania i szukam ciekawych sposobów na rozszerzenie swojej wiedzy. Pisałem proste gierki 3D na platformę Playstation 2 i PSP, i zamierzam do tego wrócić. Chciałbym się dowiedzieć, ile czasu i wiedzy wymagałoby zdekompilowanie jakiejś prostej gierki (nie wiem, choćby szachy 3D?) i napisanie zgodnego z kompilatorem PSP kodu w C/C++ na podstawie otrzymanego kodu assemblera. Z assemblerem jeszcze nie miałem do czynienia, ale nie jest problem się tego nauczyć; natomiast pisanie aplikacji 3D na PSP nie stanowi dla mnie jako tako trudności. Myślicie że zderzenie się z DirectX może mocno utrudnić całą sprawę? Z góry dzięki za odpowiedź.
Skoro zadajesz te pytanie to sobie na 100% z tym nie poradzisz. Samo mówienie, że asembler to nie jest żaden problem już mówi o tym jak dużo wiesz o kodowaniu. Odpuść takie rzeczy, tego się po prostu nie robi. Idź krok po kroku. Teraz powinieneś zacząć robić jakieś gry korzystając z silnika graficznego. Znajdziesz tutaj tematy mówiąc od jakiego silnika zacząć. Pytanie czy w ogóle znasz jakikolwiek język programowania?
Wybacz, ale robisz ze mnie idiotę. Przecież piszę, że pisałem aplikacje 3D na SDK dla PS2 i PSP, co za tym idzie, znam język C i C++, który jest wymagany dla kompilatora, znam podstawy kodowania w grafice 3D, ręczne używanie kompilatora oraz wiele innych pomniejszych elementów, które pojawiają się przy tworzeniu programu 3D w pełni działającego na konsoli, a takowy JUŻ NAPISAŁEM. Poza tym piszę na początku, że to forma nauki i eksperymentowania, więc nie interesuje mnie fakt, że na silniku graficznym osiągnę lepsze rezultaty.
Szybciej i lepiej wyjdzie napisać taką grę od początku. Poza tym takie przenoszenie gry byłoby pewnie pogwałceniem licencji.
Kacper Gutowski napisał(a):
Witam, od ponad roku aktywnie uczę się programowania i szukam ciekawych sposobów na rozszerzenie swojej wiedzy. Pisałem proste gierki 3D na platformę Playstation 2 i PSP, i zamierzam do tego wrócić.
Dla kogo chcesz wspierać konsole, których już nikt nie wspiera?
Wiem, że czasem znajdują się zapaleńcy robiący non-profit nowe gry na archaiczne sprzęty (C64, NES, Sega Mega Drive..), ale Ty dopiero od ponad roku programujesz... Dlaczego od samego początku chcesz dziwaczyć?
Chciałbym się dowiedzieć, ile czasu i wiedzy wymagałoby zdekompilowanie jakiejś prostej gierki (nie wiem, choćby szachy 3D?) i napisanie zgodnego z kompilatorem PSP kodu w C/C++ na podstawie otrzymanego kodu assemblera.
j.w.
Skoro chcesz poszerzać swoją wiedzę, to czemu by nie napisać własnych szachów zamiast dekompilować?
Uczysz się programowania, czy piracenia?
Reversowanie nie jest takie proste ;) https://hack.cert.pl/challenges masz tu całą masę zadań z kategorii "re". Większość z nich to są binarki których źródła miały < 100 linijek kodu w C. Spróbuj rozwiązać któreś z tych zadań na początek i przekonasz się ile pracy potrzeba żeby przeanalizować nawet bardzo prostą aplikację.
Generalnie uznałem, że jeśli rekompilacja nie byłaby super czasochłonna i/lub wykonalna przez dość początkującego to byłoby to ciekawe doświadczenie. Wszystko na użytek własny, w celach edukacyjnych. Ale skoro odradzacie, to zajmę się czymś innym.
Mam też pomysł nieco inny i nie związany z PSP - napisanie emulatora jakiejś starej konsoli, na podstawie poradników dostępnych w internecie (dużo tego jest). Chyba jest to bardziej realne do zrobienia?
Wiem, dziwne mam hobby.
Kacper Gutowski napisał(a):
Chciałbym się dowiedzieć, ile czasu i wiedzy wymagałoby zdekompilowanie jakiejś prostej gierki (nie wiem, choćby szachy 3D?)
Czy ja wiem, parę minut na wygooglowanie narzędzia typu Snowman, kolejne parę minut na wyklikanie żeby zdekompilował binarkę... :)
Schody zaczną się, jak już zdekompilujesz i dostaniesz te kilkadziesiąt - kilkaset tysięcy linii kodu w asmie, prawdopodobnie bez śladu po pierwotnym kodzie źródłowym w postaci choćby nazw etykiet :P
napisanie zgodnego z kompilatorem PSP kodu w C/C++ na podstawie otrzymanego kodu assemblera.
Wiesz ile SLoC w C miała ta procedura?
dot_product:
testl %edx, %edx
je .L7
cmpl $1, %edx
je .L8
movl %edx, %ecx
xorl %eax, %eax
pxor %xmm0, %xmm0
shrl %ecx
salq $4, %rcx
.L4:
movupd (%rdi,%rax), %xmm1
movupd (%rsi,%rax), %xmm3
addq $16, %rax
mulpd %xmm3, %xmm1
movapd %xmm1, %xmm2
unpckhpd %xmm1, %xmm1
addsd %xmm0, %xmm2
movapd %xmm1, %xmm0
addsd %xmm2, %xmm0
cmpq %rax, %rcx
jne .L4
movl %edx, %eax
andl $-2, %eax
andl $1, %edx
je .L11
.L3:
cltq
movsd (%rsi,%rax,8), %xmm1
mulsd (%rdi,%rax,8), %xmm1
addsd %xmm1, %xmm0
ret
.L11:
ret
.L7:
pxor %xmm0, %xmm0
ret
.L8:
xorl %eax, %eax
pxor %xmm0, %xmm0
jmp .L3
Dokładnie 4, jeśli liczyć tylko cialo funkcji ;)
double dot_product(double* a, double* b, unsigned int n) {
double x = 0.0;
int i=0;
for(;i<n; i++) x += a[i] * b[i];
return x;
}
Zgadnij, jak będzie wyglądać po dekompilacji prosta gierka, która w C miała tylko 4k linii... ;)
Z assemblerem jeszcze nie miałem do czynienia, ale nie jest problem się tego nauczyć
Zależy którego ;]
- ARM - do ogarnięcia
- Nios2 - jak wyżej, ~96 instrukcji (w R1, R2 + rozszerzenia dokładają jeszcze z parędziesiąt), każda pełni ściśle określoną rolę, wykonuje podstawową czynność
- x86/x86-64 - dzieło sadysty, dziecko szatana, nie dość, że 12347627369 instrukcji, to jeszcze dwie składnie (Intelowska i AT&T, żeby było śmieszniej w jednej operandy podajesz w kolejności
cel, [źródło [...]]
, w drugiej[źródło, [...]], cel
), do tego instrukcje używane przez kompilatory niezgodnie z pierwotnym przeznaczeniem / znaczeniem żeby zoptymalizować kod np. instrukcje do obliczania adresów używane jak FMA dla integerów... styczność z nim na 1 roku studiów skutecznie obrzydziła mi assembly na długi czas.
EDIT
Ogólnie jak chcesz się na szybko pobawić bez instalowania narzędzi i popatrzeć, jaki assembly wyplują różne kompilatory / różne wersje kompilatorów dla jakichś procedur pisanych w językach kompilowanych, to tu jest taka fajna zabawka online
Dzięki za rzeczową odpowiedź. Programuję wysokopoziomowo, najniżej w C, a assemblera x86 ani ARM ani jakiegokolwiek innego nie tykałem bo nie było mi to do niczego potrzebne. Stąd też moja niewiedza w tej kwestii. Googlowałem temat dekompilacji i znalazłem narzędzia, które dekompilują program do postaci pseudokodu C, co podobno jest mniej wydajne, ale bardziej "ogarniable" dla człowieka. Rzecz jasna taki kod i tak trzeba by było zmodyfikować na własne potrzeby. Czy takie rozwiązanie miałoby szansę, czy jest to pic na wodę?
Kacper Gutowski napisał(a):
Mam też pomysł nieco inny i nie związany z PSP - napisanie emulatora jakiejś starej konsoli, na podstawie poradników dostępnych w internecie (dużo tego jest). Chyba jest to bardziej realne do zrobienia?
No to już prędzej. Nawet czasem się widzi współczesne emulatory NES'a napisane w Unity z wizualizacją 3D:
Jak uda Ci się napisać w pełni funkcjonalny emulator dosa, wydajniejszy niż DOSBOX... albo chociaż pogrzebiesz w źródłach DOSBOXa i sprawisz, żeby Dungeon Keeper chodził płynnie na współczesnych maszynach, to będę Ci wdzięczny ;) Bo na razie pełna rozdzielczość (Alt+R) ze wszystkimi opcjami cienia itp. zamula nawet na PC za 7k, a na Raspberry (który ma procek niezgodny z DOSem) jeszcze trudniej jest DOSBOXowi tłumaczyć kod aplikacji.