PC-FX Zeroigar Translation Development Thread

[SamIAm]

GREAT news, you guys.

Remember this?

3. Take subtitled AVI and convert it with MPCONV2. This is a program included with the PC-FXGA GMAKER development kit that encodes AVIs to MIX, which is a format the PC-FX's HuC6271 video playback chip can understand.

...you can tell it to encode at certain "Quality" settings which don't have ceilings. Quality=0 effectively tells it to use as much data as it could want, and Quality=1, 2, 3 etc. step that amount down by about 10% each successively.

Guess what? For 13 of the game's 16 FMVs, encoding at Quality=0 yields files that actually work on real hardware!

The fact that the buffer can handle some of the data rate spikes blows my mind, but I've tested multiple burns in multiple playthroughs, and there's been no variation in the playback at all.

The three FMVs that don't work are actually the first three in the game: the opening cinema, the theme song cinema, and the pre-stage 1 cinema. However, these also work just fine if we encode them with very high data rate ceilings (330KB/s, 340KB/s, and 355KB/s, respectively). These look great, and the difference between them and Quality=0 encodings is negligable.

Of course, I'll also want to test on other systems just to make sure that they can handle these extreme data rate spikes.

As a matter of fact, Mednafen does not deal with these accurately. I'll be getting in touch with the author soon about this. Basically, Mednafen is simulating the drive speed limits, but it's underrunning the buffer and failing at points that a real system doesn't.

The good news there is that Mednafen contains a setting that allows you to raise the speed of the virtual PC-FX drive, and if you do so, the problem goes away.

[esteban]

Awesome. 

[dshadoff]

The fact that the buffer can handle some of the data rate spikes blows my mind, but I've tested multiple burns in multiple playthroughs, and there's been no variation in the playback at all.

The three FMVs that don't work are actually the first three in the game: the opening cinema, the theme song cinema, and the pre-stage 1 cinema. However, these also work just fine if we encode them with very high data rate ceilings (330KB/s, 340KB/s, and 355KB/s, respectively). These look great, and the difference between them and Quality=0 encodings is negligable.

Of course, I'll also want to test on other systems just to make sure that they can handle these extreme data rate spikes.

As a matter of fact, Mednafen does not deal with these accurately. I'll be getting in touch with the author soon about this. Basically, Mednafen is simulating the drive speed limits, but it's underrunning the buffer and failing at points that a real system doesn't.

The good news there is that Mednafen contains a setting that allows you to raise the speed of the virtual PC-FX drive, and if you do so, the problem goes away.

I wonder how much of the buffering is done on the CPU side, and how much is done in the CD-ROM hardware side.

By the time the PC-FX was released, it was already becoming commonplace for portable CD players to include roughly 1 second of buffer for the audio (in case of skip).  While unnecessary on the PC-FX, I recall that CDROM drives faster than 1X generally had some kind of buffering mechanism just to manage the data flows.  32KB to 64KB wouldn't be unreasonable.

So, as long as the peak speed wasn't too much higher than normal, and as long as the duration of the peak wasn't too high, the buffer wouldn't be completely drained.

-Dave

[elmer]

I wonder how much of the buffering is done on the CPU side, and how much is done in the CD-ROM hardware side.

By the time the PC-FX was released, it was already becoming commonplace for portable CD players to include roughly 1 second of buffer for the audio (in case of skip).  While unnecessary on the PC-FX, I recall that CDROM drives faster than 1X generally had some kind of buffering mechanism just to manage the data flows.  32KB to 64KB wouldn't be unreasonable.

Unfortunately, I haven't disassembled the video playback code to see just how much of the 1MB of King RAM that it is using.

This 1995 article from Next Generation magazine claims that there's a 256KB CD buffer.

http://archives.tg-16.com/NG/NG_1995_01_040.jpg

I can't find any mention of that buffer in the PC-FXGA documentation, but I guess that that's not too surprising, since the PC-FXGA uses the PC's CDROM that could contain anything.

256KB seems quite large for the time ... but given the PC-FX's need to play back digital video with wildly-variable data rates, I guess that it is plausible, and it would certainly help explain what we're seeing in practice.

So, as long as the peak speed wasn't too much higher than normal, and as long as the duration of the peak wasn't too high, the buffer wouldn't be completely drained.

I've been quite surprised at just how variable the data rate is in the videos.

