[J2V]Game 4D: God of War Ghost of Sparta Việt ngữ

chơi ps3 thì chắc giờ chỉ còn đường PS NOW. Mà ở VN thì lag tụt quần.

 

Ban us

 

bản chain of olympus có vẻ khá dễ chơi ở cáp normal , lần đầu chơi bản 1 chết lên chết xuống vì mấy cái bẫy , rương giấu rất kĩ dễ miss , thấy bản 2 và bản COO thấy dễ hơn hẳn
chừng nào bác chủ thớt dịch xong nhỉ , down về chơi thử ủng hộ bác

 

chả hiểu sao ngày xưa ngồi chơi mê mệt GoW 1, sang bản 2-3 thấy không hay bằng bản 1 về cách chơi lắm.
trước thức đêm chơi ngủ quên không khóa cửa trộm nó vào rinh cmn cái máy với đt...

 

máy chơi game mà cũng nhận biết được mà rinh á? thằng trộm nào thức thời thế?

 

mở máy chơi rồi ngủ quên, may là nó chỉ rinh có cái máy với đt

 

Còn nhà ngươi, sao nó không rinh luôn đi ... thằng trộm này dốt thế

 

chắc thằng trộm nó trai thẳng

 

forum mình ko thấy topic về games trên psp nhỉ ? ko biết ngoài 2 phần GOW thì psp có game nào hay ko , giới thiệu vài game chơi tết với các bác ?

 

http://forum.gamevn.com/threads/psp...war-of-the-lions-ban-dich-tieng-viet.1279647/

 

hỏi ngu là psvista có khác psp ko ? thank bác trên nhưng dòng FF ngán rồi nên ko chơi đâu

 

II. Quy trình

1. Mua vui một vài trống canh

Quy trình để chuyển ngữ một game từ ngôn ngữ này sang ngôn ngữ nọ luôn có những bước chính sau đây, chung cho mọi hệ thống, dù đó là PC, Snes, PS, Xbox, Genesis hay gì đi nữa.

- Tìm, xác định bộ font và sửa đổi nó
- Tìm và xác định text (thoại, chữ) trong ngôn ngữ nguồn, sửa đổi nó sang ngôn ngữ đích

Đây là hai bước chủ chốt, bất di bất dịch, luôn được áp dụng trong mọi trường hợp. Tuy nhiên trong thực tế, ta có thể phải làm nhiều bước nhỏ hơn để đến được hai cái đích lớn này, tùy từng trường hợp. Các bước nhỏ hơn có thể là:

- Giải nén font/text nếu chúng bị nén
- Giải mã font/text nếu chúng bị nén
- Nén lại font/text sau khi chỉnh sửa
- Mã hóa lại font/text sau khi chỉnh sửa
- Viết lại chương trình để tối ưu hóa việc hiển thị/đọc text
- Chỉnh sửa độ rộng của từng ký tự cho phù hợp với văn bản ngôn ngữ đích
- Viết chương trình độ rộng biến thiên theo từng ký tự cho phù hợp với ngôn ngữ đích, nếu như trong ngôn ngữ nguồn không có chương trình này
- Trích xuất (dump) text từ Rom/game ra ngoài file văn bản
- Chèn text đã dịch vào Rom/game

Spoiler: Hạo nãi

Trên đây chỉ là một số vấn đề nho nhỏ thường gặp trong quá trình dịch game. Đối với các yêu cầu đầu tiên thì đòi hỏi phải có kiến thức chuyên sâu vào game mình cần dịch, hay nói nôm na là kiến thức về ngôn ngữ để viết nên game đó. Cụ thể ở đây là ngôn ngữ Assembly Mips, cộng với kiến thức về đặc trưng phần cứng của hệ máy, nó sẽ giúp ta xác định mọi thứ trong cái game cần dịch.

Ngoài lề: bản thân tôi không phải lập trình viên, không học ngành IT nhưng nhờ ham đọc tài liệu (sách + Google) mà đã có được một số kiến thức cơ bản về phần cứng, Assembly cho các hệ máy. Do vậy đừng nghĩ những gì tôi đề cập bên trên là cao siêu vượt quá tầm của bạn.

