Zelda Densetsu SFC

1. Khái quát 

Zelda no Densetsu - kamigami no toraifōsu (ゼルダの伝説 神々のトライフォース ), được tạm chuyển ngữ sang Việt văn là "truyền thuyết Zelda-tam bảo của chư thần", là phiên bản thứ 3 trong series Zelda no Densetsu do Nintendō phát hành. Phiên bản này dành cho máy Super Nintendō, xuất hiện vào cuối năm 1991 ở Nhật, đúng 1 năm sau khi hệ máy này ra đời. Bản dịch tiếng Anh chính thức được phát hành cho các hệ máy SNES Mỹ, SNES Âu châu ở các thị trường này xuất hiện sau đó vài tháng. 

Tựa đề của bản tiếng Anh chính thức khác biệt so với bản gốc tiếng Nhật, cụ thể là "The Legend of Zelda: A Link to the Past". Ngoài tựa đề ra thì các phiên bản tiếng Anh cũng còn nhiều chỗ khác biệt nho nhỏ khác so với bản tiếng Nhật như lời thoại, hình ảnh xuất hiện trong game. Đây là kết quả của quá trình kiểm duyệt để tránh những vấn đề nhạy cảm như tôn giáo ở xã hội Âu Mỹ.

Về lối chơi, phiên bản này quay về với gốc rễ, bám sát với phiên bản Zelda đầu tiên năm 1986 trên máy Famicom (NES) sau khi phiên bản thứ hai năm 1987 cũng trên máy Famicom. Ở phiên bản SFC này xuất hiện nhiều Item mà sau đó đã trở thành những món đồ cố định trong series, như thanh kiếm "Master-sword", lọ thủy tinh,... Phiên bản này cũng là một hình mẫu ảnh hưởng đến nhiều dòng game sau này, chẳng hạn như Dark Souls. Bạn có thể thấy nhiều yếu tố mà Dark Souls học tập ở phiên bản Zelda này, như cách bố trí Item trong màn, chiếc cầu vô hình,...

2. Bản dịch Việt văn

Về mặt dịch thuật, bản dịch này dựa trên nền bản gốc tiếng Nhật, cố gắng bám sát tinh thần của bản gốc hết mức có thể. Sẽ có nhiều chỗ dị biệt nếu đối chiếu với bản Anh ngữ, bởi vì bản Anh ngữ vốn đã có những điểm dị biệt đó so với bản tiếng Nhật. Chẳng hạn như tựa đề của bản gốc mang nghĩa là "Triforce của các vị thần", trong đó "Triforce" là 3 món bảo vật hoàng kim của 3 vị thần sáng tạo nên thế giới trong series Zelda, tượng trưng cho trí tuệ, sức mạnh và dũng khí. Bản dịch Việt ngữ này dựa trên tinh thần của bản tiếng Nhật, có tựa đề là "Tam bảo của chư thần", hoàn toàn khác biệt với "A Link to the Past".

Về mặt kỹ thuật, bản dịch này cũng dựa trên Rom tiếng Nhật được dump trực tiếp từ băng cassette Super Famicom, ứng dụng kỹ thuật lập trình Assembly 65816 ở mức cao độ để phục vụ cho việc dịch thuật ở mức tối đa. Chẳng hạn như khung thoại được mở rộng, thay đổi màu khung thoại, dùng nhiều kiểu font chữ,... Bản dịch này còn có một số tính năng mà vốn đã bị ẩn đi ở phiên bản gốc, một số tính năng vốn không có trong phiên bản gốc. Đây cũng là kết quả của việc ứng dụng kỹ thuật Assembly 65816 trong quá trình dịch thuật.

Lưu ý: đây là bản dịch tiếng Việt, hay nói cách khác là bản chuyển ngữ Việt văn, bản Việt ngữ hóa. Đây hoàn toàn không phải là bản Việt hóa. Dịch sang tiếng Việt (Việt ngữ hóa) và "Việt hóa" là hai khái niệm hoàn toàn khác nhau, không nên nhầm lẫn.

4. Quá trình dịch thuật

Phần này ghi lại những điểm kỹ thuật trong quá trình dịch thuật. Ai quan tâm có thể tham khảo.

