Sakura Wars 3 English Translation Project

Moderators: pcwzrd13, deluxux, VasiliyRS

User avatar
The Opponent
rebel
Posts: 21
Contact:

Re: Sakura Wars 3 English Translation Project

Post#21 » Wed Jun 01, 2022 12:44 am

These are Flycast texture dumps of the battle system interface graphics we're searching for. Unit names are also stored as graphics.
Attachments
7d7e5f4e.png
7d7e5f4e.png (18.86 KiB) Viewed 59996 times
3399d9a3.png
3399d9a3.png (17.5 KiB) Viewed 59996 times
64a6b3ca.png
64a6b3ca.png (3.62 KiB) Viewed 59996 times
88e234c1.png
88e234c1.png (24.77 KiB) Viewed 59996 times
17873e33.png
17873e33.png (31.95 KiB) Viewed 59996 times
b89419eb.png
b89419eb.png (62.17 KiB) Viewed 59996 times

TapamN
letterbomb
Posts: 149

Re: Sakura Wars 3 English Translation Project

Post#22 » Wed Jun 01, 2022 5:18 am

The Opponent wrote:These are Flycast texture dumps of the battle system interface graphics we're searching for. Unit names are also stored as graphics.

Luckily the textures are uncompressed, so it was easy to find. It's seems like they're duplicated in multiple battle directories. This one I found is in SLG/G01/SMAP01.ESM at offset 0x1a10f8:
Screenshot_2022-06-01_04-00-14.png

This is a very basic and incomplete program I was working on to work with PVR textures. It can view .PVR files and scan through and display uncompressed raw texture data. At the moment, it's crash prone if you use it wrong, and the UI is cumbersome (need to mostly use the mouse, not keyboard, when scanning through raw data), but it's just enough to display 16-bit textures. One thing I had planned was that you could replace graphics when you find a texture, for modding games, but I never got around to it.

Edit:
Semirelated story: The disc drive on my orignal Dreamcast died while placing ST3. While I was playing, I stopped to eat, and the disc drive spun down. When I got back, the drive would no longer spin up. If I held the lid sensor closed, I could see the disc jiggle a bit when it tried to spin up, and if helped give it a start by spinning it with my finger it could only run at around 0.5x speed for a bit until it gave up. That DC lasted about 7 years (I got it 2000 when the price dropped to $150, and it died in 2007). My current main DC I got to replace it has been working fine since then.

User avatar
fafadou
Gold Lion
Posts: 1653

Re: Sakura Wars 3 English Translation Project

Post#23 » Wed Jun 01, 2022 5:59 am

A fantastic tool dear @TapamN :-)

User avatar
yzb
Developer
Posts: 130

Re: Sakura Wars 3 English Translation Project

Post#24 » Wed Jun 01, 2022 6:36 am

I don't know what you mean by compressed data, I just took a look

The compression method used in this game is prs compression, but there are some more file headers

User avatar
The Opponent
rebel
Posts: 21
Contact:

Re: Sakura Wars 3 English Translation Project

Post#25 » Wed Jun 01, 2022 10:45 am

TapamN wrote:
The Opponent wrote:These are Flycast texture dumps of the battle system interface graphics we're searching for. Unit names are also stored as graphics.

Luckily the textures are uncompressed, so it was easy to find. It's seems like they're duplicated in multiple battle directories. This one I found is in SLG/G01/SMAP01.ESM at offset 0x1a10f8:
Screenshot_2022-06-01_04-00-14.png
This is a very basic and incomplete program I was working on to work with PVR textures. It can view .PVR files and scan through and display uncompressed raw texture data. At the moment, it's crash prone if you use it wrong, and the UI is cumbersome (need to mostly use the mouse, not keyboard, when scanning through raw data), but it's just enough to display 16-bit textures. One thing I had planned was that you could replace graphics when you find a texture, for modding games, but I never got around to it.

Edit:
Semirelated story: The disc drive on my orignal Dreamcast died while placing ST3. While I was playing, I stopped to eat, and the disc drive spun down. When I got back, the drive would no longer spin up. If I held the lid sensor closed, I could see the disc jiggle a bit when it tried to spin up, and if helped give it a start by spinning it with my finger it could only run at around 0.5x speed for a bit until it gave up. That DC lasted about 7 years (I got it 2000 when the price dropped to $150, and it died in 2007). My current main DC I got to replace it has been working fine since then.

Thank you for this discovery. Incidentally, yesterday I was searching for text related to tactical decisions during the combat sections and found that some of them weren't in the script files. They were also located in SLG/G01/SMAP01.ESM, and duplicated in other ESM files. These text data blocks have a different format from the script files, but changing them to longer strings presented no apparent issues. To replace this text, I manually pasted the translated text into the ESM file to replace the original text block.

0004518.png
0004520.png


For the interface graphics, at 0x1a0fa5 is the signature BPV1. This signature occurs many times throughout other files we believe to contain graphics, but none of the tools available to us are able to display them.