2. Cấu trúc đĩa

Game cho PSP được lưu trữ trên đĩa UMD do chính Sony phát triển, nó có thể chứa tối đa 1.8GB dữ liệu nên việc tìm kiếm một thứ gì đó trong đĩa sẽ rất khó, hoặc không thể nếu không có phương pháp tìm kiếm khoa học.
Đầu tiên cần biết về cấu trúc dữ liệu của game PSP lưu trên UMD.

- Thư mục gốc\UMD_DATA.BIN chứa các thông tin về đĩa game như mã số game, phân vùng khu vực.
- Thư mục gốc\PSP_GAME chứa các Icon ở định dạng PNG, các file thông tin khác và hai thư mục quan trọng là SYSDIR và USRDIR.
- SYSDIR chứa file EBOOT.BIN, đây là file khởi động của PSP, tương đương với file .exe trên PC. Nói chung chỉ cần nhìn tên là biết SYSDIR là thư mục hệ thống.
-USRDIR là thư mục User, tùy từng nhà sản xuất game mà tên gọi file, folder bên trong đó khác nhau. Đây là nơi chứa dữ liệu của game.

Nếu bạn mở GOW GOS (bản tiếng Nhật) bằng CD Mage hoặc UMD thì sẽ thấy cấu trúc file/folder như hình dưới đây.




Bạn có thể dùng bất kỳ phần mềm nào khác để mở file ISO, ở đây tôi quen dùng CD Mage.

III. Bắt tay vào việc: tìm và xử lý font chữ

1. Khái niệm về font

Trước tiên cần hiểu khái niệm font chữ. Từ "font" bao hàm cả hai ý nghĩa sau:

- Diện mạo (cao gầy béo lùn to tròn...) hay ngoại quan của chữ
- Dữ liệu (gồm 0 và 1) cấu thành nên cái diện mạo bên trên

Đối với người dùng máy tính ở cấp phổ thông thì khi nói tới font, người ta chỉ nói tới cái ý nghĩa thứ nhất (như font Arial, font Tahoma... là nói tới ngoại quan). Còn ở cấp sâu hơn, phải đề cập tới ý nghĩa thứ hai. Vì lý do này mà hay nghe nhiều bạn kêu khổ:

- Game này không hỗ trợ font tiếng Việt, em gõ dấu toàn ra lỗi
- Game này không dùng font Unicode, em không Việt hóa được

Đó là do chưa hiểu rõ về bản chất của font.
Về bản chất thì font chữ cũng chỉ là một dạng hình ảnh đồ họa. Tất cả mọi thành phần được hiển thị trên màn hình PC, console đều là đồ họa hết, dù ở định dạng gì đi nữa.

Dòng PS của Sony, trong đó có PSP là máy chơi game sử dụng đồ họa pixel. Trái với các dòng NES, SNES của Nintendō là đồ họa dạng mảng (tile). Đối với hai loại máy của Nintendō thì một đơn vị đồ họa nhỏ nhất mà máy thể hiện được là một ô vuông 8x8 pixel, còn đối với dòng PSP thì đơn vị nhỏ nhất là 01 pixel, tức là chiếm diện tích nhỏ hơn 64 lần, khiến hình ảnh mịn hơn.

Quay trở lại ý nghĩa thứ hai của font, về bản chất nó là một chuỗi dài gồm 0 và 1. Khi máy gặp phải giá trị 0, nó sẽ thể hiện khoảng trống ra màn hình. Còn khi gặp giá trị 1, nó thể hiện một điểm (pixel) ra màn hình.

Lấy ví dụ về chữ "a" có kích thước 8x8 pixel như dưới đây. Ta xem những ô trống là 0 (không hiển thị ảnh), những ô có hiển thị ảnh là 1 thì chữ “a” sẽ như sau.

​

Đổi chuỗi này sang hệ thập lục, ta được $387EC6C6C6C67F3B. Đây là giá trị cho chữ “a” nếu ta xem bằng Hex editor. Còn khi máy tính (Super Famicom) hoạt động, nó chỉ hiểu được chuỗi
11100001111110110001101100011011000110110001100111111100111011 mà thôi.