A) Các bước để hoàn tất một bản dịch

• Dump Rom

• Debug để xác định font chữ, câu thoại và mọi thứ khác liên quan

• Viết thêm code mới phục vụ cho việc hiển thị chữ, chèn code này vào Rom bằng xkas

• Dump text gốc

• Dịch text đã dump

• Chèn text đã dịch vào Rom bằng Atlas

Trừ bước đầu và bước cuối có thứ tự không đổi thì các bước còn lại có thể xáo trộn trật tự, có thể bỏ qua tùy tình huống.

B) Những thứ cần có

• Băng game: dùng để dump (trích xuất) Rom. Về mặt pháp lý, việc dump Rom từ băng vật lý để chơi bằng trình giả lập (Emulator) là việc hoàn toàn hợp pháp. Do vậy, đây là thứ bắt buộc phải có.

• Rom dumper: có thể dùng máy dump Rom hoặc băng cassette có chức năng dump, chẳng hạn như Super UFO Pro 8. Băng cassette này có nhược điểm là chỉ đọc được LoRom và HiRom, không đọc được băng ExLoRom và ExHiRom. Nói cách khác, Super UFO Pro 8 chỉ đọc được băng game có dung lượng từ 32Mb (4MB) trở xuống. Băng Zelda này có dung lượng 8Mb (1MB) nên hoàn toàn tương thích với Super UFO Pro 8. Đây là thứ bắt buộc phải có, nếu không có thì ta buộc phải tự tạo một công cụ khác có chức năng tương đương.

• Giả lập Super Famicom/SNES có chức năng debug. Ở đây tôi quen dùng Mesen-S (bản cũ của Mesen). Đây là thứ bắt buộc phải có, nếu không có thì ta buộc phải tự viết một công cụ khác có chức năng tương đương.

• Một Hex-editor: dùng bất kỳ loại gì cũng được. Ở đây tôi quen dùng Stirling. Hex-editor không đóng vai trò quan trọng lắm, chỉ là để thuận tiện cho một số thao tác lặt vặt sẽ xuất hiện.

• Phần mềm disassembler: dùng để "giải mã" dữ liệu số trong game thành những câu lệnh assembly. Tuy nhiên, do đặc thù của SNES CPU là dùng song song 2 chế độ là 8bit và 16bit nên người sử dụng phải hiểu rõ thời điểm chuyển đổi 2 chế độ này để có kết quả tốt nhất. Ngoài ra, phần mềm cũng không phân biệt đâu là code, đâu là dữ liệu. Người dùng phải tự hiểu rõ phần này để có kết quả tốt nhất. Có khá nhiều phần mềm disassembler cho hệ máy này, nhưng tôi quen dùng Dispel. Phần mềm này không bắt buộc phải có, nhưng nếu dùng nó thì bạn sẽ hình dung được chức năng của một đoạn code dễ dàng hơn. Có thể dùng luôn chức năng debug của giả lập để thay thế phần mềm này.

• Xkas: phần mềm assembler của tác giả byuu (David Kirk Ginder, 1983~2021) giúp chuyển đổi mã assembly thành mã máy. Có khá nhiều phiên bản, ở đây tôi quen dùng xkas plus. Đây là thứ bắt buộc phải có, nếu không có thì ta buộc phải tự viết một công cụ khác có chức năng tương đương.

• Cartographer: phần mềm command-line của tác giả RedComet, cho phép dump dữ liệu từ Rom ra dạng text. Khá thuận tiện cho việc dịch thuật nhưng không bắt buộc phải có, nếu như bạn hiểu rõ về cấu trúc cũng như từng câu thoại trong game.

• Atlas: phần mềm command-line của tác giả Klarth, cho phép chèn text đã dịch và Rom. Đây là thứ bắt buộc phải có, nếu không có thì ta buộc phải tự viết một công cụ khác có chức năng tương đương.

