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ź.
0
6
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?
0
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.
0
Szybciej i lepiej wyjdzie napisać taką grę od początku. Poza tym takie przenoszenie gry byłoby pewnie pogwałceniem licencji.
0
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?
5
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ę.
0
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.
2
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
0
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ę?
1
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.
0
@Kacper Gutowski takich narzędzi które dekompilują do pseudo-C jest raptem kilka -> snowman (generuje straszną kupę), hopper, retdec, hexrays. Ten ostatni generuje dość znośny kod, ale kosztuje tysiące dolarów. Generalnie wszystkie generują mniej-więcej poprawny kod i są przydatne do statycznej analizy, ale na pewno nie do zrekompilowania tego.
3
Spine napisał(a):
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?
Może dla siebie... dla kolegi który też ma PS2... jakie to ma znaczenie że "nikt nie wspiera"..
Są entuzjaści starego sprzętu i emulatorów.