Ngoài ra còn có khái niệm bitplane, hay bit per pixel. Chữ "a" bên trên là 01 bpp (1 bit cho mỗi pixel) nên nó có hai trạng thái màu: không màu (giá trị 0) và có màu (giá trị 1). Đối với 2bpp, hình ảnh sẽ có 4 màu, 4bpp là 8 màu...

Lấy ví dụ về chữ "a" bên trên, nhưng lần này là 2bpp. Thực chất, 2 bpp là dạng triển khai của 1 bpp, trong đó có 1 bit plane thể hiện phần thịt của chữ, 1 bit plane còn lại thể hiện phần bóng mờ của chữ. Nếu font càng sử dụng nhiều bit plane thì nó sẽ có nhiều cấp độ bóng mờ. Nhiều game console sau này sử dụng font nhiều bit plane để tạo ra hiệu ứng đổ bóng nhiều màu, nhiều cấp độ để việc hiển thị chữ được đẹp hơn, rõ ràng hơn so với việc chỉ dùng 1 bit plane (chỉ gồm phần thịt của chữ, không có bóng).

​

Lồng ghép vào nhau

​

2. Xác định font

GOW GOS có nhiều chế độ ngôn ngữ. Bản EU có các ngôn ngữ: Anh, Pháp, Ý, Hy Lạp... trong một đĩa UMD. Còn bản JP có hai ngôn ngữ: Nhật và Anh trong cùng một đĩa UMD. Đối với giả lập PPSSPP, nó sẽ tự động chọn ngôn ngữ trong game dựa vào ngôn ngữ của giả lập.

Đầu tiên, hãy chọn ngôn ngữ tiếng Anh cho giả lập PPSSPP. Ta sẽ tìm font chữ trong bản tiếng Anh. Vào game, chụp lại ảnh màn hình đầu tiên.

​

Phóng to phần chữ trong phần mềm xem ảnh, để ý kỹ thì sẽ thấy phần chữ có 16 màu. Tức font chữ ở đây là 4bpp.

​

Bây giờ chọn New Game để xem cảnh mở đầu của GOS. Từ giao diện PPSSPP, vào Debug --> GE Debugger hoặc dùng phím tắt Ctr + G để bật Debugger đồ họa của PPSSPP.

Trong GE Debugger ta thấy có các nút sau và ý nghĩa của chúng sau một thời gian mày mò:

- Step frame: dừng game và cho biết các lệnh xử lý mọi thành phần đồ họa trong frame (khung hình) tiếp theo.
- Step Tex: dừng game và cho biết các lệnh và thông tin liên quan tới texture đang được xử lý. Font chữ cũng là một dạng texture.
- Step Draw: dừng game và cho biết các lệnh và thông tin liên quan tới những gì sẽ được vẽ ra màn hình
- Step Prim: dừng game và thể hiện các thành phần trong texture sắp được vẽ ra màn hình. Những thành phần này được bôi đỏ ở khung preview bên phải.
- Step Into: dừng game và đi vào từng lệnh đồ họa một, ở cấp chi tiết nhất, hết lệnh này đến lệnh kia.
- Resume: thoát khỏi chế độ debug, cho game tiếp tục chạy.



Như vậy, sau khi click vào ô "Step Tex" nhiều lần, ta sẽ thấy hình ảnh font chữ hiện ra ở khung preview bên phải. Bên dưới là dòng thông tin:

- Texture L0: 0x8cfd3d0 (128x128)

Dòng này có ý nghĩa: Texture (font) cấp độ 0 nằm ở địa chỉ 0x8CFD3D0 trong Ram và bộ font này có kích thước 128x128 pixel.
Đọc tài liệu kỹ thuật về PSP, ta biết được console này có Ram 24MB, bắt đầu từ địa chỉ 0x08800000. Đối với các loại console cũ như NES, SNES do dung lượng Ram hạn chế nên CPU đọc dữ liệu và lệnh xử lý từ Rom. Còn đối với những dòng console đời sau, cấu hình mạnh hơn và nhiều Ram hơn thì CPU thường copy dữ liệu, lệnh từ Rom vào Ram, sau đó mới đọc các dữ liệu này từ Ram.

​