There's usually plenty of opportunity to refill the buffer (whatever size it is) ... as long as the spike doesn't last too long.

Here's an example of one of the videos that works ...

Code: [Select]

Frame Rate Over Time (in KB/s) "+++"=AVG "---"=MAX:

    180 190 200 210 220 230 240 250 260 270 280 290 300 310 320 330 340 350 360
000s+++
001s+++ --- --- ---
002s+++ --- --- ---
003s+++ --- --- ---
004s+++ +++ --- ---
005s+++
006s+++ ---
007s+++ +++ +++ +++ +++ ---
008s+++ +++ +++ +++ +++ ---
009s+++ +++ +++ +++ +++ +++ +++ +++
010s+++ +++ +++ +++ +++ +++ +++ +++ +++ --- --- ---
011s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ ---
012s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ ---
013s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ ---
014s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++
015s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++
016s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ --- --- ---
017s+++ +++ +++ +++ +++ +++ +++ +++
018s+++ +++ +++ +++ +++ +++ +++ +++
019s+++ +++ +++ +++ +++ +++ +++ ---
020s+++ +++ +++ +++ +++ +++ +++
    180 190 200 210 220 230 240 250 260 270 280 290 300 310 320 330 340 350 360

I'm attaching the graphs for all SamIAm's hard-subbed Q0 videos for anyone that's curious.

These are the largest files where zero01.mix, zero02.mix and zero03.mix do NOT work ... and so it gives some idea of the limits.

[elmer]

And last but not least, there are two completely separate additional solutions for making the FMVs look good.

1. Perform some programming voodoo to move the original video as-is up 16 pixels, and then add the subtitles separately like mentioned above. This is ideal in terms of quality (no additional lossiness to the image whatsoever), but possibly very difficult in terms of programing.

Well ... as of yesterday, this actually works now. 

This gives us a couple of benefits ...
[ul][li]There is absolutely no loss in video quality.[/li][li]The files with the Q0-encoded subtitles are slightly smaller than the Q0-encoded all-in-one files.[/li][li]The translation patch will be much, much, much smaller, and won't need to include any of the original copyrighted game content.[/li][/ul]Technically ... a huge "thanks" to David Michel for figuring out the video data format in the first place for MagicEngine-FX, and then passing that information on to Ryphecha for Mednafen.

The ability to look at Mednfen's video-playback code, and then decompress Zeroigar's M-JPEG bitstream into it's individual components, allowed me to understand why my first attempt to get this method to work failed ... and failed in such a visually spectacular way! 

I can't even imagine just how hard it was to figure out the PC-FX's video data format, whether it was by hacking data on a real PC-FX, or disassembling Hudson's MPCONV2 compressor, or looking at the work that the Japanese hacker "soltin" did back in the early 2000's.

http://hwbb.gyao.ne.jp/soltin/gametool.html

[SamIAm]

I'm telling you guys, elmer is one hell of a hacker.

Unfortunately, I haven't disassembled the video playback code to see just how much of the 1MB of King RAM that it is using.

This 1995 article from Next Generation magazine claims that there's a 256KB CD buffer.

http://archives.tg-16.com/NG/NG_1995_01_040.jpg

I can't find any mention of that buffer in the PC-FXGA documentation, but I guess that that's not too surprising, since the PC-FXGA uses the PC's CDROM that could contain anything.

256KB seems quite large for the time ... but given the PC-FX's need to play back digital video with wildly-variable data rates, I guess that it is plausible, and it would certainly help explain what we're seeing in practice.

The official specs released by NEC have that same 256KB figure for the drive cache.

Also, I think the potentially limitless cache for PC-FXGA systems was something they talked up, and definitely something Japanese users have talked about.

One thing I wonder about is whether NEC ever had any dreams of licensing good homebrew PC-FXGA games for the PC-FX. You would kind of think that they would, but there's the cache difference and the 3D chip. Maybe they thought the PC-FXGA would become a popular system on its own?

I'm very psyched that we're using the original video. Not having those stupid 16x16 black blocks, and otherwise having substantially cleaner parts of the game with black areas, is a wonderful thing.

Now there's just getting the best quality subtitles in there that we can, without overwhelming any drives.

[elmer]

