Sakura Wars 3 English Translation Project

[The Opponent]

Today's update introduces Glycine Bleumer, a proud noble who has some pointed questions for Ogami.
https://twitter.com/TaishoRoman3/status ... 6323765249

The purpose of this update is to show subtitled Dreamcast FMV and how seamlessly the cutscenes blend back into normal gameplay. I've documented our process for extracting and encoding video on the wiki: https://github.com/TheOpponent/st3-tran ... o-encoding

[fafadou]

It's awesome to five some news ans update, thanks ?

Could you add in the github, how have you done for adding subtiles during fmv please ?

[ateam]

It's awesome to five some news ans update, thanks ?

Could you add in the github, how have you done for adding subtiles during fmv please ?

From the GitHub document, the following is stated:

Adding subtitles to video files using Aegisub and burning them into the video is a well-documented procedure and will not be duplicated here. For maximum video quality, it is recommended to use the video files from the PC version of Sakura Taisen 3 as a source, as those videos are in plain MPEG-1 format at 640 x 480 resolution. However, the audio sample rate will need to be converted to 22050Hz before encoding to SFD, as the SEGA Dreamcast Movie Creator is unable to perform the conversion correctly.

[fafadou]

Ok so you used aegisub instead of ffmpeg.

[The Opponent]

One of the early concerns we had with this project was modifying graphics shown on the VMU, which include logo animations and messages for save file operations. The image data for these graphics were not stored in any clear format, so we focused on the script instead. This week, I investigated how the game handles VMU screen update operations.

With assistance from ateam, I determined that Sakura Wars 3 is one of the rare games that uses low-level LCD functions to update the VMU screen. This allows for the screen to be updated very quickly, up to 30 Hz to show fast logo animations and a live minimap in combat situations, but it also means that screen data is sent to the VMU 1 bit at a time, and that makes searching for stored VMU screen data very difficult. In order to locate such images as a single frame of the Sakura Wars 3 logo shown during the boot sequence, I searched through RAM dumps using CrystalTile 2 in 1bpp mode looking for a pattern that resembled a legible 48 x 32 image.

0010965.png (2.04 KiB) Viewed 71402 times

After confirming that the image is being written into a discrete location in RAM, I then saved a hex dump of that 1bpp image, which is 192 bytes in length rather than the expected 1,536 bytes that would be used by standard LCD screen functions. Searching the game's files for a match of that 192 bytes yielded no results, which made me believe that either the LCD image data was either encoded or stored in an archive. These logos are displayed as the game is booting, so I reasoned that it they must be located in the disc root. Finally I extracted SYSLIST.AFS and examined each file, and found a number of BIN files that turned out to be sequences of raw bitmaps, similar to SKFONT.CG. CrystalTile 2 reveals that the file tyt00.bin in SYSLIST.AFS contains the logo animation in question with all frames in sequence:

From here, I modified my Python script for font tile conversion to generate 1bpp LCD screen data sequences, and modified the last two frames of the logo to test the replacement. The last two frames are alternated rapidly to create a shimmering effect on the LCD screen.

This video shows a hardware test of this animation. With this, another concern of the translation project has been resolved earlier than expected.

While I was searching for the LCD animations, I also found what appears to be VMU executables, with plainly visible 1bpp graphic data that should be editable.

[streeker]

While I was searching for the LCD animations, I also found what appears to be VMU executables, with plainly visible 1bpp graphic data that should be editable.

That's right. Sakura Wars 3 contains a VMU minigame called "Pari No Futari". That's what you've come across.

[VincentNL]

Have a look at Gif2SVMU, you may find it useful for converting gif animations to VMU gfx data directly.
(Please note it is supposed to work with _pdVmsLcdWrite1 library function.)

https://github.com/VincentNLOBJ/GIF2SVMU

[The Opponent]

The other major concern we had with VMU functionality throughout the game are the Mobile Kinematron messages that scroll across the screen. I discovered this week that these messages are stored in the game's script as normal strings. The screen data is formed in memory using the normal in-game font, which is converted to 1-bit pixel data and stored in a buffer that is scrolled across the screen until the player dismisses it. I traced the function that generates the image for the LCD screen, but was unable to change the character width to accommodate English text. This function is separate from the other text functions for the main script and ignores all control codes, so using codes to manually set character width was not an option either. The text is read and rendered instantaneously, so the typical method of using Cheat Engine to search for a character width byte was not viable here.

Incidentally, if no VMU with a screen is connected in port A-1, a fallback copy of the same message is displayed on the TV screen. In the script, this fallback message is stored immediately after the message for the LCD screen and is given extra formatting for the text box.

Knowing that the characters for these messages can be changed like any other line in the script, I decided to change the line to unused font tiles and redefine those tiles to form an English message. We already use this technique for map labels.

This video is the hardware test for Kinematron message translation proof of concept. The font and content is subject to change. For this proof of concept, I used Helvetica Neue Medium with no antialiasing with extra character spacing. I experimented with our current in-game English font for consistency, but I was unable to make the font look presentable without antialiasing. I settled on using a different proportional font that scales well as a pixel font to conserve font tiles. I had to carefully select the font here to ensure that the message is legible as it scrolls on the VMU screen, which has a long response time and no backlight. The message can be scrolled faster with the A button, which may make the message unreadable due to motion blur depending on the quality of the screen.

With this, the only remaining VMU concern for this game are the minigames. As mentioned in my previous post, their graphics are stored as 1bpp image data that we should be able to edit.

We posted a more extensive proof of concept video of this translation on Twitter: https://twitter.com/TaishoRoman3/status ... 7814697985

[wakabayashy]

keep up the good work!

[kozi801]

Je suis heureux de savoir que la communauté française traduira en français

I am happy to learn that the community might make a french Translation too