GOW GOS cũng đọc dữ liệu từ Ram. Bây giờ, từ giao diện PPSSPP vào Debug --> Memory View (hoặc Ctrl + M) để mở công cụ xem Ram. Gõ địa chỉ 0x8CFD3D0 vào ô "Goto", Enter để đi đến địa chỉ này. Tại đây ta thấy được dữ liệu của font ở khung preview bên phải.
Từ đây ta có hai cách xác định dữ liệu này nằm ở đâu trong đĩa UMD.

Cách thủ thuật:

- Để ý tìm một chuỗi giá trị đặc trưng trong Memory View. Ở đây tôi để ý đến chuỗi 20 22 62 00 30. Bạn có thể dùng chuỗi khác.
- Mở file ISO bằng Hex editor, tìm chuỗi kể trên. Kết quả tôi tìm được chuỗi này nằm ở 0x4A955E75 trong file ISO. Nói cách khác, dữ liệu font bắt đầu ở 0x4A955E10.
- Đọc tài liệu kỹ thuật về đĩa CD/UMD thì ta biết khái niệm LBA. 1 LBA = 0x800 byte. Lấy địa chỉ 0x4A955E10 chia cho 0x800 ta được 0x952AB hay 610987. Điều này cho thấy dữ liệu font nằm ở vị trí LBA 610987.
- Quay trở lại phần cấu trúc UMD, ta thấy file PSP_GAME\USRDIR\DATA\ENGLISH\GAME.BIN bắt đầu ở LBA 610960 và kết thúc ở 610991. Dữ liệu font nằm ở LBA 610987 thuộc phạm vi này, như vậy ta kết luận font chữ nằm ở file PSP_GAME\USRDIR\DATA\ENGLISH\GAME.BIN.

​

Cách khoa học:

Nếu đọc tài liệu kỹ thuật của PSP, ta biết CPU MIPS có khái niệm gọi là "syscall". Có thể hiểu nôm na nó là chức năng của hệ điều hành, nói rõ hơn là chức năng của kernel. Khi phần mềm (game) đang chạy, nếu nó gặp lệnh syscall thì nó sẽ giao quyền xử lý cho hệ điều hành.

Đối với MIPS, chức năng của syscall phụ thuộc vào giá trị của register $v0. Chẳng hạn, giá trị này là 1 thì kernel sẽ in con số nguyên ra màn hình console, nếu giá trị này là 4 thì kernel sẽ in chữ ra màn hình console...

Lấy ví dụ:

text: asciiz "Hello"

la $a0, text #đưa địa chỉ chuỗi text vào $a0
li $v0, 4 # đưa giá trị 4 vào $v0
syscall #in ra màn hình console chuỗi text "Hello"

Tùy vào giá trị của $v0 mà nội dung của syscall sẽ khác nhau. Và cũng tùy nội dung mà các tham số cũng thay đổi. Đối với chức năng syscall này thì tham số là register $a0, nhưng đối với chức năng khác thì lại cần $a1, $s0....

Quay trở lại vấn đề chính, ta đã biết dữ liệu font bắt đầu tại địa chỉ 0x8CFD3D0 trong Ram. Tiếp theo:

- Từ giao diện PPSSPP --> Debug --> Disassemble (Ctr + D).
- Đặt địa chỉ breakpoint: 0x8CFD3D0, chỉ tích mục "write". Điều này có nghĩa là bất cứ khi nào CPU ghi dữ liệu vào địa chỉ trên, nó sẽ dừng game để ta có thể truy lại các lệnh xử dẫn đến việc ghi dữ liệu vào vùng Ram trên.
- Reset lại game (vì GOS ghi font vào Ram từ lúc đầu), lúc này CPU sẽ ngừng xử lý game.
- Khi CPU ngừng game, lần lượt click vào "Step Into" để đi vào từng lệnh chi tiết. Sau một vài lệnh, ta thấy dòng xử lý di chuyển tới 0x880868C trong Ram với nội dung: JAL zz_sceIoRead và giá trị $v0 lúc này là FE18, kích thước của file cần đọc.
- zz_sceIoRead là chức năng syscall đọc file từ đĩa UMD của PSP. Chức năng này sử dụng tham số đường dẫn đến file đã mở trong chức năng zz_sceIoOpen trước đó. Tham số $s3 cho ta biết thông tin về vị trí của file cần đọc trên đĩa.
- Giá trị của $s3 lúc này là 8CFF4A4. Nhảy tới địa chỉ này trong Ram và ta thấy được thông tin về vị trí file trên đĩa:

disc0:/PSP_GAME/USRDIR/DATA/ENGLISH/GAME.BIN

​

Như vậy, ta đã xác định được file chứa dữ liệu font: GAME.BIN. Đây là một file hỗn hợp gồm nhiều file nhỏ khác nhau. Mở file bằng Hex editor, dễ dàng xác định phần "file chứa font bắt đầu từ 0xDDB0 nhưng dữ liệu font thật sự bắt đầu ở DE10 vì 0x60 byte đầu tiên là header.

Copy dữ liệu từ 0xDDB0 đến hết file GAME.BIN, tạo thành file mới và mở bằng các phần mềm như Crystal Tile hay Tile Molester, điền các thông số như bpp (mà ta đã xác định ở bước đầu tiên) ta sẽ thấy được hình ảnh font.

​

Lúc này chỉ cần export hình ảnh ra dạng PNG hoặc BMP, chỉnh sửa bộ font này rồi import vào GAME.BIN là kết thúc công việc.

Lưu ý: nếu dùng phần mềm Tile Molester thì phải chèn thêm một số dummy byte vào cuối file để nó hiển thị hết bộ font. Đây là bug của phần mềm.

(Còn tiếp)

 

Mấy cái chọn ngôn ngữ giả lập, rồi dùng crystaltile2 tốt hơn tilemolester, setting crystaltile2, là nhờ ai nhắc vậy nhỉ? ị hị hị
dump text đi bác uôi, em dịch gần xong roài.
thật tuyệt khi học hỏi 1 cách bài bản và hệ thống như này, nhưng em sẽ bookmark lại để dành cho những dự án sau còn dự án này cứ nhờ bác đã.
thật ra do font eng ít chữ quá không thì cũng không cần phải nhờ vả làm chi.

 

Thanks đã cho biết chỉnh ngôn ngữ giả lập.
Sau đó tôi tìm thấy trong mớ Syscall của PSP có cả chức năng chọn ngôn ngữ, tức là khi đã debug thì sớm muộn gì cũng lòi ra hết thôi



Mấy cái phần mềm thì dùng nhiều rồi quen thôi.

 

Giải thích rõ hơn về syscall.

https://courses.missouristate.edu/KenVollmar/mars/Help/SyscallHelp.html

 

Kratos không phải là Cratos

 

nhầm nhọt, tại thằng FFX độc quyền PS2 (Sony đăt hàng Square) đâm cứ mặc định đấy là hàng của Sony

 

III. Bắt tay vào việc: xác định text

Spoiler: Hão nại

Trong phần trước, ta đã xác định được font chữ (nói đúng hơn là texture chữ) để chỉnh sửa nó. Tuy nhiên, nếu để ý kỹ thì sẽ thấy hai điểm khó khăn trong phần font của bản Anh ngữ mà ta đã xác định:

- Bảng font chỉ gồm 26 chữ cái La Tinh và một số ký tự Ascii khác, không đủ nhiều để có thể chèn chữ La Tinh có dấu trong tiếng Việt. Số lượng chữ có dấu và không dấu trong tiếng Việt (không tính chữ in hoa) đã hơn 60. Vậy phải làm sao?
- Bảng font chỉ có một kiểu chữ là in hoa, không có chữ thường.

Đối với vấn đề chữ hoa, thực ra là trong game vẫn hiển thị đầy đủ chữ hoa và chữ thường. Chỉ là cùng một kiểu chữ nên khó nhận ra. Đối với chữ thường, phần code trong game sẽ làm chữ nhỏ hơn phần chữ hoa nhưng thực chất vẫn dùng cùng một texture với chữ hoa. Đối với vấn đề thiếu ký tự có dấu cho tiếng Việt, ta có thể giải quyết dễ dàng nếu để ý các phiên bản ngôn ngữ khác của GOW GOS. Cụ thể là bản tiếng Nhật, với số lượng chữ Kana và chữ Hán lên tới hàng ngàn chữ. Nhưng làm thế nào để mở rộng bản font đặng còn thêm chữ vào? Vấn đề này tôi sẽ giải thích ở phần sau.