One thing I wonder about is whether NEC ever had any dreams of licensing good homebrew PC-FXGA games for the PC-FX. You would kind of think that they would, but there's the cache difference and the 3D chip. Maybe they thought the PC-FXGA would become a popular system on its own?

I think that there's some mention in the PC-FXGA documentation about being able to offically register and get a "unlocked" license file that would allow you to run your games on a real PC-FX ... at which point you'd probably be a licensed developer and Hudson would publish your game (if they thought that it was good enough).

Not too different to Sony and Microsoft's modern "indie" programs.

I suspect (with absolutely no proof) that the 3D chip was there to help get 3D games developed for the PC-FX's 3D add-on card that would have slotted into the bottom expansion slot of the PC-FX.

Comparing the retail PC-FXGA to Sony's early official Playstation development cards ... I also suspect that the PC-FXGA board was actually Hudson's official professional development kit for the PC-FX.

It makes more sense to me that they'd just recycle the offical devkit as the PC-FXGA, rather than design completely new boards for the very limited retail market that the PC-FXGA would appeal to.

I'm very psyched that we're using the original video. Not having those stupid 16x16 black blocks, and otherwise having substantially cleaner parts of the game with black areas, is a wonderful thing.

Now there's just getting the best quality subtitles in there that we can, without overwhelming any drives.

The testing that we're doing is already showing up some really interesting things about the way that the MPCONV2 compressor is working, and how we can get the absolute best-quality out of the subtitled videos! 

[elmer]

The testing that we're doing is already showing up some really interesting things about the way that the MPCONV2 compressor is working, and how we can get the absolute best-quality out of the subtitled videos! 

For anyone wanting to do PC-FX video compression in the future ...

It looks very much like Hudson's MPCONV2 video converter starts by compressing individual frames at Q0 (highest quality), and then if they're too big for the frame-rate that you've set, it recompresses them at Q1 (2nd best), and sees if they'll fit ... and so on.

If you look carefully, you can see that the following snippets of the graphs from the 2nd Zeroigar video show what happens when a long subtitle is displayed, exceeding the frame-rate limit that's been set.

The 120KB/s video starts out at Q0, then switches to Q1 when the subtitle appears, then switches back to Q0 again when the subtitle changes.

Looking at the screen capture ... you can just see faint blue dots around the subtitle because of the drop in quality from Q0 to Q1. Those dots definitely aren't there in the Q0 video.

Code: [Select]

Subtitle "Luru hurried to build Zeroigar, the weapon to defeat Emperor Zemu."

Frame Rate Over Time (in KB/s) "+++"=AVG "---"=MAX:

Q0 (highest quality)

    180 190 200 210 220 230 240 250 260 270 280 290 300 310 320 330 340 350 360
006s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ --- ---
007s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ --- --- ---
008s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++
009s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ ---
010s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++
011s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++
012s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ --- ---
013s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ ---
014s+++ +++ +++ +++ +++ +++ +++ +++ +++ --- ---
015s+++ +++ +++ +++ +++ +++ +++ +++ +++ ---

120KB/s

    180 190 200 210 220 230 240 250 260 270 280 290 300 310 320 330 340 350 360
006s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ --- ---
007s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ --- ---
008s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++
009s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++
010s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ ---
011s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ ---
012s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ ---
013s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ ---
014s+++ +++ +++ +++ +++ +++ +++ +++ ---
015s+++ +++ +++ +++ +++ +++ +++ +++ +++ ---

Q1 (2nd best quality)

    180 190 200 210 220 230 240 250 260 270 280 290 300 310 320 330 340 350 360
006s+++ +++ +++ +++ +++ +++ +++ +++ --- --- ---
007s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ --- --- ---
008s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++
009s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++
010s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ ---
011s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ ---
012s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ ---
013s+++ +++ +++ +++ +++ +++ +++ +++ +++ +++ +++ ---
014s+++ +++ +++ +++ +++ +++ +++ +++ ---
015s+++ +++ +++ +++ +++ +++ +++ +++ ---


[dshadoff]

Very cool stuff, BTW.

I was wondering about the subtitling exercise - do you have more information on the exact file format for this "lossless AVI" format ?

And what tools are you using to shift the graphic up and implant the text ?

