da napisał:

Wiesz o jakie referencje chodzi? Coś zaimplementowanego celowo, jak licznik poligonów, czy po prostu jakiś ciąg znaków w pliku poziomu który twój dekopiler uznaje za szum?

Za szum, może to być np. kod odpowiedzialny za wyświetlenie poziomu po ekranie ładowania.

da napisał:

W sensie, uważasz że to zabezpieczenia, czy nie poznałeś jeszcze wystarczająco dobrze formatu? A może to coś wynikającego z konwencji?

Kwestia nie tyle formatu, ile zrozumienia tego, co się tam dzieje.

da napisał:

Wiesz na czym stoisz?

Na ziemi. Trzeba przełożyć relacje między rejestrami procesora na kod źródłowy, który kompiluje się do pliku .exe o identycznym działaniu, jak oryginalny. I tyle.

Spinex napisał:

da napisał:

Wiesz na czym stoisz?

Na ziemi. Trzeba przełożyć relacje między rejestrami procesora na kod źródłowy, który kompiluje się do pliku .exe o identycznym działaniu, jak oryginalny. I tyle.

Miałem na myśli że zanim zabierzesz się za naprawianie gry, musisz się dowiedzieć co konkretnie powoduje że poziomy nie chcą się ładować
i to jest to o co chcę się ciebie zapytać od trzech postów: czy masz jakiś pomysł na zlokalizowanie źródła problemu?

Może w ogóle nie trzeba będzie modyfikować gry? Kto wie

Aż miło patrzeć, jak projekt nabiera sensownych kształtów  : )

Tak naprawdę to właściwy link do gameplayu jest tutaj: http://www.youtube.com/watch?feature=pl … 6tLEsbZBlQ

Poniżej zamieszczam fragment odkodowanego pliku .exe żebyście mogli zobaczyć, jak to wygląda. Ten fragment
kodu jest odpowiedzialny za współpracę z kartą graficzną, instrukcji SSE dla procesorów SIMDa tu nie zamieszczam dlatego,
iż gdyby ktoś poważył się skompilować ten kod przy użyciu tych instrukcji do kodu maszynowego, mógłby uszkodzić sobie
procesor. Składnia assemblera odpowiada intelowskiemu x86 32 bitowemu w dialekcie FASM.

format binary

width EQU 16
height EQU 4
size EQU 450

DB "BM"
DD size
DW 0
DW 0
DD 54

DD 40
DD width
DD height
DW 1
DW 24
DD 0
DD size-54
DD 0
DD 0
DD 0
DB 0
DB 0
DW 0


TIMES 4 DB 0, 0, 0
TIMES 5 DB 255, 255, 255
TIMES 3 DB 0, 0, 0
DB 255, 255, 255
TIMES 3 DB 0, 0, 0

DB 255, 255, 255
DB 0, 0, 0
DB 255, 255, 255
DB 0, 0, 0
DB 255, 255, 255
DB 0, 0, 0
DB 255, 255, 255
DB 0, 0, 0
DB 255, 255, 255
DB 0, 0, 0
DB 255, 255, 255
DB 0, 0, 0
DB 255, 255, 255
DB 0, 0, 0
DB 255, 255, 255
DB 0, 0, 0

DB 255, 255, 255
DB 0, 0, 0
DB 255, 255, 255
DB 0, 0, 0
DB 255, 255, 255
DB 0, 0, 0
DB 255, 255, 255
DB 0, 0, 0
DB 255, 255, 255
TIMES 3 DB 0, 0, 0
DB 255, 255, 255
TIMES 3 DB 0, 0, 0

TIMES 4 DB 0, 0, 0
DB 255, 255, 255
TIMES 3 DB 0, 0, 0
DB 255, 255, 255
DB 0, 0, 0
TIMES 3 DB 255, 255, 255
DB 0, 0, 0
DB 255, 255, 255
DB 0, 0, 0

w przełożeniu powyższego kodu na HLL typu C/C++ wygląda to tak:

#include <assemblerimport.h>
#include <eua.h>

binary f0x13 size, width, height, bufor


int main()
{

    for (cell a : bufor)
    {
            a.value = customize(*as, *ax, *eax)
    }

    return 121;


    ah, ax, em = value integer: 120x234BACfh
}

Najpierw mnie złapałeś tym, że to ukryty poziom, a teraz ten gameplay?
Tak czy siak, jestem pozytywnie nastawiony do całego tego projektu, szczególnie, że zawsze mnie interesowało jak to wszystko jest zrobione i jak to można modyfikować (po za tym, mam zamiar się w tym kierunku rozwijać)

Spinex napisał:

instrukcji SSE dla procesorów SIMDa tu nie zamieszczam dlatego,
iż gdyby ktoś poważył się skompilować ten kod przy użyciu tych instrukcji do kodu maszynowego, mógłby uszkodzić sobie
procesor

naprawdę uważasz że ktoś z nas tutaj umie skompilować instrukcje SSE dla  procesorów SIMDa


czuję się zaszczycony