Còn bây giờ, việc cần làm là xác định vị trí của text trong Iso. Hay nói chuẩn xác hơn là xác định kiểu encoding của text. Text encoding có nhiều kiểu, chẳng hạn kiểu đơn giản nhất là chuẩn Ascii với các ký tự La Tinh cơ bản không dấu tương ứng với mỗi con số (hệ thập lục) như 41=A, 42=B, 6A=j, 6B=k,.... Ngoài ra còn nhiều kiểu encoding khác phức tạp hơn như Shift-Jis, Unicode,... và cũng có những kiểu encoding không theo một quy chuẩn nào, thường thấy trong game thế hệ cũ như Nes, Snes, Saturn, PSX,... Với những kiểu encoding khác nhau thì tuy cùng một chữ cái nhưng giá trị tương ứng của nó là khác nhau. Chẳng hạn nếu theo chuẩn Ascii thì chữ "A" tương đương với số 41, nhưng theo một chuẩn khác thì chữ này có thể là số 5C,....

1. Xác định encoding theo cách thủ thuật

Cách làm này mang tính hú họa, đoán mò, được chăng hay chớ và sẽ không áp dụng được nếu như game không dùng kiểu Ascii hoặc nếu text bị mã hóa/nén. Nhưng may mắn thay là GOS bản tiếng Anh và các ngôn ngữ Âu châu khác đều dùng Ascii, và cũng không bị mã hóa hay nén nên ta có thể áp dụng trong trường hợp này. Dù sao đây cũng là cách đơn giản nhất, ít tốn thời gian nhất nên cứ thử.

Đầu tiên, tìm một đoạn text ở vị trí thuận tiện nhất, chẳng hạn ở gần save point hoặc đoạn mở đầu.



Như đã biết, mỗi chữ La Tinh trong kiểu encoding Ascii tương đương với một con số thập lục. Như vậy, phần text trong đoạn mở đầu sẽ nằm đâu đó trong Iso.
Tiếp theo, mở Iso bằng Hex editor và tìm kiếm chuỗi text:

"Kratos, the Ghost of Sparta"

hoặc có thể dò tìm những cụm từ khác trong câu trên.

Và kết quả ta tìm được địa chỉ dòng text trên.



Áp dụng cách chia địa chỉ cho $800 để tính LBA như ở phần trước, ta biết được phần text này nằm trong file DATA\ENGLISH\R6_INTRO.BIN

2. Xác định encoding theo cách khoa học

Trong phần trước ta đã xác định được font bằng cách set write break point cho texture. Kết quả cho biết là chức năng syscall zz_sceIoRead là thứ đã ghi dữ liệu texture từ UMD (Iso) vào Ram. Và zz_sceIoRead sử dụng đường dẫn đến file mà zz_sceIoOpen đã mở trước đó. Lần này ta không biết trước dữ liệu (text) được ghi vào Ram là những gì, nên không thể set write break point. Nhưng ta đã biết zz_sceIoRead là thứ ghi dữ liệu vào Ram, vậy có thể set execute break point ở zz_sceIoRead để CPU dừng xử lý mỗi khi nó gặp phải syscall này. Cách set như hình dưới.



(Từ debug console, chuyển từ tab Regs sang tab Funcs, kéo xuống dưới để thấy các syscall và double click vào syscall cần set)

Ngoài ra, còn một chức năng khác cũng có thể đọc dữ liệu từ file trong UMD và ghi vào Ram, là sceIOReadAsync. Do vậy nên set break point ở cả hai syscall này.

Sau khi set break point, khởi động lại game. Có thể có nhiều lần CPU dừng xử lý khi gặp hai syscall ta vừa set, vì có thể nó cần mở nhiều file khác nhau, trong đó có file ta cần xác định.

Sau nhiều lần CPU dừng, ta có thể xác định sceIOReadAsync mới là chức năng đọc chuỗi text trên.