I was wondering because the thought had occurred to me long ago to do this for Gulliver Boy (and the Yuna HuVideo), ever since Tomaitheous showed us the HuVideo storage format (but didn't know what tools existed to assist):

Header: 0x2000 bytes long
16 bytes = "HuVideo"+ padded with 0x00
2 bytes = length in frames(0x3000) of video
2 bytes = x width of video frame (pixels)
2 bytes = y width of video frame (pixels)
2 bytes = (always 0x10)
2 bytes = (always 0x06)


Yuna frame layout: 160x128 window 10fps
0000-27FF = tile data - uncompressed
2800-29FF = new palette data (all 256 colors)
2A00-2AbF = tile mape ( 4bit entries )
2AA0-2FFF = ADPCM data + noise buffer + trailing fixed string


Gulliverboy frame layout: 192x112 window 10fps
0000-29FF = tile data - uncompressed
2A00-2BFF = new palette data (all 256 colors)
2C00-2CA7 = tile mape ( 4bit entries )
2CA8-2FC7 = ADPCM data
2FC8-2FEF = noise buffer
2FF0-2FFF = either some sort of header or ADPCM string(for overflow) - same value for every frame.

[elmer]

I was wondering about the subtitling exercise - do you have more information on the exact file format for this "lossless AVI" format ?

And what tools are you using to shift the graphic up and implant the text ?

While waiting for SamIAm to provide a definitive answer, I believe that he's using VirtualDub for the main video processing.

VirtualDub does have a filter to add hard-coded subtitles ... but I don't know if he's using that or something else.

Once you've got the video into AVI format, there are plenty of options.

AVI is just a container format ... there are lots of codecs available, both lossy and lossless.

The simplest "lossless" option is to just store raw uncompressed RGB bitmaps in an AVI so that you can do your editing. Or you can install a lossless-compressor codec like lagarith or CorePNG.

http://www.jmcgowan.com/avicodecs.html
http://www.alexander-noe.com/video/documentation/avi.pdf

VirtualDub should be able to compile an AVI from a directory full of individual BMP files, and then decompile it back into BMP files again when you've done whatever transformations you want to do (like adding subtitles).

So, if you can write a simple converter to dump those HuVideo frames as a big set of BMP files, you should be OK.

But does anyone have a compressor to create a HuVideo file from a bunch of images (or an AVI)?

You'd also need to handle extracting/interleaving the original audio data ... both into the AVI for editing, and also back into the HuVideo file (or preferably, just copy the existing HuVideo audio data).

It sounds like some custom tools would be needed.

That's pretty much what I've had to do for reinserting the Zeroigar videos back into the CD ... merge the original and the subtitle video streams together on a frame-by-frame basis.

[ParanoiaDragon]

Made the news on Siliconera! http://www.siliconera.com/2015/08/25/robot-anime-style-action-shooter-god-fighter-zeroigar-translated-into-english/

[NightWolve]

Huh, so elmer and SamIAm (plus esteban) are "the people at romhacking.net" ??

[elmer]

Huh, so elmer and SamIAm (plus esteban) are "the people at romhacking.net" ??

Thanks for the link, I hadn't seen it.  Always nice to get a little notice.

At least the guy didn't say a whole bunch of inaccurate stuff about the PC-FX! 

I enjoyed the commentard that was so down on us pirating the game ... such a brainiac! 

[NightWolve]

I enjoyed the commentard that was so down on us pirating the game ... such a brainiac! 

Hah, I saw, what a clown... I felt the need to respond to him.

He's, you know, a stickler for the rules, you see, you gotta wait out the full ~75 years before you produce unlicensed translations or redistribute the whole game itself... Yes, who cares of the law's technical inflexibility and blindness, follow it, and no, no principles of abandonware or de facto public domain should ever be considered, wait out the full damn ~75 years or get a license! If not, the game must be left untouched, untranslated, trapped in out-of-print pieces of plastic for the full ~75 years and only available to those who obtained said pieces of plastic...

He also doesn't understand how unlicensed translations are normally distributed without the videogame they target (but even so, who would give a shit on an old IP or for a dead system say for a few sticklers like him?)... Anyway, yeah, what a hero, fighting the good fight for some old game few ever even heard of till now! Way to go!!

[elmer]

Made the news on Siliconera! http://www.siliconera.com/2015/08/25/robot-anime-style-action-shooter-god-fighter-zeroigar-translated-into-english/

Looks like there's been 40 downloads of the patch since that article went up yesterday ... not bad!