• Phần mềm chỉnh sửa hình ảnh (các dạng ảnh PNG, BMP): có khá nhiều loại có chức năng này. Nhưng cần lưu ý là chọn loại có khả năng lưu ảnh mà không phá vỡ cấu trúc pixel của nó. Tôi quên dùng Pixelformer của hãng Qualibyte Software. Những phần mềm làm thay đổi cấu trúc pixel như Microsoft Paint hay Photoshop mà không có plugin thì đều không dùng được. Phần mềm này không bắt buộc nếu như bạn hiểu rõ cách vẽ pixel.

• Phần mềm chỉnh sửa dữ liệu hình ảnh của Super Famicom/SNES. Loại này hoàn toàn khác với cái vừa nêu bên trên. Phần mềm ở trên là loại dùng để xem/chỉnh sửa các định dạng ảnh trên máy tính, còn phần mềm ở đây là để xem/chỉnh sửa định dạng ảnh của máy Super Famicom/SNES. Có khá nhiều loại, ở đây tôi quen dùng YY-CHR. Phần mềm này không bắt buộc phải có nếu như bạn hiểu rõ về cách vẽ pixel, có thể tạo ra được hình ảnh chỉ từ những con số.

• Phần mềm chuyển đổi dạng ảnh của máy tính (PNG, BMP) sang định dạng ảnh của Super Famicom/SNES. Có khá nhiều loại, nhưng tôi quen dùng SuperFamiconv, một phần mềm command-line có nhiều tính năng. Phần mềm này không bắt buộc phải có nếu như bạn hiểu rõ về cách vẽ pixel, có thể tạo ra được hình ảnh chỉ từ những con số.

• Text editor: một trình soạn thảo văn bản dạng plain text, là công cụ chính yếu để ta viết code và dịch thuật. Có thể dùng Notepad có sẵn trong Windows cũng được. Ở đây tôi quen dùng Notepad++. Những phần mềm như Microsoft Word hoàn toàn không thể dùng được. Đây là thứ bắt buộc phải có, nếu không có thì ta buộc phải tự viết một công cụ khác có chức năng tương đương.

•  Phần mềm Lunar Address của tác giả FuSoYa’s Niche để tiện chuyển đổi giữa địa chỉ SNES và địa chỉ trên máy tính. Nếu bạn đã hiểu rõ về địa chỉ SNES thì có thể bỏ qua phần mềm này.

• Phần mềm Lunar Expand của tác giả FuSoYa’s Niche để mở rộng dung lượng ROM. Nếu bản dịch không phình to hơn kích thước bản gốc thì có thể bỏ qua phần mềm này. Hoặc nếu bạn hiểu rõ cấu trúc của một Rom SNES thì có thể mở rộng dung lượng bằng cách dùng Hex-editor, không nhất thiết phải dùng Lunar Expand.

• Kiến thức về bộ câu lệnh của CPU 65816, chức năng của từng câu lệnh. Có thể tìm hiểu qua Google. Tài liệu về mảng này không hiếm.

• Kiến thức về phần cứng máy Super Famicom/SNES như địa chỉ SNES, khái niệm HiRom/LoRom, khái niệm DMA/HDMA, các loại Ram của SNES, chức năng của các Register, NMI/IRQ, Vblank, Force-blank,.... Có thể tìm hiểu qua Google. Tài liệu về mảng này không hiếm.

C) Quy trình

Đầu tiên là bước dump nội dung game từ băng cassette. Ở đây tôi dùng băng Super UFO Pro 8 để dump. Tháo nắp phía trên của Super UFO Pro 8 ra, ta sẽ thấy khe cắm băng. Cắm trực tiếp băng Zelda vào đó. Sau đó, cắm cả cụm này vào máy Super Famicom rồi khởi động máy. Trong menu BACKUP của Super UFO Pro 8, chọn mục GAME CART TO SDC. Chức năng của mục này là copy nội dung của băng game (Game cartridge) vào trong thẻ nhớ SD gắn trong Super UFO Pro 8.