Lần lượt click Step Into để theo dấu từng lệnh xử lý. Lúc này ta thấy $a1 chứa giá trị địa chỉ mà CPU đọc chuỗi text từ Ram (0x9DE9C00) và $s1 là địa chỉ phần đường dẫn đến file đã mở (0x9DE01F0).



Như vậy ta đã xác định được chuỗi text cần tìm nằm ở file nào.

Lưu ý: nên save state trước đoạn cần debug, vì có thể các địa chỉ ghi vào Ram thay đổi mỗi lần. Khi save state ngay trước đoạn cần debug, vì như thế ta đã save luôn cả "chủng tử" (seed) cho số ngẫu nhiên được chọn làm địa chỉ ghi Ram. Tham khảo thêm bài này (https://gokuraku-shujo.blogspot.com/2016/10/so-ngau-nhien.html) để biết thêm về số ngẫu nhiên.


3. Tìm Pointer

Pointer là con số chỉ đến địa chỉ bắt đầu của từng câu thoại. Vì sao phải dùng nó? Vì nó giúp cho việc viết lời thoại (text) trong game được linh động hơn. Khi nhà sản xuất thay đổi câu chữ, làm độ dài của chuỗi thay đổi theo thì họ không phải mất công sửa đổi thôi. Nói nôm na, Pointer giống như một dạng label.

Đọc bài này (https://gokuraku-shujo.blogspot.com/2015/03/dich-thuat-ff9.html) để hiểu thêm về Pointer.

Sau khi xác định được file chứa text, mở file bằng Hex editor và ta dễ dàng xác định được Pointer bằng mắt thường đối với những ai đã quen với việc này:

- Gồm 4 byte (thường chỉ sử dụng 2 byte cuối vì GOS không có text nào đủ dài để dùng đến 2 byte đầu)
- Mỗi Pointer cách nhau 0x0E byte

Tuy nhiên cách xác định bằng mắt thường chỉ áp dụng cho trường hợp file nhỏ, người đã quen. Còn đối với những trường hợp khác thì nên sử dụng debugger để tìm, cách thức tương tự như những phần trước.

Chẳng hạn, câu thoại đầu tiên được đọc từ vị trí 0x9DEA1C3 trong Ram. Chỉ cần set read break point tại địa chỉ đó thì CPU sẽ dừng lại ngay trước lệnh đọc tại địa chỉ này. Từ đó ta truy ngược code xử lý và sẽ thấy đoạn:



08ABB4E0 lw v0,0x4(t0) #đọc giá trị tại địa chỉ $t0 + 4, chứa vào $v0. Địa chỉ $t0 là 0x9DE9E50 + 4 = 0x9DE9E54. Giá trị tại địa chỉ này là 000002BB.
08ABB4E4 addu v0,a0,v0 # lấy giá trị hiện tại của v0 + giá trị của a0 rồi ghi vào v0. Giá trị hiện tại của v0 là 0x9DE9F08, vị trí bắt đầu của khối text.

Như vậy có thể thấy mối liên kết giữa Pointer và địa chỉ bắt đầu câu thoại trong GOS như sau:

- Địa chỉ bắt đầu text = địa chỉ bắt đầu khối text + giá trị Pointer

Đây là điều hết sức bình thường và quen thuộc với các hệ máy console.

(Còn tiếp)

 

Thank bác asm . bài viết rất hay . Cho em hỏi với các hệ máy như nds hoặc psvita thì cách làm có tương tự thế này không ? . Bác đã thử 2 hệ này chưa vậy ?

 

Mỗi hệ máy mỗi khác, nhưng các bước cơ bản để dịch một game thì giống nhau.
Nói về hack để dịch thì có 2 kiểu chính:
- Dùng thủ thuật, aka làm mò
- Dùng kiến thức, cái này cần có debugger

PSVita mình chưa thử (hình như chưa có giả lập??) còn NDS thì cũng vọc rồi, cũng đơn giản.

Để làm được thì điều kiện cần thiết nhất là phải có giả lập của hệ máy đó, và giả lập phải có chức năng debug. Từ đó mới biết được các lệnh được xử lý ra sao, ta nắm được những gì đang được xử lý tại một thời điểm.