[Hướng dẫn]Dịch Mộc đế 5 (Thracia 776)
- Thread starter asm65816
- Ngày gửi
asm65816
Mega Man
- 23/5/09
- 3,320
- 4,851
- Thread starter
- #25
IV. Chỉnh độ rộng của chữ
Có lẽ nhiều người dùng máy tính đã quá quen thuộc với khái niệm độ rộng của ký tự đến nỗi họ không nhận ra nó nữa. Nếu để ý quan sát một chút thì sẽ thấy hầu hết font chữ trên PC đều có độ rộng không bằng nhau cho từng ký tự, chẳng hạn chữ “n” sẽ hẹp hơn chữ “m” và rộng hơn chữ “i”. Thật khó coi nếu tất cả các ký tự La Tinh đều rộng bằng nhau, chẳng hạn như “c á i g ì t h ế n à y ?”
Thuật ngữ gọi bộ font có độ rộng khác nhau giữa các ký tự là “variable width font”, hay chuẩn xác hơn là “proportional font”, còn bộ font có các ký tự rộng bằng nhau là “fixed width font” hay đúng hơn là “mono-spaced font”.
Hầu hết các bộ font trên PC đều là proportional font, do vậy việc dịch game PC thường không đòi hỏi chỉnh lại độ rộng của font chữ, vì nó đã bao hàm sẵn trong bộ font rồi (trừ một vài game PC được port từ console sang). Trái lại, đa phần game console tiếng Nhật thường sử dụng mono-spaced font, tức các ký tự trong bảng chữ đều rộng bằng nhau. Khi ta thay font Nhật đó bằng font La Tinh thì sẽ “t r ô n g r ấ t x ấ u n h ư c o n g ấ u”.
Như hình trên, sau khi ta thay các ký tự Kana trong bộ font thành ký tự La Tinh thì sẽ nhận thấy một khoảng trống khá rộng theo sau những ký tự này. Lý do là ký tự Kana ban đầu rộng hơn ký tự La Tinh mà ta vẽ lại.
Do vậy, khi dịch game console thì ta luôn phải để tâm tới việc này. Độ rộng của từng ký tự có thể được thay đổi thông qua đoạn code điều chỉnh. Đối với (đa phần) game không đoạn code này thì phải viết thêm, dựa trên routine in chữ ra màn hình của game và việc này đòi hỏi phải có kiến thức về ngôn ngữ Assembly để thực hiện. Còn đối với một số game có sẵn code chỉnh độ rộng như Fire Emblem thì không cần phải có kiến thức về Assembly mà chỉ cần một chút suy luận là làm được, nhưng nếu có hiểu biết về Asm thì công việc sẽ dễ dàng và khoa học hơn.
Cách 1:
+ Đầu tiên chụp màn hình game đối với Rom nguyên gốc chưa chỉnh sửa, chụp chỗ nào có hội thoại và nhớ là chỉ chụp bằng chức năng của giả lập để có độ phân giải đúng (256x224 pixel).
+ Phóng to ảnh, “đếm” số pixel của từng ký tự. Nên đếm cho những ký tự đứng cạnh nhau trong bảng font. Chẳng hạn như chữ “ke” dưới đây rộng 12 pixel, “ku” là 10 pixel….
+ Dò tìm chuỗi giá trị vừa tìm được trong Hex editor. Chẳng hạn, ta đã biết “ki” có độ rộng 11 (0B) pixel, ku là 10 (0A) pixel, ke là 12 (0C) pixel, ko là 11 (0B) pixel bằng phương pháp đếm, và ta cũng biết ki, ku, ke, ko đứng liền nhau trong bảng font. Vậy, mở Rom bằng Hex editor và dò tìm chuỗi 0B-0A-0C-0B thì được một số kết quả (chuỗi tìm kiếm càng dài thì kết quả càng chuẩn). Thử từng kết quả để biết rằng chuỗi này bắt đầu tại $A9A50.
+ Kiểm chứng: tại $A9A50 ta thấy chuỗi 0C 0B 0B 0C 0C…. ứng với độ rộng của a, i, u, e, o…. Thử thay các giá trị này thành 0F (16 pixel, rộng hơn ban đầu) thì ta được
Rõ ràng khoảng cách giữa các ký tự Kana đã dãn rộng ra. Ngược lại, thử thay các giá trị mặc định tại $A9A50 bằng con số nhỏ hơn (chẳng hạn, 07) và ta được
Như vậy, khoảng cách giữa các chữ Kana đã bị thu hẹp. Điều này cho thấy bắt đầu từ $A9A50 là những con số điều chỉnh độ rộng của từng ký tự trong bảng font.
Hình dưới đây đã điều chỉnh độ rộng của ký tự La Tinh sau khi thay thế font và xóa bỏ chữ Hán, cho kết quả đều đặn dễ nhìn.
Cách 2: nếu như cách trên có vẻ thủ công và “ăn may” thì cách này đòi hỏi một số kiến thức nhất định về ngôn ngữ Assembly 65816 của máy Snes. Ở đây dùng Debugger của giả lập Snes9X để xác định code độ rộng.
+ Ta đã biết, bộ font bắt đầu bằng chữ Kana “a” tại $340000. Tuy nhiên, địa chỉ này chỉ đúng khi ta xem bằng Hex editor hay các phần mềm trên PC. Còn trên máy Snes, khi nó thực thi chương trình thì địa chỉ này không còn đúng. Có khái niệm gọi là “địa chỉ Snes”, và ở đây dùng phần mềm Lunar Address để xác định (nếu không thì phải dùng kiến thức Memory Mapper của Snes để xác định).
+ Khai báo các thông tin về loại Rom (FE5 là LoROM) cho Lunar Address, nhập địa chỉ $340000 (PC) và ta được địa chỉ Snes tương ứng là $ E88000.
+ Chạy Debugger của Snes9X, click vào tab “Breakpoint”, nhập địa chỉ E88000 vào trong ô và tích vào ô “read”. Điều này có nghĩa rằng Debugger sẽ thực thi lần lượt các lệnh của chương trình (game), cho tới khi nó gặp phải lệnh “đọc” địa chỉ mà ta vừa ra điều kiện. Lúc này Debugger sẽ đứng lại và hiển thị các thông tin liên quan.
Click vào tab “Skip Op” để kiểm tra lần lượt từng lệnh trong routine đọc địa chỉ E88000, từ đó lần theo các dấu vết (phải hiểu được ý nghĩa của từng lệnh, ở đây tôi không đi sâu vào phần này vì sẽ mất nhiều thời gian) và cuối cùng ta được dẫn tới routine $95/9A20 20 2B 9A JSR $9A2B [$83:9A2B] (bắt đầu tại $A9A20) và routine này kết thúc tại $A9A4F ($95/9A4F 60 RTS). Ngay sau đó (từ $A9A50) là phần code chỉnh độ rộng cho từng ký tự.
Có lẽ nhiều người dùng máy tính đã quá quen thuộc với khái niệm độ rộng của ký tự đến nỗi họ không nhận ra nó nữa. Nếu để ý quan sát một chút thì sẽ thấy hầu hết font chữ trên PC đều có độ rộng không bằng nhau cho từng ký tự, chẳng hạn chữ “n” sẽ hẹp hơn chữ “m” và rộng hơn chữ “i”. Thật khó coi nếu tất cả các ký tự La Tinh đều rộng bằng nhau, chẳng hạn như “c á i g ì t h ế n à y ?”
Thuật ngữ gọi bộ font có độ rộng khác nhau giữa các ký tự là “variable width font”, hay chuẩn xác hơn là “proportional font”, còn bộ font có các ký tự rộng bằng nhau là “fixed width font” hay đúng hơn là “mono-spaced font”.
Hầu hết các bộ font trên PC đều là proportional font, do vậy việc dịch game PC thường không đòi hỏi chỉnh lại độ rộng của font chữ, vì nó đã bao hàm sẵn trong bộ font rồi (trừ một vài game PC được port từ console sang). Trái lại, đa phần game console tiếng Nhật thường sử dụng mono-spaced font, tức các ký tự trong bảng chữ đều rộng bằng nhau. Khi ta thay font Nhật đó bằng font La Tinh thì sẽ “t r ô n g r ấ t x ấ u n h ư c o n g ấ u”.
Như hình trên, sau khi ta thay các ký tự Kana trong bộ font thành ký tự La Tinh thì sẽ nhận thấy một khoảng trống khá rộng theo sau những ký tự này. Lý do là ký tự Kana ban đầu rộng hơn ký tự La Tinh mà ta vẽ lại.
Do vậy, khi dịch game console thì ta luôn phải để tâm tới việc này. Độ rộng của từng ký tự có thể được thay đổi thông qua đoạn code điều chỉnh. Đối với (đa phần) game không đoạn code này thì phải viết thêm, dựa trên routine in chữ ra màn hình của game và việc này đòi hỏi phải có kiến thức về ngôn ngữ Assembly để thực hiện. Còn đối với một số game có sẵn code chỉnh độ rộng như Fire Emblem thì không cần phải có kiến thức về Assembly mà chỉ cần một chút suy luận là làm được, nhưng nếu có hiểu biết về Asm thì công việc sẽ dễ dàng và khoa học hơn.
Cách 1:
+ Đầu tiên chụp màn hình game đối với Rom nguyên gốc chưa chỉnh sửa, chụp chỗ nào có hội thoại và nhớ là chỉ chụp bằng chức năng của giả lập để có độ phân giải đúng (256x224 pixel).
+ Phóng to ảnh, “đếm” số pixel của từng ký tự. Nên đếm cho những ký tự đứng cạnh nhau trong bảng font. Chẳng hạn như chữ “ke” dưới đây rộng 12 pixel, “ku” là 10 pixel….
+ Dò tìm chuỗi giá trị vừa tìm được trong Hex editor. Chẳng hạn, ta đã biết “ki” có độ rộng 11 (0B) pixel, ku là 10 (0A) pixel, ke là 12 (0C) pixel, ko là 11 (0B) pixel bằng phương pháp đếm, và ta cũng biết ki, ku, ke, ko đứng liền nhau trong bảng font. Vậy, mở Rom bằng Hex editor và dò tìm chuỗi 0B-0A-0C-0B thì được một số kết quả (chuỗi tìm kiếm càng dài thì kết quả càng chuẩn). Thử từng kết quả để biết rằng chuỗi này bắt đầu tại $A9A50.
+ Kiểm chứng: tại $A9A50 ta thấy chuỗi 0C 0B 0B 0C 0C…. ứng với độ rộng của a, i, u, e, o…. Thử thay các giá trị này thành 0F (16 pixel, rộng hơn ban đầu) thì ta được
Rõ ràng khoảng cách giữa các ký tự Kana đã dãn rộng ra. Ngược lại, thử thay các giá trị mặc định tại $A9A50 bằng con số nhỏ hơn (chẳng hạn, 07) và ta được
Như vậy, khoảng cách giữa các chữ Kana đã bị thu hẹp. Điều này cho thấy bắt đầu từ $A9A50 là những con số điều chỉnh độ rộng của từng ký tự trong bảng font.
Hình dưới đây đã điều chỉnh độ rộng của ký tự La Tinh sau khi thay thế font và xóa bỏ chữ Hán, cho kết quả đều đặn dễ nhìn.
Cách 2: nếu như cách trên có vẻ thủ công và “ăn may” thì cách này đòi hỏi một số kiến thức nhất định về ngôn ngữ Assembly 65816 của máy Snes. Ở đây dùng Debugger của giả lập Snes9X để xác định code độ rộng.
+ Ta đã biết, bộ font bắt đầu bằng chữ Kana “a” tại $340000. Tuy nhiên, địa chỉ này chỉ đúng khi ta xem bằng Hex editor hay các phần mềm trên PC. Còn trên máy Snes, khi nó thực thi chương trình thì địa chỉ này không còn đúng. Có khái niệm gọi là “địa chỉ Snes”, và ở đây dùng phần mềm Lunar Address để xác định (nếu không thì phải dùng kiến thức Memory Mapper của Snes để xác định).
+ Khai báo các thông tin về loại Rom (FE5 là LoROM) cho Lunar Address, nhập địa chỉ $340000 (PC) và ta được địa chỉ Snes tương ứng là $ E88000.
+ Chạy Debugger của Snes9X, click vào tab “Breakpoint”, nhập địa chỉ E88000 vào trong ô và tích vào ô “read”. Điều này có nghĩa rằng Debugger sẽ thực thi lần lượt các lệnh của chương trình (game), cho tới khi nó gặp phải lệnh “đọc” địa chỉ mà ta vừa ra điều kiện. Lúc này Debugger sẽ đứng lại và hiển thị các thông tin liên quan.
Click vào tab “Skip Op” để kiểm tra lần lượt từng lệnh trong routine đọc địa chỉ E88000, từ đó lần theo các dấu vết (phải hiểu được ý nghĩa của từng lệnh, ở đây tôi không đi sâu vào phần này vì sẽ mất nhiều thời gian) và cuối cùng ta được dẫn tới routine $95/9A20 20 2B 9A JSR $9A2B [$83:9A2B] (bắt đầu tại $A9A20) và routine này kết thúc tại $A9A4F ($95/9A4F 60 RTS). Ngay sau đó (từ $A9A50) là phần code chỉnh độ rộng cho từng ký tự.
Master_cheat001
Mr & Ms Pac-Man
- 23/6/07
- 224
- 9
Vãi dịch thành Fire Embem kiếm hiệp truyền kỳ rồi 
asm65816
Mega Man
- 23/5/09
- 3,320
- 4,851
- Thread starter
- #32
V. Dump text và Insert
1. Dump
Thuật ngữ "dump" chỉ việc trích xuất text từ Rom/file game ra văn bản để dịch. Việc trích xuất text không chỉ phục vụ mục đích để đọc, mà nó còn có các ý nghĩa thiết thực sau:
1. Dễ đọc, dễ kiểm soát: thường thì để đọc hết hội thoại trong game thì người chơi phải chơi hết game, chơi đến mọi ngóc ngách trong game. Có những hội thoại chỉ xuất hiện khi đã hội đủ một số điều kiện nhất định. Do vậy, để đọc hết hội thoại trong game bằng cách chơi thì tốn rất nhiều thời gian, công sức. Nhưng nếu dump hội thoại ra file văn bản thì ta có thể đọc toàn bộ nội dung thoại một cách dễ dàng, bao gồm cả những đoạn thoại ẩn. Tuy nhiên có thể các đoạn thoại không được sắp xếp theo trật tự diễn tiến thời gian/event như trong game.
2. Tránh bỏ sót khi chèn: với những game có số lượng thoại lớn như Fire Emblem hay Final Fantasy, nếu không trích xuất text ra thì gần như không thể biết được chính xác phải chèn lại vào Rom/file game bao nhiêu câu, dẫn đến chèn thiếu, dịch thiếu. Đây là ý nghĩa quan trọng của việc dump text.
3. Tránh nhầm, thiếu code: một số game sử dụng control code nhúng kèm trong hội thoại như Fire Emblem, Tearring Saga với mật độ rất cao. Control code là phần code điều khiển mọi thứ trong đoạn thoại như làm chữ chua nhanh, chạy chậm, phóng to chữ, đổi màu chữ, chuyển từ nhân vật này sang nhân vật khác, hiển thị avatar nhân vật... Trong quá trình chơi trong game, ta chỉ gián tiếp nhận thấy những tác động của control code (nếu tinh ý) chứ không thể trực tiếp thấy bản thân những code đó. Do vậy, nếu chỉ nhìn text trên màn hình mà dịch rồi chèn lại Rom/file game thì sẽ thiếu control code và đôi khi là dẫn đến đơ game. Final Fantasy IX là một game sử dụng rất nhiều control code trong câu thoại và tất cả chúng đều là code quan trọng, chỉ cần sai lệch hay thiếu một đoạn nhỏ cũng làm hỏng game. Đây là ý nghĩa tối quan trọng của việc dump text
Một đoạn thoại trong FE5 sau khi dump và phần dịch bên dưới bằng Atlas. Nếu không dump thì sẽ không biết được sự tồn tại của control code nằm trong thoại.
Như vậy, ta đã thấy rõ tầm quan trọng của việc dump text trong quá trình dịch game. Nếu chỉ dịch những game nhỏ với số lượng câu thoại không nhiều, vài đến mười mấy câu đơn giản thì có thể không cần phải dump, nhưng nếu là một game đồ sộ thì nhất định phải cần đến.
Hiện nay có nhiều phần mềm được viết riêng để phục vụ cho mục đích này. Có thể kể đến những cái tên như Script Extractor, Romjuice, Cartographer... Nguyên tắc của chúng đều giống nhau: tham chiếu các giá trị hex ta cung cấp trong table để chuyển đổi thành văn bản trong file xuất ra. Chẳng hạn ta có những entry sau trong tabel
00=0
01=1
02=2
03=3
04=4
05=5
06=6
07=7
08=8
09=9
0A=A
0B=S
0C=M
và trong Rom/file game có đoạn
0A-0B-0C-06-05-08-01-06
thì khi gặp đoạn này, phần mềm sẽ in ra file văn bản với nội dung: ASM65816.
Cách sử dụng những phần mềm này khá đơn giản: cung cấp tên Rom, file game (để cùng thư mục với phần mềm), khai báo địa chỉ bắt đầu và kết thúc của text, khai báo tên file văn bản cần xuất ra.
Tuy nhiên phần mềm Cartographer còn có thêm nhiều chức năng phức tạp/tiện lợi hơn, chẳng hạn như dump theo pointer. Nghĩa là thay vì khai báo địa chỉ bắt đầu và kết thúc của text thì ta khai báo địa chỉ bắt đầu và kết thúc của pointer chỉ đến đoạn text đó. Chức năng này rất lợi hại vì khi chèn text đã dịch vào Rom/file game thì mối quan tâm hàng đầu là pointer chứ không phải địa chỉ chèn vào đâu.
Ví dụ về dump theo pointer bằng Cartographer. Đọc thêm file readme để biết chi tiết
2. Insert
Insert, tức chèn văn bản đã dịch vào Rom/file game. Đây là quá trình ngược lại với dump và là bước cuối cùng trong chuỗi thao tác cần thiết để hoàn thành quá trình dịch thuật. Đây cũng là mục đích lớn nhất của quá trình dịch game.
Có nhiều phần mềm phục vụ cho việc này, như Script Insertor, Gizmo, Atlas... Trong đó Atlas của tác giả Klarth nổi bật hơn cả và đã thay thế tất cả những phần mềm kia vì những tính năng tiện lợi của nó. Đặc biệt, Atlas và Cartographer có tính tương thích với nhau rất cao, nên giới dịch game chuyên nghiệp trên Thế giới thường sử dụng bộ đôi này. Nguyên tắc hoạt động của những phần mềm này cũng giống như phần mềm dump văn bản, chỉ ngược chức năng. Chẳng hạn, lấy lại ví dụ trên.
Nếu ta có đoạn văn bản "ASM65816" thì khi chèn vào Rom với file table được cung cấp thì phần mềm sẽ đưa các giá trị hex sau vào:
0A-0B-0C-06-05-08-01-06
Dưới đây là những lợi ích của việc sử dụng Insertor:
1. Nhanh, chuẩn xác vì chỉ cần dịch/gõ như gõ văn bản bình thường, không phải gõ trên Hex editor vừa chậm, vừa dễ sai sót và không hỗ trợ tiếng Việt.
2. Một số công cụ dịch game chuyên dụng tập trung vào một game nào đó có hỗ trợ dịch và chèn văn bản, nhưng tuyệt đại đa số chúng là những công cụ do người Tây phương viết ra nên không hỗ trợ dấu tiếng Việt, khi chèn dẫn đến hỏng Rom/game. Chẳng hạn như Resident Evil 5, Silent Hill trên PC đều có công cụ hỗ trợ dịch, nghĩa là phần mềm sẽ liệt kê hết những câu thoại trong game và bên cạnh là ô để dịch như kiểu ô Excel, nhưng tất cả đều không hỗ trợ dấu tiếng Việt. Nhưng với Atlas, ta có thể gõ bất cứ thứ tiếng gì, miễn là file table và file văn bản dịch phải cùng encoding.
Như vậy, về nguyên tắc thì chỉ cần sử dụng bộ đôi vạn năng Cartographer + Atlas là có thể dịch hết mọi game có trên thị trường, cho mọi hệ máy từ trước đến nay. Dĩ nhiên là để làm được việc này, đôi khi cần phải có thêm kiến thức về Assembly cho hệ máy đó, nếu như game sử dụng những giải thuật "không bình thường". Đối với những game này thì sau quá trình giải mã thì có thể tiến hành dump, insert bằng bộ đôi vạn năng kể trên như bình thường.
1. Dump
Thuật ngữ "dump" chỉ việc trích xuất text từ Rom/file game ra văn bản để dịch. Việc trích xuất text không chỉ phục vụ mục đích để đọc, mà nó còn có các ý nghĩa thiết thực sau:
1. Dễ đọc, dễ kiểm soát: thường thì để đọc hết hội thoại trong game thì người chơi phải chơi hết game, chơi đến mọi ngóc ngách trong game. Có những hội thoại chỉ xuất hiện khi đã hội đủ một số điều kiện nhất định. Do vậy, để đọc hết hội thoại trong game bằng cách chơi thì tốn rất nhiều thời gian, công sức. Nhưng nếu dump hội thoại ra file văn bản thì ta có thể đọc toàn bộ nội dung thoại một cách dễ dàng, bao gồm cả những đoạn thoại ẩn. Tuy nhiên có thể các đoạn thoại không được sắp xếp theo trật tự diễn tiến thời gian/event như trong game.
2. Tránh bỏ sót khi chèn: với những game có số lượng thoại lớn như Fire Emblem hay Final Fantasy, nếu không trích xuất text ra thì gần như không thể biết được chính xác phải chèn lại vào Rom/file game bao nhiêu câu, dẫn đến chèn thiếu, dịch thiếu. Đây là ý nghĩa quan trọng của việc dump text.
3. Tránh nhầm, thiếu code: một số game sử dụng control code nhúng kèm trong hội thoại như Fire Emblem, Tearring Saga với mật độ rất cao. Control code là phần code điều khiển mọi thứ trong đoạn thoại như làm chữ chua nhanh, chạy chậm, phóng to chữ, đổi màu chữ, chuyển từ nhân vật này sang nhân vật khác, hiển thị avatar nhân vật... Trong quá trình chơi trong game, ta chỉ gián tiếp nhận thấy những tác động của control code (nếu tinh ý) chứ không thể trực tiếp thấy bản thân những code đó. Do vậy, nếu chỉ nhìn text trên màn hình mà dịch rồi chèn lại Rom/file game thì sẽ thiếu control code và đôi khi là dẫn đến đơ game. Final Fantasy IX là một game sử dụng rất nhiều control code trong câu thoại và tất cả chúng đều là code quan trọng, chỉ cần sai lệch hay thiếu một đoạn nhỏ cũng làm hỏng game. Đây là ý nghĩa tối quan trọng của việc dump text
Một đoạn thoại trong FE5 sau khi dump và phần dịch bên dưới bằng Atlas. Nếu không dump thì sẽ không biết được sự tồn tại của control code nằm trong thoại.
Như vậy, ta đã thấy rõ tầm quan trọng của việc dump text trong quá trình dịch game. Nếu chỉ dịch những game nhỏ với số lượng câu thoại không nhiều, vài đến mười mấy câu đơn giản thì có thể không cần phải dump, nhưng nếu là một game đồ sộ thì nhất định phải cần đến.
Hiện nay có nhiều phần mềm được viết riêng để phục vụ cho mục đích này. Có thể kể đến những cái tên như Script Extractor, Romjuice, Cartographer... Nguyên tắc của chúng đều giống nhau: tham chiếu các giá trị hex ta cung cấp trong table để chuyển đổi thành văn bản trong file xuất ra. Chẳng hạn ta có những entry sau trong tabel
00=0
01=1
02=2
03=3
04=4
05=5
06=6
07=7
08=8
09=9
0A=A
0B=S
0C=M
và trong Rom/file game có đoạn
0A-0B-0C-06-05-08-01-06
thì khi gặp đoạn này, phần mềm sẽ in ra file văn bản với nội dung: ASM65816.
Cách sử dụng những phần mềm này khá đơn giản: cung cấp tên Rom, file game (để cùng thư mục với phần mềm), khai báo địa chỉ bắt đầu và kết thúc của text, khai báo tên file văn bản cần xuất ra.
Tuy nhiên phần mềm Cartographer còn có thêm nhiều chức năng phức tạp/tiện lợi hơn, chẳng hạn như dump theo pointer. Nghĩa là thay vì khai báo địa chỉ bắt đầu và kết thúc của text thì ta khai báo địa chỉ bắt đầu và kết thúc của pointer chỉ đến đoạn text đó. Chức năng này rất lợi hại vì khi chèn text đã dịch vào Rom/file game thì mối quan tâm hàng đầu là pointer chứ không phải địa chỉ chèn vào đâu.
Ví dụ về dump theo pointer bằng Cartographer. Đọc thêm file readme để biết chi tiết
2. Insert
Insert, tức chèn văn bản đã dịch vào Rom/file game. Đây là quá trình ngược lại với dump và là bước cuối cùng trong chuỗi thao tác cần thiết để hoàn thành quá trình dịch thuật. Đây cũng là mục đích lớn nhất của quá trình dịch game.
Có nhiều phần mềm phục vụ cho việc này, như Script Insertor, Gizmo, Atlas... Trong đó Atlas của tác giả Klarth nổi bật hơn cả và đã thay thế tất cả những phần mềm kia vì những tính năng tiện lợi của nó. Đặc biệt, Atlas và Cartographer có tính tương thích với nhau rất cao, nên giới dịch game chuyên nghiệp trên Thế giới thường sử dụng bộ đôi này. Nguyên tắc hoạt động của những phần mềm này cũng giống như phần mềm dump văn bản, chỉ ngược chức năng. Chẳng hạn, lấy lại ví dụ trên.
Nếu ta có đoạn văn bản "ASM65816" thì khi chèn vào Rom với file table được cung cấp thì phần mềm sẽ đưa các giá trị hex sau vào:
0A-0B-0C-06-05-08-01-06
Dưới đây là những lợi ích của việc sử dụng Insertor:
1. Nhanh, chuẩn xác vì chỉ cần dịch/gõ như gõ văn bản bình thường, không phải gõ trên Hex editor vừa chậm, vừa dễ sai sót và không hỗ trợ tiếng Việt.
2. Một số công cụ dịch game chuyên dụng tập trung vào một game nào đó có hỗ trợ dịch và chèn văn bản, nhưng tuyệt đại đa số chúng là những công cụ do người Tây phương viết ra nên không hỗ trợ dấu tiếng Việt, khi chèn dẫn đến hỏng Rom/game. Chẳng hạn như Resident Evil 5, Silent Hill trên PC đều có công cụ hỗ trợ dịch, nghĩa là phần mềm sẽ liệt kê hết những câu thoại trong game và bên cạnh là ô để dịch như kiểu ô Excel, nhưng tất cả đều không hỗ trợ dấu tiếng Việt. Nhưng với Atlas, ta có thể gõ bất cứ thứ tiếng gì, miễn là file table và file văn bản dịch phải cùng encoding.
Như vậy, về nguyên tắc thì chỉ cần sử dụng bộ đôi vạn năng Cartographer + Atlas là có thể dịch hết mọi game có trên thị trường, cho mọi hệ máy từ trước đến nay. Dĩ nhiên là để làm được việc này, đôi khi cần phải có thêm kiến thức về Assembly cho hệ máy đó, nếu như game sử dụng những giải thuật "không bình thường". Đối với những game này thì sau quá trình giải mã thì có thể tiến hành dump, insert bằng bộ đôi vạn năng kể trên như bình thường.
- 27/4/08
- 318
- 59
Khi nào ra lò bản này vậy bác asm? Thèm quá!
asm65816
Mega Man
- 23/5/09
- 3,320
- 4,851
- Thread starter
- #34
VI. Pointer
Trong phần trước có đề cập đến việc dump text và insert. Nhưng để dump (trích xuất) và insert (chèn) thì phải nắm được một yếu tố vô cùng quan trọng khác, đó chính là pointer. Phần này sẽ đề cập đến những cách xác định pointer.
Đa phần game console đều sử dụng pointer table, tức một dãy pointer đứng liền kề nhau. Tuy nhiên, FE4 và FE5 lại không sử dụng pointer table mà chèn pointer chỉ đến câu thoại vào giữa event code. Chẳng hạn:
<code hiển thị map1>
<code bật nhạc đầu map1>
<code hiển thị 2 nhân vật địch xuất hiện>
<pointer 2 nhân vật địch nói chuyện với nhau>
.....
Cho nên việc xác định pointer sẽ khó khăn hơn thông thường.
1. Xác định bằng địa chỉ SNES CPU
Đầu tiên, load Rom bằng Windhex với file table đã xây dựng, ta dễ dàng xác định được đoạn thoại đầu map 1 nằm ở vị trí 0xAA493 (với Rom không header).
Vì FE 5 là Lorom 80:8000 nên dễ dàng tính được offset 0xAA493 tương đương với địa chỉ $95A493 trong SNES CPU. Có thể dùng cách khác là phần mềm Lunar Address nếu không nắm được các đặc điểm của địa chỉ SNES.
Nếu không rõ Rom đối tượng thuộc loại gì, có header hay không thì chỉ cần click vào tab "Auto detect type" là Lunar Address tự xác định được đó là loại Rom gì.
Tiếp theo, chỉ cần nhập địa chỉ Rom khi mở trên PC vào ô "PC File Address" thì bên ô đối diện ("SNES LoROM") sẽ cho địa chỉ tương ứng trong SNES CPU.
Đoạn thoại ta cần xác định nằm ở 0xAA493 trong PC, tương ứng với $95A493 trong SNES CPU. Đây cũng chính là giá trị pointer của đoạn thoại này.
Vì SNES sử dụng kiểu xếp dữ liệu Little Endian (thứ tự ngược) nên 95A493 phải được đọc thành 93-A4-95. Dò tìm 3 giá trị này trong Rom và ta sẽ được địa chỉ của pointer chỉ đến đoạn thoại này.
Nếu đã biết loại Rom thì không cần dùng đến Lunar Address, mà chỉ cần đổi kiểu xem trong Windhex thì vẫn có thể biết được địa chỉ trong SNES CPU tương ứng bằng cách vào Option --> Display offest as---> SNES Lo-Rom (Fast Rom).
Cách này có ưu điểm là dễ dàng xác định được pointer, không cần hiểu sâu về Asm, nhưng có khuyết điểm là không chuẩn xác hoàn toàn. Bởi vì trong Rom có thể có nhiều địa chỉ cùng giá trị với nhau, nên ta phải kiểm tra từng địa chỉ trong trường hợp này.
2. Xác định bằng Debugger
Dùng Debugger luôn là cách làm khoa học, chuẩn xác và giúp ta hiểu sâu rộng hơn về game, nhưng có khuyết điểm là đòi hỏi phải có một lượng kiến thức nhất định về Asm. Có thể dùng Geiger's Snes9X Debugger để xác định.
Load Rom bằng Debugger, tích vào ô "Trace once" nếu muốn chỉ theo dõi 1 lệnh 1 lần (tránh ngốn Ram) và tích vào ô Logging CPU khi game chạy đến đoạn bắt đầu hội thoại.
Khi bỏ dấu tích ở ô Logging CPU thì quá trình log kết thúc, file log được lưu vào thư mục Logs. Mở file Log, dễ dàng xác định được đoạn thoại đầu map 1 gồm những đoạn code sau:
Chú ý đoạn bôi đậm,
LDA [$3B],y[$FD:83D1] ; load giá trị tại địa chỉ $3B + giá trị tại địa chỉ $FD83D1 (giá trị của Register Y) vào Register A.
STA $1746 [$8C:1746] ; chứa giá trị của Register A vào địa chỉ $1746 trong Ram.
Đoạn này cho biết, giá trị của pointer được đọc từ (biến số) $3B và $FD83D1, sau đó ghi vào $1746 trong Ram. Vì Ram của SNES bắt đầu từ $7E0000 nên $1746 tương đương với $7E1746. Đây là nơi chứa pointer của tất cả các câu thoại trong game, tuy nhiên chỉ có một pointer duy nhất được thể hiện ở một thời điểm hội thoại nhất định.
Bật chức năng Hex editor trong Debugger, chọn mục Viewing là RAM và kéo xuống địa chỉ $7E1746, ta sẽ thấy giá trị 93-A9-95 là giá trị của pointer cần tìm. Khi chuyển sang đoạn thoại khác, giá trị này sẽ thay đổi tương ứng. Có thể đóng băng, hay tạo cheat code tại địa chỉ này để xác minh. Khi đó, dù ở bất cứ đoạn nào trong game, thoại vẫn cứ thể hiện là đoạn thoại đầu map 1.
Như vậy ta đã tìm được pointer bằng Debugger.
Trong phần trước có đề cập đến việc dump text và insert. Nhưng để dump (trích xuất) và insert (chèn) thì phải nắm được một yếu tố vô cùng quan trọng khác, đó chính là pointer. Phần này sẽ đề cập đến những cách xác định pointer.
Đa phần game console đều sử dụng pointer table, tức một dãy pointer đứng liền kề nhau. Tuy nhiên, FE4 và FE5 lại không sử dụng pointer table mà chèn pointer chỉ đến câu thoại vào giữa event code. Chẳng hạn:
<code hiển thị map1>
<code bật nhạc đầu map1>
<code hiển thị 2 nhân vật địch xuất hiện>
<pointer 2 nhân vật địch nói chuyện với nhau>
.....
Cho nên việc xác định pointer sẽ khó khăn hơn thông thường.
1. Xác định bằng địa chỉ SNES CPU
Đầu tiên, load Rom bằng Windhex với file table đã xây dựng, ta dễ dàng xác định được đoạn thoại đầu map 1 nằm ở vị trí 0xAA493 (với Rom không header).
Vì FE 5 là Lorom 80:8000 nên dễ dàng tính được offset 0xAA493 tương đương với địa chỉ $95A493 trong SNES CPU. Có thể dùng cách khác là phần mềm Lunar Address nếu không nắm được các đặc điểm của địa chỉ SNES.
Nếu không rõ Rom đối tượng thuộc loại gì, có header hay không thì chỉ cần click vào tab "Auto detect type" là Lunar Address tự xác định được đó là loại Rom gì.
Tiếp theo, chỉ cần nhập địa chỉ Rom khi mở trên PC vào ô "PC File Address" thì bên ô đối diện ("SNES LoROM") sẽ cho địa chỉ tương ứng trong SNES CPU.
Đoạn thoại ta cần xác định nằm ở 0xAA493 trong PC, tương ứng với $95A493 trong SNES CPU. Đây cũng chính là giá trị pointer của đoạn thoại này.
Vì SNES sử dụng kiểu xếp dữ liệu Little Endian (thứ tự ngược) nên 95A493 phải được đọc thành 93-A4-95. Dò tìm 3 giá trị này trong Rom và ta sẽ được địa chỉ của pointer chỉ đến đoạn thoại này.
Nếu đã biết loại Rom thì không cần dùng đến Lunar Address, mà chỉ cần đổi kiểu xem trong Windhex thì vẫn có thể biết được địa chỉ trong SNES CPU tương ứng bằng cách vào Option --> Display offest as---> SNES Lo-Rom (Fast Rom).
Cách này có ưu điểm là dễ dàng xác định được pointer, không cần hiểu sâu về Asm, nhưng có khuyết điểm là không chuẩn xác hoàn toàn. Bởi vì trong Rom có thể có nhiều địa chỉ cùng giá trị với nhau, nên ta phải kiểm tra từng địa chỉ trong trường hợp này.
2. Xác định bằng Debugger
Dùng Debugger luôn là cách làm khoa học, chuẩn xác và giúp ta hiểu sâu rộng hơn về game, nhưng có khuyết điểm là đòi hỏi phải có một lượng kiến thức nhất định về Asm. Có thể dùng Geiger's Snes9X Debugger để xác định.
Load Rom bằng Debugger, tích vào ô "Trace once" nếu muốn chỉ theo dõi 1 lệnh 1 lần (tránh ngốn Ram) và tích vào ô Logging CPU khi game chạy đến đoạn bắt đầu hội thoại.
Khi bỏ dấu tích ở ô Logging CPU thì quá trình log kết thúc, file log được lưu vào thư mục Logs. Mở file Log, dễ dàng xác định được đoạn thoại đầu map 1 gồm những đoạn code sau:
Mã:
$8C/88FE 08 PHP A:88FE X:FFFE Y:0039 P:envmxdizc
$8C/88FF 5A PHY A:88FE X:FFFE Y:0039 P:envmxdizc
$8C/8900 AD 2C 17 LDA $172C [$8C:172C] A:88FE X:FFFE Y:0039 P:envmxdizc
$8C/8903 89 00 40 BIT #$4000 A:0001 X:FFFE Y:0039 P:envmxdizc
$8C/8906 D0 1B BNE $1B [$8923] A:0001 X:FFFE Y:0039 P:envmxdiZc
$8C/8908 B7 3B [B]LDA [$3B],y[$FD:83D1][/B] A:0001 X:FFFE Y:0039 P:envmxdiZc
$8C/890A 8D 46 17 [B]STA $1746 [$8C:1746][/B] A:A493 X:FFFE Y:0039 P:eNvmxdizc
$8C/890D C8 [B]INY[/B] A:A493 X:FFFE Y:0039 P:eNvmxdizc
$8C/890E B7 3B [B]LDA [$3B],y[$FD:83D2][/B] A:A493 X:FFFE Y:003A P:envmxdizc
$8C/8910 8D 47 17 [B]STA $1747 [$8C:1747][/B] A:95A4 X:FFFE Y:003A P:eNvmxdizc
$8C/8913 DA PHX A:95A4 X:FFFE Y:003A P:eNvmxdizc
$8C/8914 A9 00 82 LDA #$8200 A:95A4 X:FFFE Y:003A P:eNvmxdizc
$8C/8917 85 6E STA $6E [$00:006E] A:8200 X:FFFE Y:003A P:eNvmxdizc
$8C/8919 A9 72 86 LDA #$8672 A:8200 X:FFFE Y:003A P:eNvmxdizc
$8C/891C 85 6D STA $6D [$00:006D] A:8672 X:FFFE Y:003A P:eNvmxdizc
$8C/891E 22 E7 83 8C JSL $8C83E7[$8C:83E7] A:8672 X:FFFE Y:003A P:eNvmxdizcChú ý đoạn bôi đậm,
LDA [$3B],y[$FD:83D1] ; load giá trị tại địa chỉ $3B + giá trị tại địa chỉ $FD83D1 (giá trị của Register Y) vào Register A.
STA $1746 [$8C:1746] ; chứa giá trị của Register A vào địa chỉ $1746 trong Ram.
Đoạn này cho biết, giá trị của pointer được đọc từ (biến số) $3B và $FD83D1, sau đó ghi vào $1746 trong Ram. Vì Ram của SNES bắt đầu từ $7E0000 nên $1746 tương đương với $7E1746. Đây là nơi chứa pointer của tất cả các câu thoại trong game, tuy nhiên chỉ có một pointer duy nhất được thể hiện ở một thời điểm hội thoại nhất định.
Bật chức năng Hex editor trong Debugger, chọn mục Viewing là RAM và kéo xuống địa chỉ $7E1746, ta sẽ thấy giá trị 93-A9-95 là giá trị của pointer cần tìm. Khi chuyển sang đoạn thoại khác, giá trị này sẽ thay đổi tương ứng. Có thể đóng băng, hay tạo cheat code tại địa chỉ này để xác minh. Khi đó, dù ở bất cứ đoạn nào trong game, thoại vẫn cứ thể hiện là đoạn thoại đầu map 1.
Như vậy ta đã tìm được pointer bằng Debugger.
Dark.Prince001
Mr & Ms Pac-Man
- 14/1/13
- 159
- 0
Ko liên quan nhưng bác Asm còn cái tool fe5 editor ko ? Cho mình xin . Link trên diễn đàn die sạch rồi 
Narga
Youtube Master Race
- 24/1/03
- 68
- 1
Bác còn kinh nghiệm vui lòng chia sẻ để mọi người biết, em đang thử với Breath of Fire II, cái này bản dịch E rất tệ, bản re-trans thì khá hơn, trong quá trình thử em có thấy nó có những khối text để point tới nhưng có vẻ nó bị mã hoá hoặc do em chưa có kinh nghiệm nhiều nên tìm và suy đoán rất vất vả.
... xui xẻo quá vậy 
T0977999482
Mega Man
- 8/7/09
- 3,431
- 8,010
Bác thông cảm nhiều bạn có chịu đọc và hiểu đâu! Thanh niên thời đại này chiếm đến 70% là muốn ăn sẵn