Đặt Write break point tại địa chỉ này trong Vram, ta xác định được thời điểm mà khối hình ảnh này được chuyển vào Vram là ngay sau khi dòng chữ "Nintendo presents" ở màn hình đầu tiên kết thúc, qua routine $00E310. Tại đây, các thành phần đồ họa của Background và sprite đều được lần lượt chuyển vào Vram qua cổng $002118 mà không thông qua kỹ thuật DMA nên tốc độ chuyển không được nhanh. Ta có thể thay thế bằng routine dưới đây. Trong đó zelda_chr là dữ liệu đồ họa của màn hình tựa đề mới mà ta đã vẽ bằng Pixelformer rồi chuyển đổi bằng SuperFamiconv. 

PHP

SEP #$20

REP #$10

LDA.b #(zelda_chr>>16)

STA $4304

LDA #$80

STA $2115

LDX #$1801

STX $4300

LDX #(zelda_chr)

STX $4302

LDX #$18C0

STX $4305

LDX #$6000>>1

STX $2116

LDA #$01

STA $420B

LDX #$0000

_loop:

LDA zelda_map,x

STA $0B00,x

INX

CPX #$0700

BNE _loop

LDX #$0000

_loop2:

LDA zelda_map+1,x

CLC

ADC #$39

STA $0B01,x

INX #2

CPX #$0700

BNE _loop2

PLP

Phần _loop và _loop2 là chức năng copy tilemap của mành hình mới được chuyển đổi bằng SuperFamiconv. Tilemap được copy vào địa chỉ Ram $7E0B00 hoặc bất kỳ địa chỉ trống nào đủ 0x700 byte. Về lý thuyết, màn hình mode1 có kích thước 256x256 pixel, tương đương với tilemap 0x800 byte nhưng đặc thù của máy Super Famicom/SNES hệ NTSC là Tivi chỉ hiển thị đến scanline thứ 224 là hết, do vậy chiều cao chỉ là 224 pixel nên tilemap chỉ cần 0x700 byte là đủ. Bước copy tilemap mới vào địa chỉ Ram trống là để phục vụ cho bước DMA tilemap này vào Vram sau này.

Để xác định được vị trí của Background 1 tilemap trong Vram thì ta dùng công cụ Tilemap Viwer của debugger. Tilemap của Background 1 trong phân cảnh này bắt đầu tại $2000. Bằng cách đặt Write break point tại địa chỉ này thì ta biết được Tilemap được chuyển vào Vram ở địa chỉ $008BE2: JSR $92A1. Routine $92A1 được thực hiện trong khoảng thời gian Vblank, và là routine chung để cập nhật tilemap của Background 1 trong suốt game. Do vậy ở đây ta cần đặt điều kiện để routine mới chỉ được thực hiện trong phân cảnh tựa đề game để tránh ảnh hưởng tới những phân cảnh khác.

org $008BE2

JML freeram

freeram:

LDA $10

BNE +

PHP

SEP #$20

REP #$10

LDX #$1801

STX $4300

LDX #$0700

STX $4305

LDX #$0B00

STX $4302

LDX #$2000>>1

STX $2116

LDA #$7E

STA $4304

LDA #$80

STA $2115

LDA #$01

STA $420B

PLP

JML $008BE5

+

JSR _0092a1

JML $008BE5

Đoạn code trên DMA 0x700 byte tilemap ở địa chỉ $7E0B00 vào $2000 trong Vram chỉ khi game đang ở mode 0, tức màn hình đầu tiên. Sau đoạn code này thì ta được kết quả như dưới đây.

Xong màn hình mở đầu, tiếp theo là phần chính: text trong phần thoại chính của game. Game Super Famicom/SNES có 2 kiểu hiển thị text chính là render trong thời gian thực, và pre-render (render sẵn). Kiểu hiển thị pre-render có ưu điểm là không cần xử lý nhiều, và thường là chỉ render tilemap dựa trên tileset là bộ font chữ được chuyển vào Vram trước đó. Kiểu render này đã xuất hiện từ thời Famicom, thường được áp dụng với game không có nhiều text, hay game có bộ font chữ đơn giản. Còn nhược điểm của nó là không thể hiện được bộ font nhiều chữ, hay có chữ phức tạp, và không thể hiện được chữ có độ rộng biến thiên (proportional font). Còn kiểu render trong thời gian thực chỉ mới nở rộ từ thời Super Famicom, thường được dùng trong những game nhiều chữ như dòng Fire Emblem hay Final Fantasy. Kiểu render trong thời gian thực có ưu điểm là có thể vẽ chữ với độ phức tạp cao, do đó thể hiện được kiểu chữ có độ rộng biến thiên, ít tốn không gian Vram (vì nó không chứa sẵn bộ font trong Vram, mà chứa dữ liệu font trong Rom) nhưng lại có nhược điểm là đòi hỏi xử lý, tính toán khá nhiều.