User avatar
ateam
Heroine Console
Posts: 478

Re: Sakura Wars 3 English Translation Project

Post#26 » Wed Jun 01, 2022 2:03 pm

TapamN, that tool to view headerless PVR textures (by adjusting settings in the UI) looks great. Can't wait to see you release it one day!

That said, I decided to take what's shown in that screenshot. For those familiar with PVR Tool (aka WinPVR), a texture with identical settings would appear in the information window as such:

Image

Now, these textures in SW3 appear to be either...

    A) Headerless (as in, their header described/stored elsewhere).
    B) Stored with their texture settings encoded in the BPV1-signed header shown in previous posts.

What I'm about to show is not at all ideal and will scale poorly. However, until either A or B is solved, this may be a good start to knock out a large portion of PVRs.

So given that TapamN was able to identify the correct texture settings, I went ahead and inserted the appropriate matching header inside the SMAP01.ESM file The Opponent was showing in this thread. The specific offset for this example texture is 0x0x1a10e8. The byte-string is 50 56 52 54 08 00 02 00 02 01 00 00 00 01 00 01.

Image

After saving the file, I can use something like PVR Viewer to scan SMAP01.ESM for embedded textures. A key difference between this utility (and all other PVR extraction utilities I'm presently aware of) is that it relies on header data to act as a delimiter, as well as to provide details on how the texture data itself is stored. TapamN's tool, on the other hand, is more akin to what one sees in something like CrystalTile2, where the user himself can adjust said settings as needed until arriving at the correct ones.

Image

From here, I can either extract this individual PVR directly out of SMAP01.ESM by using PVR Viewer, or I could do so by manually copying/pasting the hex data between BPV1 headers, or even by writing a custom utility. For the sake of example, the easiest method is to simply extract directly from PVR Viewer.

After doing so, we can then use the aforementioned PVR Tool (aka WinPVR) to open the individual texture, where we'll see that everything appears as it should, and even alpha channel/transparency properties are in-tact.

Image

Lastly, I'll note that out of curiosity, I did a recursive scan of all SW3's files to see if this specific PVR header was found anywhere else. If it were, it could potentially show you the separate, external location (or even the location within the SMAP01.ESM file itself) where the header data is being stored.

To do this, I used my own little byte-searching utility (https://github.com/DerekPascarella/ByteSearch) to look for 08 00 02 00 02 01 00 00 00 01 00 01 (i.e., everything after PVRT inside the known-to-be-good header).

Image

Unfortunately, no useful results were returned. The SYSLIST.AFS file matched because there are several textures inside of it with the same header settings, which is also true of the disc art PVR (0GDTEX.PVR). Also, SMAP01.ESM popped up as a false-positive because of the data that I manually patched there.

Well, that wraps up the little bit of digging I did on this matter. Personally, I tend to believe that the PVR texture settings are encoded in some currently unknown (at least to us in this thread) format vis-à-vis that BPV1 header shown previously.

For the curious, the following links represent trustworthy documentation on PVR headers as implemented on the SEGA Dreamcast:
https://github.com/nickworonekin/puyotools/wiki/PVR-Texture
https://fabiensanglard.net/Mykaruga/tools/segaPVRFormat.txt

Best of luck, and happy hacking!
Find me on...

DreamcastForever.com
GitHub
Reddit
SegaXtreme
Twitter
YouTube
• Discord: derek.ateam

User avatar
The Opponent
rebel
Posts: 21
Contact:

Re: Sakura Wars 3 English Translation Project

Post#27 » Wed Jun 01, 2022 5:02 pm

Thank you very much for these insights.

Using this information, I determined that extracting the data from the ESM file and placing it into a handmade PVR texture file with a resolution of 512 x 1024 allows for all relevant graphics to be decoded. However, there are two menu elements that appear to be in a different format from ARGB4444.
Attachments
test8.png

User avatar
The Opponent
rebel
Posts: 21
Contact:

Re: Sakura Wars 3 English Translation Project

Post#28 » Wed Jun 01, 2022 8:36 pm

A quick test to replace these textures was successful. This consisted of creating a PVR texture out of the first 131,072 bytes of pixel data in this region, converting it to PNG, editing it, converting it back to PVR, and then replacing the original data with the converted data.
Attachments
0004545.png

TapamN
letterbomb
Posts: 149

Re: Sakura Wars 3 English Translation Project

Post#29 » Fri Jun 03, 2022 11:19 pm

The Opponent wrote:However, there are two menu elements that appear to be in a different format from ARGB4444.

That 128x128 region is ARGB1555.

I noticed that there are also textures containing the super move names in CMAP01.GRCT.

Screenshot_2022-06-03_21-18-31.png


It looks like there are four 128x128 textures here (being displayed as one 256x256). Two 128x128 ARGB4444 placed contiguously (stacked on top of each other on the left half of the screenshot), then a 128 byte gap followed by a 128x128 ARGB4444 texture and a ARGB1555 texture immediately afterwards.

I'm releasing the code for my texture viewer as is, to help with locating any remaining textures.

I normally use Xubuntu, but the program uses wxWidgets so it would be easy (well, easier...) to port to other OSes. I managed to compile a Windows version with MinGW and get running it through Wine. There's some assertion warning when it starts, it's very sluggish, and it has trouble redrawing the screen in a few instances, but it mostly works as well as on Linux. I included a precompiled Windows version, but it needs a bunch of large DLLs from MinGW and wxWidgets. The wxWidgets DLLs are the current version (3.1.6). The required DLLs should be "libgcc_s_seh-1.dll", "libstdc++-6.dll", "wxbase316u_gcc810_x64.dll", "wxmsw316u_core_gcc810_x64.dll", and "wxmsw316u_gl_gcc810_x64.dll". If it helps track down the correct MinGW DLLs, the version of MinGW GCC I used was "x86_64-w64-mingw32-gcc (GCC) 9.3-win32 20200320".

It has the Makefile I use for Linux ("Makefile") and for Windows/MinGW ("Makefile.win"). You'll need to set up the wxWidgets libraries and compile it yourself. The Windows Makefile will probably need some adjustments for where the library and headers are found. I recommend not looking at the source... I don't use C++ often and I'm not too familar with wxWidgets, so it's really bad...

You can open a raw binary file with "File->Open Binary" or Shift+Ctrl+O.

The controls on the left are, from top to bottom
  • Texture size (width on left, height on right)
  • A spinner controlling the read position. The value is what 16-bit texel address to treat as the start of the texture. It's a decimal value that gets doubled when used as the address. A value of 0 means the texture is read from address 0 of the binary, a value of 8 means it reads from address 16 decimal, or 0x10 hex. If the text box has focus, you can use up and down on the keyboard to scroll the address texel by texel.
  • Hex address in bytes. This is where you would find the texture start in a hex editor. So this is the spinner value, doubled, in hex.
  • Size of texture in bytes (decimal)
  • Buttons to jump forward or backward by -2048, +512, or +2048 bytes
  • Color format drop down box
  • Checkboxes for mip mapping, twiddle, and compression. For UI textures, you should always be able to leave mips and compression. off, and twiddled on.
  • The next button tries to jump to the texture after the currently displayed one. It does this by adding the texture size to the address. It might not jump far enough, or jump too far, but it's better than scrolling manually. If you want to jump to the middle of what you have displayed, reduce the texture size so that the part you want to jump to isn't displayed, do the jump, then restore the texture size.

The program will crash if you read too far past the end of the file, or try to open too large of a raw file (if it's less than 8MB, it should work fine). If you open a new binary file after scrolling through another, the texture start offset does not reset, but it draws the start of the new texture anyways. You should manually set the texture start value to 0 when opening a new file.
Attachments
dctexgui.7z
(180.37 KiB) Downloaded 174 times

User avatar
The Opponent
rebel
Posts: 21
Contact:

Re: Sakura Wars 3 English Translation Project

Post#30 » Mon Jun 06, 2022 11:51 am

Thank you for posting your tool. Unfortunately, I had trouble compiling it as provided for Windows, but I believe it should prove helpful for other Dreamcast projects.

With the knowledge of how the BPV1 container stores textures (documented here), I wrote a Python script to process files that contain BPV1 signatures and create PVR textures from the information in the headers. Using this script, I independently found the textures above for the name labels, and also discovered that the textures for the intermission menus are stored in PRS-compressed BPV1 blocks in the CBD files within ADVDATA/EYECATCH. It is possible to edit these textures and recompress them.

CPRS.OUT_0x140f0[1].png
CPRS.OUT_0x140f0[1].png (9.2 KiB) Viewed 59505 times

0004569[1].png


However, the file ADVDATA/EYECATCH/TAIN_DTS.CBD contains the name labels for the team status screen, and within this texture, the names are aligned to the left. This means that the data that determines where on the screen they're placed will need to be found and edited after the name graphics are changed to English.
TAIN_DTS.CBD_CPRS1.out_0x60208[1].png
TAIN_DTS.CBD_CPRS1.out_0x60208[1].png (11.59 KiB) Viewed 59505 times


Outside of these findings with the textures, I also found how strings in the team status screen is stored. Within ADVDATA/EYECATCH/EYECATCH.BIN are a number of strings preceded by a table of pointers to absolute memory addresses, rather than relative offsets. I had gotten advice to use the unused portions of SKFONT.CG, which is itself stored into a constant memory location, for new strings and point all new strings and code to that region. The tests for both proved successful.
0004669[1].png


I had relocated my custom ASM code, which was formerly stored in blank regions in 1ST_READ.BIN, to SKFONT.CG and tested on hardware.
PXL_20220605_011937720.PORTRAIT[1].jpg

  • Similar Topics
    Replies
    Views
    Last post

Return to “Modifications”

Who is online

Users browsing this forum: No registered users