IPS (*.ips)
Chyba najstarszy i najpopularniejszy z łatek. Niestety również najuboższy. Główną jego zaletą jest prostota działania i niesamowita popularność (mnóstwo emulatorów posiada obsługę tego formatu dla patchowania plików w locie). Obecnie ten format jest już mocno przeterminowany i nie nadaje się do nowych gier (w sensie: większych od 16MB, ale już przy 2MB mogą występować problemy z adresacją - przynajmniej mi się to przydarzyło i od tamtej pory nie używam IPS). W przypadku porównywania plików o różnej wielkości należy stosować trick, który opisałem przy okazji PPF3.
UPS (*.ups)
Następca IPSa. Nie znam i nie używam, ale podobno przystosowany jest już do obsługi plików powyżej 16MB.
Ninja/Ninja2 (*.rup)
Nowy, bardzo dobry format, który podobnie jak UPS i PPF obsługuje "duże pliki". Cechy unikalne: przechowuje sporo dodatkowych informacji takich jak autor, tytuł gry, tytuł łatki, data wydania, opis, gatunek etc. i... gwóźdź programu: sprawdza sumy kontrolne plików (MD5). Jeśli użytkownik będzie próbował użyć łatki na pliku, który jest np. uszkodzony, zmodyfikowany, overdump etc. program nie zgodzi się na patchowanie. Eliminuje to problem pomylenia plików i rzucania błotem w autora patcha he he (choć szkoda, że ninja nie pyta użytkownika czy mimo wszystko kontynuować patchowanie). Kolejną ciekawą funkcją podczas budowy patcha jest wybór platformy co pozwala ominąć sprawdzanie niepotrzebnych danych i przy patchowaniu eliminuje problemy z header/non-header (SNES/Genesis). Dla plików nie wymienionych na liście należy używać oczywiście RAW. Ostatnim ciekawy i unikalnym featurem jest bezproblemowe porównywanie plików o różnej wielkości (tylko w trybie raw).
Program niestety napisany jest tylko pod win32 co go trochę deklasuje w moich oczach. Potrzebny jest też net.framework w wersji najmniej 2.0. Aplikacja obsługuje niemal wszystkie niżej/wyżej wymienione formaty - tworzy natomiast tylko swój własny.
Fire Flower (*.pat)
Nie znam.
Rom eXtension Library (*.rxl)
nie znam.
format SNES-Edit (*.npo)
Jest to format używany przez ww. "multi edytor". Osobiście nigdy nie używałem tego formatu, który i tak jest tylko ciekawostką (służy raczej rom hacker-owi podczas pracy). Mimo wszystko warto odnotować, że coś takiego
w ogóle istnieje.
PDS (*.pds)
nie znam.
PlayStation Patch File (*.ppf)
Na wstępie od razu zaznaczę, że pomimo iż nazwa sugeruje format stricte związany z dziadkiem PSXem, nie służy tylko i wyłącznie do jego obrazów gier. PPF jest jednym z najlepszych (o ile nie najlepszym) dotychczasowym, scenowym formatem łatek. Jego głównymi zaletami są: możliwość przechowywania krótkiego readme/nfo autora (file.diz) i danych pozwalających na odpatchowanie pliku (odwrócenie zapisanych w nim przez łatkę zmian). Niestety ma jedną, dość poważną wadę: nie radzi sobie z plikami o różnych rozmiarach (choć jest na to sposób). Format dostępny jest w trzech wersjach 1.0, 2.0 i 3.0. Wersja 3.0 jest co prawda najlepsza i daje najmniejszy plik wynikowy, ale na chwilę obecną żaden emulator nie obsługuje auto-patchowania PPF3 (może nowy ePSXe zmieni ten stan rzeczy).
programy, którymi można stworzyć PPF:
- MakePPF (win32, osx, freebsd, unix, java, dos)
- PPF-Studio (win32)
programy do patchowania
- ApplyPPF (win32)
- PPF-O-Matic (win32, osx, freebsd, linux, java)
Oczywiście jest ich, dużo, dużo więcej. Wybrałem tylko po dwa: Make/Apply to oryginalne programy Paradox pod cmd/terminal - stare i niewygodne dla "dzieci windowsa". ;P PPF-O-Matic to również program grupy Paradox, tym razem z przystępnym gui i na wiele platform. PPF-Studio natomiast to wg. mnie najwygodniejszy i najlepszy z dostępnych tego rodzaju programów na scenie (które i tak wszystkie oparte są na make/applyppf).
Dla opornych przygotowałem dawno temu dwa tutoriale: robienie łaty i patchowanie.
Patche w postaci plików wykonywalnych.
Tego rodzaju łatki uzależniają użytkownika od OS-u i należy sobie zdawać sprawę z faktu, że nie wszystkie aplikacje zawsze działają (i będą poprawnie działać) na różnych emulatorach itp. Jeśli obraz, rom czy też dump kasety nie wymagają jakiś skomplikowanych operacji (szczególnie w przypadku obrazów płyt dla DC, Xboxa) to zalecam unikać takich wynalazków.
Jeśli jednak się uparłeś, a Pan Bóg poskąpił Ci zdolności programisty jest wiele programów, które np. z *.ips przerobią na *.exe (vide IPS2EXE). Generalnie jednak staraj się unikać takich patchy.
---
Formaty mamy już za sobą, czas poruszyć kilka innych kwestii. Pierwszą z nich jest problem, który onieśmiela większość początkujących użytkowników, mianowicie:
Porównywanie ze sobą plików o różnych rozmiarach.
Otóż właśnie - jest to jedna z bolączek wielu formatów (np. PPF3). Tradycyjnie czyli wybierając mniejszy obraz X.BIN i porównując go z większym Y.BIN (lub odwrotnie) program zrobi sajgon, a nie patch (o ile w ogóle się na to zgodzi). Początkowo pomyślałem, aby dopisać brakujące bajty na końcu pliku, samymi 00h. Niestety po wykonaniu łaty (mimo iż z pozoru wszystko wygląda ok), patch jest niepoprawny!
Panaceum podsunął mi ffgriever. Należy, tak jak napisałem w pierwszym akapicie, zapisać brakujące dane 00h, z wyjątkiem ostatniego bajta, który najlepiej zapisać jako FFh. Przyznam, że nie rozumiem do końca "dlaczego to tak jest", ale faktycznie ten sposób się sprawdza.
---
Przechodzimy zatem do problemu nr. dwa, czyli nietypowe gry. Jakie są to te nietypowe? Takie, które wydawane są/były nietypowych nośnikach/mają nietypowe kompilacje (np. jakiś wymyślny fs). Poniżej postaram się to omówić na kilku platformach:
Na pierwszy ogień idzie Dreamcast. Jak powszechnie wiadomo, wszystkie gry były wydawane na GDI (GD-ROM) o pojemności 1GB. Wszystko byłoby fajnie gdyby GD-R (G lub A) były dostępne dla przeciętnego zjadacza chleba. Niestety tak się nigdy nie stało, więc scena poradziła sobie z kopiami w inny sposób. RIPując te gry. I tutaj jest właśnie problem dla rom-hackera jeśli nie pracuje na oryginalnym, kompletnym obrazie tylko na rip-ie, których jest masa. Są zupełnie inaczej zbudowane, często mają powycinane wstawki FMV, CDDA, downsamplowane pliki dźwiękowe, różnie ulokowanie pliki w tablicy (LBA), selfboot/non-selfboot, z WinCE laoderami etc. Jeśli kiedykolwiek będziesz pracować na jakimś pirackim rip-ie, KONIECZNIE podaj informację w readme, dla której konkretnie wersji (data release'u + nazwa grupy) przeznaczony jest Twój patch. Oczywiście najrozsądniej jest zrobić obraz swojej oryginalnej gry i wtedy nie trzeba się martwić o powyższą masę informacji, które - nie oszukujmy się - praktycznie nic nie mówią przeciętnemu Kowalskiemu.
Xbox/Xbox360, z nimi jest już nieco prościej, ale należy pamiętać o kilku niezmiernie ważnych rzeczach: grę na Xbox'a można skopiować na kilka sposobów: Sposób pierwszy to niepełny dump, czyli obraz pozbawiony pierwszego tracka DVD-Video, który skutecznie oszukuje standardowe napędy i nie pozwala sczytać w standardowy sposób danych na XDFS (fs xbox'owej płyty). W tym przypadku NIE należy robić patcha z obrazu płyty, tylko na poszczególne pliki! Dlaczego? Ponieważ jeśli ktoś będzie mieć jakąś rebuildowaną kopię, albo pełny obraz gry to patch NIE będzie pasować. Sposób drugi do kompletny obraz gry, który wykonuj się tak samo jak dla Xbox'a 360. Tutaj ze wszech miar zalecany jest patch na obraz (tylko bez SS, PFI i DMI!), ponieważ LBA obu obrazów: i Twojego i użytkownika będzie identyczne.
GameCube/Wii. Tutaj sprawa jest już bardzo prosta. Obraz można wykonać kilkoma modelami napędów, więc nie należy się martwić o niepoprawny/niepełny dump. Pamiętać należy tylko aby NIE usuwać garbage data.
PlayStation/PlayStation (CD). Jak powyżej też bardzo prosta kompilacja. Niestety, w czasach w których nie używa się mode2 mało kto o tym pamięta, aby pracować na obrazach sczytanych właśnie w tym trybie. Dlaczego? Odczytując grę w mode1 tracimy dane z subkanałów i inne informacje, które mogą być używane przez grę jako rodzaj zabezpieczenia (kiedyś nagrywarki nie wspierały RAW-DAO96).
---
Jeszcze to czytasz? Twardy jesteś. ;) To czas teraz na korekcję bloków ECC/EDC. Wbrew pozorom nie jest to tak strasznie jak brzmi. Czym jest ECC i EDC to poczytasz sobie na Wiki, my się skupimy na czym innym: po co je naprawiać? Powodów jest jak zwykle kilka. Pierwszy i najważniejszy: większość napędów nie radzi sobie z niepoprawnymi ECC i najczęściej wtedy zawiesza grę. Powód drugi: użytkownicy, do których kierujesz swój hack gry tym bardziej nie mają (i nie muszą mieć) o tym pojęcia, więc dla swojego spokoju zrób patch jak trzeba albo przygotuj się na tonę pytań w stylu: "czemu to k* nie działa". :)
---
Huh, przebrnęliśmy przez stricte techniczne aspekty - czas na merytoryczne.
Przyszedł czas na dodatkowy i niezbędny plik, mianowicie: readme aka "czytaj to!". Jak już dowiedziałeś się na początku tego krótkiego artykułu, różne formaty patchy, przechowują różne, dodatkowe dane - niektóre oczywiście wcale nie przechowują i głównie z myślą o nich powinieneś w readme napisać:
- czym jest Twój patch (spolszczenie, jeśli inny hack to podać jego tytuł etc.)
- co konkretnie modyfikuje
- listę zmian (mile widziana, ale tak naprawdę w Polsce mało kto sobie nią zaprząta głowę - w tym i ja - lamerzy ;])
- i najważniejsze: na jaką wersję gry jest przeznaczony (pal/ntsc, jeśli rom to należy trzymać się ich nazewnictwa itd.)
Najlepszy moim zdaniem format dla tego, nazwijmy go - dokumentu - to zwykły plik tekstowy kodowany w ANSI lub UTF-8. Z miejsca należy odpuścić sobie *.html-e, *.pdf-y czy nie daj Bóg *.doc i flashe. Prostota = funkcjonalność. Pamiętaj.
---
No to na razie tyle. Jeśli jeszcze nie dostałeś wodogłowia i/lub masz jakieś pytania/uwagi, należy zadawać je w temacie: "Patch - jak to zrobić".