Zelda 3 là game dùng kiểu render trong thời gian thực, bởi 3 bộ chữ được dùng trong game này là Hiragana, Katakana và Kanji nếu tính sơ sơ cũng vài trăm chữ, không thể chứa hết trong 64KB Vram được. Ngoài ra thì Vram còn chứa nhiều dữ liệu hình ảnh khác, không chỉ mỗi font chữ. Cho nên việc Zelda 3 sử dụng kiểu render trong thời gian thực là điều dễ hiểu. Tuy nhiên có một điểm đáng tiếc là font chữ trong game không phải kiểu chữ có độ rộng biến thiên. Chữ có độ rộng cố định chữ phù hợp với các ngôn ngữ có chữ vuông như Hàn, Nhật, Tàu mà thôi. Còn trong văn bản của các thứ tiếng dùng mẫu tự La Tinh thì đây là một điều cực kỳ khó chịu khi đọc. Thử tưởng tượng bạn sẽ cảm thấy như thế nào nếu chữ "i" có cùng độ rộng với chữ "w"? Do vậy ta cần phải viết thêm ít code để hiển thị kiểu chữ có độ rộng biến thiên.

Video bên dưới đây minh họa cho khái niệm render chữ trong thời gian thực.

Như trên thì thấy mỗi ký tự trong game này chiếm 2 byte, chẳng hạn như 0x0000 tương đương với あ, còn 0x0001 tương đương với い. Tuy nhiên, thông thường thì đại đa số game trong thời Super Famicom đều dùng 1 byte để biểu diễn cho 1 ký tự Kana, còn đến khi biển diễn Kanji, do số lượng của chúng vượt quá phạm vi biểu diễn của 1 byte (0~255) nên người ta mới dùng tới kiểu 2 byte để biểu diễn. Còn ở đây lại dùng 2 byte để biểu diễn 1 ký tự Kana, thật là kỳ lạ.

Nếu tiếp tục đặt write-breakpoint ở $7F1200 để xác định những giá trị này được ghi vào vùng Ram này từ đâu, như thế nào thì ta sẽ thấy giá trị ID của mỗi chữ Kana trong Rom chỉ chiếm 1 byte mà thôi. Chỉ đến khi được ghi vào vùng Workram $7F1200 thì mới trở thành 2 byte. Mục đích của việc này là để đơn giản hóa quá trình đọc text, bởi vì các control code như code xuống dòng, code đổi màu chữ, code đổi tốc độ ghi chữ, code hiệu ứng âm thanh,... đều chiếm 2 byte, nếu code ký tự chiếm 1 byte thì việc xử lý sẽ phức tạp hơn. Vì vậy Nintendō đã biến tất cả code ký tự Kana từ 1 byte trong Rom thành 2 byte trong Ram cho đồng bộ với control code.

Sau khi đã xác định được table thì ta có thể xem vị trí của text trong Rom một cách trực quang với phần mềm Windhex, hoặc cũng có thể dump text với phần mềm Cartographer.

Cũng bằng cách đặt write-breakpoint tại địa chỉ Workram $7F1200, ta có thể xác định được text được ghi từ Rom vào Workram qua pointer ở $04.

Qua routine trên thì thấy được pointer chỉ đến một đoạn text xuất phát từ $04, mà giá trị tại đây lại xuất phát từ địa chỉ Ram $7E1CF0. Mọi đoạn hội thoại trong game đều xuất phát từ đây. Nếu muốn hiển thị đoạn hội thoại đầu tiên lên màn hình thì chỉ cần ghi giá trị 0x0000 vào địa chỉ Ram này, còn ghi giá trị 0x0001 để hiển thị đoạn thoại thứ hai.

Tuy nhiên, qua đoạn code trên thì cũng thấy được là pointer chỉ đến địa chỉ của text là 16 bit, nghĩa là toàn bộ lời thoại trong game phải được gói gọn trong một bank. Zelda 3 là game có kiểu mapping Lorom, tức một bank có dung lượng 32KB, trong khoảng $8000 đến $FFFF. Dung lượng 32KB là quá ít ỏi đối với một bản dịch tiếng Việt, bởi với cùng một câu thoại thì số lượng ký tự trong tiếng Việt thường nhiều hơn tiếng Nhật, chiếm nhiều byte hơn. Do vậy, với kiểu pointer 16 bit này thì không đủ để chứa hết lời thoại của bản dịch nên ở đây cần mở rộng kích thước pointer lên 24 bit, để có thể chỉ đến text ở bất kỳ vị trí nào trong Rom. 

REP #$30

LDA $1CF0

PHA

ASL

CLC

ADC $01,s

TAX

PLA

LDA pointer_table,x

STA $04

INX

SEP #$20

LDA pointer_table,x

STA $06

Chỉ với đoạn code đơn giản trên là ta đã đổi pointer hội thoại thành 2 byte sang 3 byte. Dĩ nhiên cần phải thay đổi cả dữ liệu pointer và dữ liệu text trong Rom. Có thể dễ dàng làm việc này với phần mềm chèn text có hỗ trợ pointer như Atlas.

Tiếp theo là đến phần chính của vấn đề, làm thế nào để biến font có độ rộng cố định thành font chữ có độ rộng biến thiên? Tất cả đều phụ thuộc vào quá trình xử lý font mà ta sẽ viết sau đây.

1) Tạo một bộ font chữ cái La Tinh có dấu tiếng Việt. Có thể dùng YY-CHR hoặc các phần mềm xử lý ảnh dạng pixel, sau đó convert thành định dạng 2bpp. Bởi vì text trong Zelda 3 được hiển thị ở mode 1, trong đó lớp Background 3 được dùng để hiển thị text có độ sâu màu 2bpp, tức mỗi tile có thể hiển thị tối đa 4 màu.

2) Tại routine đọc ký tự text ở vùng Workram $7F1200, đọc từng giá trị tại chuỗi này. Nếu giá trị là control code thì không cần can thiệp, nếu giá trị là ký tự Kana thì xử lý tiếp các bước đánh số bên dưới.

REP #$30

LDX $1CD9

LDA $7F1200,x

CMP #$FF00

BEQ +

SEP #$30

LDA #$0C

STA $012F

REP #$30

+

LDA $1CDD

ASL

TAX

SEP #$20

LDA $1CDC //tile pro

STA $1301,x

STA $1303,x

STA $1305,x

STA $1329,x

STA $132B,x

STA $132D,x

JSR write_text_pos

3) Render ký tự 

Đây là phần phức tạp nhất của toàn bộ quá trình, gồm các bước như dưới đây.

a. Đầu tiên là liên kết từ giá trị ID của mỗi ký tự đến phần tileset tương ứng của ký tự đó trong bảng font. Cách tạo liên kết phụ thuộc vào cách mà ta sắp xếp dữ liệu font trong Rom. Có khá nhiều cách xếp, nhưng phổ biến nhất là 2 cách xếp như dưới đây.

Ở hình trên, dữ liệu của chữ "A" được sắp xếp mặc định theo chế độ hiển thị của Super Famicom, trong khi những ký tự còn lại được sếp theo kiểu của máy Famicom. Với bất kỳ kiểu xếp dữ liệu nào thì cũng cần phải chọn kiểu xem dữ liệu tương ứng với nó trong YY-CHR để cho kết quả hiển thị đúng. Tương tự, cách xếp dữ liệu cũng ảnh hưởng tới cách mà ta vẽ chữ (render) ở bước sau, cũng như cách xếp tilemap. Chẳng hạn, bên trên là bộ font có kích thước 16 x 16 pixel cho mỗi ký tự, đủ để ta vẽ dấu tiếng Việt. Nếu coi phần bên trên của chữ "A" có địa chỉ tilemap là $00 thì đối với kiểu xếp mặc định, tile nửa bên dưới sẽ có địa chỉ là $10, còn tile thứ hai, bên trên của chữ "A" có địa chỉ là $01. Còn nếu xếp theo kiểu Famicom 16 thì tile nửa bên dưới có địa chỉ là $01, còn tile thứ hai bên trên có địa chỉ là $02,... Có thể vẽ tùy ý bằng YY-CHR rồi quan sát sự thay đổi của quỹ đạo byte bằng Hex editor để nắm quy luật.

Dưới đây là một ví dụ về cách liên kết từ giá trị ID của mỗi ký tự đến tileset của ký tự đó trong trường hợp xếp dữ liệu tileset theo kiểu Famicom 16.

REP #$20

LDA $7F1200,x

XBA

AND #$00FF

CMP #$00E8

BNE +

xử lý abcxyz...

+

ASL #6

TAX

LDY #$0000

SEP #$20

-

LDA font0,x

XBA

LDA font0+0x20,x

JSR shift_pix

ORA {char_buffer}+0x20,y

STA {char_buffer}+0x20,y

XBA

ORA {char_buffer},y

STA {char_buffer},y

LDA font0+0x10,x

XBA

LDA font0+0x30,x

JSR shift_pix

ORA {char_buffer}+0x30,y

STA {char_buffer}+0x30,y

XBA

ORA {char_buffer}+0x10,y

STA {char_buffer}+0x10,y

INY

INX

DEC {buffer1}

BNE -

PLB

REP #$20

LDA #$BFC0

STA $04

LDA #$007E

STA $06

RTS

Bên trái là hình ảnh tileset của bộ chữ được chứa trong Rom, mỗi ký tự là một tile. Nếu không xử lý gì và để nguyên như thế này mà ghi vào Vram thì từ nào có bao nhiêu ký tự thì sẽ tốn bấy nhiêu tile, không đẹp về mặt thẩm mỹ và cũng không hiệu quả về mặt không gian. Còn bên phải là hình ảnh bộ chữ sau khi được xử lý, một tile có thể chứa nhiều ký tự, mỗi ký tự chỉ chiếm một khoảng không gian vừa đủ với độ rộng của nó.

Để làm được việc này thì ta cần đến phép shift bit về bên phải. Nói đại khái thì sau khi đọc dữ liệu hình ảnh của ký tự, ta sẽ đẩy các bit của dữ liệu đó về bên phải với số lần tương ứng với độ rộng của ký tự đứng trước đó. Chẳng hạn, đối với từ "file" ta có 4 ký tự gồm "f", "i", "l" và "e". Giả định "f" có độ rộng là 5 pixel, "i" có độ rộng 1 pixel, "l" có độ rộng 2 pixel và "e" có độ rộng là 4 pixel. Một tile luôn có độ rộng không đổi là 8 pixel. Do vậy, khi ghi ký tự đầu tiên là "f" trong chuỗi này thì ta shift (đẩy) hình ảnh của "f" về phía phải 0 pixel, tức là không cần shift. Do nó chỉ chiếm 5 pixel trong tile, mà tile có 8 pixel nên vẫn còn lại 3 pixel trống về phía phải. Ký tự tiếp theo là "i" chỉ chiếm 1 pixel nên hoàn toàn chứa vừa trong phần còn lại của tile thứ nhất. Lúc này, khi ghi hình ảnh của "i" thì phải đẩy nó về phía phải 5 pixel để nó đứng liền sau hình ảnh của ký tự "f" trong tile. Các ký tự còn lại trong chuỗi cũng được xử lý tương tự.

LDA font0,x

XBA

LDA font0+0x20,x

   JSR shift_pix

Điểm lưu ý: đọc 1 byte của tile thứ nhất và 1 byte của tile liền kề sau đó trước khi shift. Mỗi lần shift sang phải, giá trị của byte giảm đi một nửa.

shift_pix:

REP #$20

CMP #$0000

BEQ end_shift_pix

PHX

LDX {shift}

CPX #$0000

BEQ end_shift_pix-1

-

LSR

DEX

BNE -

PLX

end_shift_pix:

SEP #$20

RTS

Routine đẩy bit về bên phải đơn giản như bên trên. Khi giá trị shift là 00 thì thoát khỏi routine ngay lập tức. Hình bên dưới thể hiện mối tương quan giữa vị trí của pixel với giá trị byte của nó.

5) Tạo liên kết từ giá trị ID của ký tự đến giá trị độ rộng của ký tự đó. Cách thức không khác với cách tạo liên kết đến tileset của bộ font ở phần trên, nhưng thay vì dẫn đến địa chỉ hình ảnh của font trong Rom thì ở đây dẫn đến địa chỉ của table chứa độ rộng của các ký tự. Có thể chứa table này trong Rom hoặc Ram tùy ý.

LDX $1CD9

LDA $7F1200,x

XBA

AND #$00FF

TAX

LDA font0_width,x

AND #$00FF

STA {char_haba}

Biến số {char_haba} là nơi chứa độ rộng của ký tự. Sở dĩ cần phải tính độ rộng của mỗi ký tự vừa ghi vào vùng đệm là để tính số pixel còn thừa lại của tile.

6) Sau khi tính độ rộng của ký tự vừa render, ta cần tính số lần shift sang phải cho ký tự tiếp theo. Ý niệm ở đây rất đơn giản. Nếu ký tự vừa rồi, tính cả số pixel đã shift của nó không dùng hết 8 pixel thì vẫn giữ nguyên tile đó cho lần vẽ tiếp theo, và ở ký tự tiếp theo phải shift sang phải với số lần bằng với số pixel còn thừa lại trong tile. Còn nếu tổng độ rộng của ký tự vừa rồi và số lần shift của nó có độ rộng từ 8 pixel trở lên thì chuyển sang tile tiếp theo.

LDA {shift}

CLC

ADC {char_haba}

CMP #$0008

BCS +

AND #$0007

STA {shift}

RTS

+

CMP #$0010

BCS +

SEC

SBC #$0008

AND #$0007

STA {shift}

INC {tile_no}

RTS

7) Bước cuối cùng của quá trình render một ký tự là chuyển tileset của nó vào Vram. Cách tốt nhất để làm việc này là thực hiện một cách tự động trong thời gian V-blank. Sau khi tính toán xong mọi thứ cần thiết thì chỉ cần ghi địa chỉ Vram cần chuyển dữ liệu, kích thước dữ liệu, địa chỉ dữ liệu và byte kích hoạt chức năng tự động DMA trong kỳ Vram. Đoạn code dưới đây ghi các thông số cần thiết để DMA 0x800 byte hình ảnh các chữ cái ở $7F8000 vào địa chỉ Vram $F800.

REP #$20

LDA #$F800>>1

STA {vram_address}

LDA #$0800

STA {dma_size}

LDA #$8000

STA {dma_adress}

SEP #$20

LDA #$7F

STA {dma_bank}

INC {trigger}

Còn trong routine NMI, chỉ cần đặt một chức năng như dưới đây là có thể tự động DMA vào địa chỉ Vram đã chỉ định.

SEP #$20

LDA {trigger}

BNE +

RTS

+

REP #$20

LDA {vram_address}

STA $2116

LDA {dma_size}

STA $4305

LDA {dma_adress}

STA $4302

LDA #$1801

STA $4300

SEP #$20

LDA #$80

STA $2115

LDA {dma_bank}

STA $4304

LDA #$01

STA $420B

STZ {trigger}

RTS

Như vậy là kết thúc toàn bộ quá trình biến bộ font từ kiểu có độ rộng cố định thành kiểu có độ rộng biến thiên.

Theo engine hiển thị nguyên bản của game thì phần khung thoại trong suốt, không có màu khiến việc đọc chữ đôi khi gặp trở ngại do hình ảnh của cảnh nền chen lấn với phần chữ. Nếu ta đặt nền khung thoại có màu đục thì sẽ khắc phục được tình trạng trên, nhưng nếu nền khung thoại vừa có màu, mà vẫn giữ được độ trong suốt để thấy cảnh nền bên dưới thì sẽ ra sao?