PC-FX Zeroigar Translation Development Thread

Started by elmer, 05/09/2015, 04:13 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

elmer

The PC-FX Zeroigar translation programming is now nearly done, and it's time to see if there's anyone here that is willing to help us out with the art.

If there are any artists willing to help out, here's my list of things that I think we need ...

High Priority ...

1) The top 2 icons on the game screen ... 16x16 pixels, 1 color + shadow. They're basically "Level" and "Experience".
2) Bottom left icon on the game screen ... 16x16 pixels, unknown palette (at the moment). There are 8 versions of this representing the 8 levels of gun power.

You can see these in the screenshots, below.

IMG

Medium Priority ...

1) Title Screen ... I'm not 100% on switching this without also switching the other large Japanese title text on the various menu screens ... but it does make a huge immediate change to a player's first impression of the game.

There are already some potential candidates for this that were done a few years ago.

2) Other screen titles ... these are baked into the background tile sets on some screens, and done as overlays on others. That's going to make changing some of them rather hard ... and since a patchwork of translated/untranslated titles would be ugly, I suspect that it's better not to change any of them ... but I'm open to suggestions.


Low Priority ...

We're using 2 custom fonts, 6x13 for the speech, and 8x16 for the menus.

The 8x16 menu font could potentially be changed from a 2 colour font into a 16 color font (or 14 color + background + transparent).

The fonts that it replaces are in 16 colors on some screens, and in 2 colors on others, depending upon whether they're runtime generated from ROM fonts, baked into printable glyphs, or pre-arranged into complete phrases.

I'd need to do some serious palette hacking to get them into 16 colors on all of the different screens.

IMHO ... someone would have to come up with a pretty nice anti-aliased font for it to be worth switching ... but I'm open to trying if someone actually does (that I like enough).

elmer

Translation Details
=============

For anyone that's curious ...

The Zeroigar game CD is split into 51 separate programs on the disc, and getting this far has required finding, figuring out, and patching 38 of them.

Every single screen uses different 'C' code (and often different text storage methods) for displaying stuff on screen.

I'm going to guess that every screen was developed by a different programmer.

These methods (and maybe more) seem to have been used ...

  • Shift-JIS text -> ROM font -> bitmapped text on the screen.
  • Shift-JIS master-glyph-list string -> ROM font -> tiles -> strings stored as indexes into the "master" string.
  • Shift-JIS master-glyph-list string -> ROM font -> tiles -> strings stored as screen maps.
  • Predrawn glyph tiles -> strings stored as indexes into an unknown "master" string.
  • Predrawn glyph tiles -> strings stored as indexes into the screen character set.
  • Predrawn glyph tiles -> strings stored as screen maps.
  • Predrawn phrases as bitmaped tiles -> strings stored as screen maps.
  • Predrawn phrases completely baked into the background tile set.

CrackTiger

It'll be tough to do with English text, some sort of symbols may work better.

Here's a simple stuff I threw together quickly:


IMG

IMG

IMG
Justin the Not-So-Cheery Black/Hack/CrackTiger helped Joshua Jackass, Andrew/Arkhan Dildovich and the DildoPhiles destroy 2 PC Engine groups: one by Aaron Lambert on Facebook, then the other by Aaron Nanto!!! Him and PCE Aarons don't have a good track record together! Both times he blamed the Aarons and their staff in a "Look-what-you-made-us-do?!" manner, never himself nor his deranged/destructive/doxxing toxic turbo troll gang which he covers up for under the "community" euphemism!

elmer

Quote from: guest on 05/09/2015, 09:31 PMIt'll be tough to do with English text, some sort of symbols may work better.

Here's a simple stuff I threw together quickly:
Thanks!  :)

Something simple like that was actually my first "programmer" thought ... which was when I knew that I was in trouble and needed to find an artist!  :wink:

Unfortunately, I think that they'd probably stick out like a sore thumb compared to the italic numbers that they're next to.

It might just be best to go for a large italic "L" and "E" in the same style as the numbers ... but perhaps someone with a better imagination than mine can come up with a better idea.

BTW ... the "Pow" by itself isn't going to work.

It's a power level for the guns (basically 1-8 guns firing), but the bar next to it is your armor level.

They're linked ... but not identical.

When you get hit, they both go down; but while it's easy to get a pickup to raise the gun power back up ... I'm not sure if I've ever seen a pickup that raises the armor level back up.

esteban

Quote from: elmer on 05/09/2015, 04:48 PMTranslation Details
=============

For anyone that's curious ...

The Zeroigar game CD is split into 51 separate programs on the disc, and getting this far has required finding, figuring out, and patching 38 of them.

Every single screen uses different 'C' code (and often different text storage methods) for displaying stuff on screen.

I'm going to guess that every screen was developed by a different programmer.

These methods (and maybe more) seem to have been used ...

  • Shift-JIS text -> ROM font -> bitmapped text on the screen.
  • Shift-JIS master-glyph-list string -> ROM font -> tiles -> strings stored as indexes into the "master" string.
  • Shift-JIS master-glyph-list string -> ROM font -> tiles -> strings stored as screen maps.
  • Predrawn glyph tiles -> strings stored as indexes into an unknown "master" string.
  • Predrawn glyph tiles -> strings stored as indexes into the screen character set.
  • Predrawn glyph tiles -> strings stored as screen maps.
  • Predrawn phrases as bitmaped tiles -> strings stored as screen maps.
  • Predrawn phrases completely baked into the background tile set.
I find this pretty darn interesting.

Clearly, to get the game finished, some tasks were split across several people...what is surprising, to me, is that they did not recycle/reuse the same code/routines when possible. They were "re-inventing the wheel"...simultaneously developing different techniques for achieving similar goals/results...which seems counter-productive.

Anyway, tell me if I am mistaken/over-reaching. :)
IMGIMG IMG  |  IMG  |  IMG IMG

SamIAm

#5
Thanks, HackTiger! Those Lvl and Exp Icons are the very kind of thing I had in mind.

QuoteHigh Priority ...

1) The top 2 icons on the game screen ... 16x16 pixels, 1 color + shadow. They're basically "Level" and "Experience".
2) Bottom left icon on the game screen ... 16x16 pixels, unknown palette (at the moment). There are 8 versions of this representing the 8 levels of gun power.
QuoteIt might just be best to go for a large italic "L" and "E" in the same style as the numbers ... but perhaps someone with a better imagination than mine can come up with a better idea.
I'd really like to have Lvl and Exp in there just because it seems to fly over so many people's heads that there is a level-up system in the game in the first place. I mean, if it looks god-awful, then that's one thing, but if it looks only a little weird, I say go with it. It's worth it to get these factors hammered in.

Quote1) Title Screen ... I'm not 100% on switching this without also switching the other large Japanese title text on the various menu screens ... but it does make a huge immediate change to a player's first impression of the game.

There are already some potential candidates for this that were done a few years ago.

2) Other screen titles ... these are baked into the background tile sets on some screens, and done as overlays on others. That's going to make changing some of them rather hard ... and since a patchwork of translated/untranslated titles would be ugly, I suspect that it's better not to change any of them ... but I'm open to suggestions.
I'd be for swapping out any Japanese with English as long as we can get decent art in there.

IMG

We had some good candidates here (scroll down for more) and here.

Arkhan hosts a nice scan of the background here for would-be photoshoppers.

IMG

AFAIK the title on the title screen and the background are one image. This text, however, is all in a separate layer from the background.

The big red letters, which are 190x46 total or 44x48 individually (elmer will have to say whether they are one image or four separate images), say "select your favorite machine". I'd be fine with reducing this to SHIP SELECT or whatever you think fits nicely...although please run any original ideas by me first.

The white letters say literally "ship one" "ship two" and "ship three". In the translation, I have this as "Type-1" "Type-2" and "Type-3", which I think works better. The letters are 16x16 individually, or 16x48 if you put them all together. Again, elmer will have to tell you about how the tiles work. I think we'll be able to make most anything work, though.

The red character is the same "Lvl" that you see in the main game.

IMG

Finally, there's this, from the Trial Mode. Don't worry about the stuff in the lower half, because that's elmer's final hacking task. The big red letters simply say "Trial Mode", but it seems that like the title screen, they are baked into the image.

While we don't have as clean a version of the background as exists in the scan from Arkhan, we do have this, from an FMV:

IMG

Make of it what you will. I suppose the best thing to do would be to use this to redraw little pieces that the "Trial Mode" letters cover up.

Hey elmer, do you think it would be easy to swap these backgrounds with any old image, or are palettes going to complicate things?

QuoteLow Priority ...

We're using 2 custom fonts, 6x13 for the speech, and 8x16 for the menus.

The 8x16 menu font could potentially be changed from a 2 colour font into a 16 color font (or 14 color + background + transparent).

The fonts that it replaces are in 16 colors on some screens, and in 2 colors on others, depending upon whether they're runtime generated from ROM fonts, baked into printable glyphs, or pre-arranged into complete phrases.

I'd need to do some serious palette hacking to get them into 16 colors on all of the different screens.

IMHO ... someone would have to come up with a pretty nice anti-aliased font for it to be worth switching ... but I'm open to trying if someone actually does (that I like enough).
That's cool. I do think the current font looks pretty good, though. :)

CrackTiger

This is the only other way I can think of to pull them off within 16 pixels.

IMG

IMG
Justin the Not-So-Cheery Black/Hack/CrackTiger helped Joshua Jackass, Andrew/Arkhan Dildovich and the DildoPhiles destroy 2 PC Engine groups: one by Aaron Lambert on Facebook, then the other by Aaron Nanto!!! Him and PCE Aarons don't have a good track record together! Both times he blamed the Aarons and their staff in a "Look-what-you-made-us-do?!" manner, never himself nor his deranged/destructive/doxxing toxic turbo troll gang which he covers up for under the "community" euphemism!

esteban

Quote from: guest on 05/10/2015, 10:34 AMThis is the only other way I can think of to pull them off within 16 pixels.

IMG

IMG
I definitely prefer this design over Round 1!
IMGIMG IMG  |  IMG  |  IMG IMG

elmer

Quote from: esteban on 05/10/2015, 07:07 AMI find this pretty darn interesting.

Clearly, to get the game finished, some tasks were split across several people...what is surprising, to me, is that they did not recycle/reuse the same code/routines when possible. They were "re-inventing the wheel"...simultaneously developing different techniques for achieving similar goals/results...which seems counter-productive.

Anyway, tell me if I am mistaken/over-reaching. :)
As far as I can tell, you're neither mistaken, nor over-reaching ... but if I ever get passed my annoyance at the pointless duplication of effort in finding/patching all the different occurences ... I can see good reasons for at least some of the variations.

The game basically boots a small (<32KB) "master control" program, and then does all the real work in the separate "overlay" programs that it loads one at a time as needed.

The only communication between the 2 systems is by a small set of variables (player level, score, weapons, etc).

So, once you've decided to follow that program architecture (rather than having a single program and just loading data-only overlays) ... then you've already thrown away most of the opportunities for binary code reuse.

FYI ... 'C' compilers in the early-to-mid 90's didn't have easy ways to write statically-linked program overlays (afaik, they didn't appear until the PS2 generation) ... so completely separate programs made some sort of sense.

It does look like there is at least some reuse of source code ... but there's not a lot of it done as shared-per-overlay routines, most of it seems to be cut-n-pasted into the source file(s) that make up each screen, either as a subroutine, or inline into the huge functions that make up a single screen.

You only have to look at the different styles of the various menu screens to see that they were done by different people ... there is very little consistency across the front end.

If you look at each screen as a separate mini-project, then each of them uses a perfectly resonable choice for drawing the background & text ... even given the same set of company-wide-utility-tools that they probably had available.

Since each section is a different overlay program, they didn't have to be efficient ... and so they weren't.

Now ... in a Western project of that time period, you'd probably only have 1 programmer and 1 artist doing all the front end and HUD work ... and so you'd generally get a lot more re-use and consistency.

SamIAm

#9
The forum just ate a big post I typed up just because I went to bed in the middle of it.  ](*,)  :-({|=

I think the LV and XP are all right, but tell me if you agree with me on this: I think almost everyone who sees Lvl and Exp is going to think "level" and "experience" no matter what, but LV and XP are going to have a somewhat lower success ratio. Remember, this is a shooter, and people aren't expecting a level-up system. I'd like to see if Lvl and Exp are workable first.

Anyway, I left out a couple of things before.

IMG

This is essentially the Game Over/Continue screen. If you see it in the game, you'll notice that the Yes and No fade back and forth with the Japanese in the background. I don't think that needs to be changed, and I also think that this means you can superimpose new English text over the other stuff just using the opposite color - white over red and red over white. It beats trying to clean the Japanese out of the image.

The red characters 無念 make a word that appears often in games, but doesn't translate well to English, if you're curious. It comes from Buddhism originally, and those of you who can read the individual characters will understand its old meaning: a state of mind free from attachments and desire. But the meaning has changed a lot over the years, and now it's kind of a stoic way to express regret or chagrin. It's almost like "What a pity" or "How embarrassing". In the context of the game, I think a big "Defeated" would have the same impact. "A sad end..." would work. "A fall from grace" would be a stretch. "Game Over" would be a reasonable compromise. Whatever fits. I suspect "Game Over" would cover the Japanese nicely. Or, you could take a liberty with "Shot Down".

Below that, the white text says literally (and much more simply) "Can you still fight?". I think that will work fine. If it's too long, "Continue?" would work.

The other ships in Normal Mode and Sakuraigar have their own Game Over screens, but whatever you make for this can be copy/pasted onto those. Just make sure you save a separate layer.

Please forgive the big image.
IMG

1, 2, 3, 4, 5, 6, 7, 8 appears as 一、二、三、四、五、六、七、八, in that order. That's really the only thing that needs doing. It looks like including the white border, these are 16x16 blocks.

Is there anything else I'm forgetting? I think that that's all of it.

elmer

#10
Quote
QuoteIMHO ... someone would have to come up with a pretty nice anti-aliased font for it to be worth switching ... but I'm open to trying if someone actually does (that I like enough).
That's cool. I do think the current font looks pretty good, though. :)
Thanks! It's about as good as I can do in a 1-bpp font with a 1-bpp dynamically-generated drop-shadow.

But to my eye ... it looks very 4th-generation ... clean and simple, with nice square pixel edges.

IMHO ... the 5th generation machines were when developers started routinely anti-aliasing the menu system fonts.

You can see that the Zeroigar developers tried to do that on some screens ... like on the Main Menu ... but didn't try at all on others ... like the end-of-level "repair" screen.

Even when they did do it ... it looks like the font is anti-aliased against a black or grey backgound, rather than being anti-aliased against the image that it's really on, which leaves it looking like it has a messy halo.

This is a limitation of the PC-FX hardware which doesn't offer either per-pixel or paletted alpha on the sprite/background layers.

That is one of the big advantages of using a frame-buffer system like the PlayStation where the final image is composited at draw-time rather than display-time.

Anyway ... that's probably way-too-much-information for most people's interest!

NightWolve

Quote from: elmer on 05/10/2015, 07:12 PMAnyway ... that's probably way-too-much-information for most people's interest!
Not at all, it's cool to see more fan localizers that really know what they're doing on the level of say folks like Bonkuts, EsperKnight, etc.

elmer

#12
QuoteI'd really like to have Lvl and Exp in there just because it seems to fly over so many people's heads that there is a level-up system in the game in the first place. I mean, if it looks god-awful, then that's one thing, but if it looks only a little weird, I say go with it. It's worth it to get these factors hammered in.
QuoteI think the LV and XP are all right, but tell me if you agree with me on this: I think almost everyone who sees Lvl and Exp is going to think "level" and "experience" no matter what, but LV and XP are going to have a somewhat lower success ratio. Remember, this is a shooter, and people aren't expecting a level-up system. I'd like to see if Lvl and Exp are workable first.
Yes, boss!  :wink:

You're right, understanding that is vital to getting how to play the game ...

So ... seriously ... if you really want that hammered in , and if we can't come up with something "artistically-beautiful" ... then I can just use the 8x16 menu font to write in "Lvl" and "Exp".

It will mean moving the numbers over by a few characters, but it's possible. It'll probably only be another 175 patches to put in (2 icons and 2 numbers at screen setup, 1 number during screen update - all times 35 levels).

Heck ... if I'm going that far, we can make them 32x16 graphics and do them as thick italics to match the numbers ... or just switch the numbers to the menu font.


IMG
QuoteAFAIK the title on the title screen and the background are one image. This text, however, is all in a separate layer from the background.
I think that I may have originally told you that, but I was wrong. The guys that did this particular screen did it as 2 layers, foreground and background, but each layer is a complete tileset/tilemap. So the big red letters are not pre-composited into the background ... but neither are they easily editable in-place. It would mean converting the foreground layer into a bitmap, changing it, and then reconverting it to a tilemap (using the same number of tiles).

After thinking about this screen a bit more ... I can just draw the font text into the existing tileset and modify the screen before it is displayed to get the "Type-1" and "Lvl" ... and basically treat it somewhat like the other screens, but modify it in RAM instead of in VRAM.

BTW ... this is one of the 2 front end screens that I can think of that puts "foreground" text into a King background (new PC-FX chip) instead of a VDC background (old PCE chip).


IMG
QuoteFinally, there's this, from the Trial Mode. Don't worry about the stuff in the lower half, because that's elmer's final hacking task.
Hahaha ... well, it's the last one for functional English menus, anyway!  :wink:

QuoteThe big red letters simply say "Trial Mode", but it seems that like the title screen, they are baked into the image.
Yep, this time they're baked into a King background. The menu is in a VDC background as normal.


IMG
QuoteThis is essentially the Game Over/Continue screen. If you see it in the game, you'll notice that the Yes and No fade back and forth with the Japanese in the background. I don't think that needs to be changed, and I also think that this means you can superimpose new English text over the other stuff just using the opposite color - white over red and red over white.
Just like the "Ship Select" screen, this one uses a foreground layer and a background layer that are both in King background memory.

Even though it's a pre-converted tileset/tilemap, there's enough space in there that I can replace the "Continue?" with any reasonable English phrase using a method similar to the "Ship/Pilot Select" screen.

There's one more screen that we've missed talking about ... the "Trial Mode" result screen (screenshot below) ... that's all in a VDC background ... and the big Japanese text is done as 2 128x64 bitmaps which would be relatively easy to change.

But, purely in my own opinion, and this applies to all of the screens ... once the menu itself is in understandable English, I really don't care if the menu's title is in English or Japanese.

It's always easy to work out what is going on ... and the Japanese kanji are often beautiful to look at.

Those kanji often express complex ideas that it takes a lot of roman characters to express in the English language ... I think that we'll have a hard time coming up with replacement graphics on a lot of these screens that looks as nice in the same memory footprint.

It's the memory that going to be the biggest problem ... I don't have anywhere near enough space in the area that I'm using for the current patches to store new graphics.
Anything would have to fit into the same space as the current graphics.

[EDIT]
Wow ... lots of typos to fix in that one!

elmer

Now that the in-game icons have been modified in Zeroigar, I thought that some people might be interested in what that seemingly-simple task actually required.

For anyone not familiar with Zeroigar ... the task is swapping out the original Japanese in-game 16x16 icons with new 24x16 "Lvl" and "Exp" icons, and new understandable 16x16 "Gun Power" icons.

As I've posted before, the game CD actually contains 35 different versions of the game program, 1 for each game-mode and difficulty setting.

For every single one of those versions, that means ...
  • Modifying where the top of the "Lvl" icon is drawn.
  • Modifying where the bottom of the "Lvl" icon is drawn.
  • Modifying where the "Lvl" number is drawn.
  • Modifying where the top of the "Exp" icon is drawn.
  • Modifying where the bottom of the "Exp" icon is drawn.
  • Modifying where the "Exp" number is drawn.
  • Modifying where the "Exp" number is drawn when it is updated.
  • Modifying where the "Exp" number is drawn when you pick up a bonus.
  • Adding new graphics for the "Lvl" icon.
  • Adding new graphics for the "Exp" icon.
  • Adding new graphics for the gun power icons.
Actually drawing the new bigger 24x16 "Lvl" and "Exp" icons instead of the old 16x16 icons is accomplished with one small new piece of code ... but to get it in there and working requires modifying the 35 different versions of the game with a total of 487 different patches in 347 different locations.

Don't forget ... all those locations had to be found and the code analysed in the first place before they could be patched.

So ... if you ever wonder why translations take so long, and sometimes get stalled or abandoned after an initial spurt of activity ... here's one example of how something that seems "simple", often isn't.

esteban

IMGIMG IMG  |  IMG  |  IMG IMG

NecroPhile

Ultimate Forum Bully/Thief/Saboteur/Clone Warrior! BURN IN HELL NECROPHUCK!!!

elmer

Anyone that's played the game might know that you can use the "III" button as an alternative to the "RUN" button to bring up the Weapon Select menu.

But have you tried pressing "III" when you're already holding down the "SEL" button?

Whoops ... bug!!!  [-X

Well ... it'll be fixed in the translation.

esteban

Quote from: elmer on 05/30/2015, 03:42 PMAnyone that's played the game might know that you can use the "III" button as an alternative to the "RUN" button to bring up the Weapon Select menu.

But have you tried pressing "III" when you're already holding down the "SEL" button?

Whoops ... bug!!!  [-X

Well ... it'll be fixed in the translation.
Does it reset the game?

Forgive my ignorance.
IMGIMG IMG  |  IMG  |  IMG IMG

elmer

Quote from: esteban on 05/30/2015, 04:40 PMDoes it reset the game?

Forgive my ignorance.
Good guess! That would have been an easy mistake for them to have made.

Nope ... it pauses the game, but it doesn't bring up the Weapon Select menu ... and the music stops loading and just starts looping the last couple of seconds of sound.

When you un-pause, which has to be with the "RUN" button and not the "III" button, you've got a 60/40 chance that the music is then trashed for the rest of the level (or until you die or a voice-over is played).

I'm guessing that it's the remains of a debug menu that they didn't fully flush out of the production CD.

elmer

#19
Here's a little tale for anyone that finds this kind of thing interesting ...

I develop/test in Mednafen and have only very recently started burning CDs.

For a while now, SamIAm has been seeing a rare problem with the subtitled videos that I'd never been able to see.

The original videos contain a 16-pixel high very-dark-grey border at top and bottom of the picture.

For the new videos, he's moved the original picture up by 16-pixels, and created a 32-pixel high space at the bottom of the picture for the subtitles.

The subtitles are then drawn in yellow text on a black background.

Now, this looks great, and works perfectly 99.9% of the time.

But, once-in-a-blue-moon ... something strange happens and the border of the subtitles (where there is no text) turn from black into medium-grey ... and then stay that way for the entire video.

This does not happen with the original videos, it does not happen with the new videos in Mednafen, and it only happens very rarely on a real PC-FX ... but if you stay in the Main Menu for long enough, then it will eventually happen.

Well, it took a couple of days to track down, but here's what happens (in somewhat technical detail).

The M-JPEG video chip that's in the PC-FX has a shortcut where 16x16 blocks of a video frame that are completely in a single color (usually black) can be encoded in a really, really short and efficient form.

Now, the original videos use dark-grey borders, so they never contain any of these specially-encoded blocks.

But, in the new subtitled videos, they're extremely common and surround all the yellow text of the subtitles.

The M-JPEG video chip can actually display any of these specially-encoded blocks in any color ... the color that is displayed is actually set by the game itself. This can be useful for doing things like green-screen chroma-key transparency.

So ...

1) The PC-FX is turned on, and the video-chip is reset ... this sets the color that these special-blocks display to "medium-grey".

2) The Zeroigar game starts up, and it sets the color to "black".

3) The game starts to play a video, and it resets the video chip again before playback.

4) The video is played.

Now ... the "bug" is in step 3 ... there needs to be a delay when you reset the chip; and the Zeroigar developer that wrote the code that resets the chip before a video is played didn't put one in.

So, 99.9% of the time the chip doesn't actually "reset", and the special-blocks are displayed in the "black" color that the game sets when it starts up.

But once-in-a-blue-moon, the chip actually does "reset", and that sets the color back to "medium-grey".

The original videos never use these special-blocks, so you don't see anything wrong when you're using them.

Mednafen doesn't set the color to "medium-grey" when it emulates the chip reset, so you never see anything wrong in Mednafen, with either the old or the new videos.

But, on a real PC-FX, you've suddenly got subtitles that are surrounded by ugly grey blocks.

Whoops!  :oops:

The lesson here for developers is ... always RTFM!  #-o

BTW ... the code that resets the chip at the start of the game does contain the proper delay ... so this is just another case of too-many-cooks.

[EDIT]

Added screenshots.

IMG

SamIAm

I can't tell you how pleased I am with the way things are shaping up. The end product is going to be very nice, you guys. I'll save my gushing for the release, but elmer is an absolutely fantastic hacker/programmer.

elmer

For anyone that's curious for an example of how the contents of a game CD are layed out on the disc, here's what I've found out about Zeroigar ...

//
// 51 code segments on CD - 42 code segments patched.
//
// PC-FX Boot   at iso 0x00000000   // Boot Info / License Info
// Startup code at iso 0x00001000 x // Boot Loader
// Startup code at iso 0x00009000 x // Main Front End
// Startup code at iso 0x00051000   // NEC & Studio Boot Screens
// Startup code at iso 0x00056000   // Art Design Slideshow - Part 1
// Startup code at iso 0x00093800   // Art Design Slideshow - Part 2
// Startup code at iso 0x00126800   // Sakurigar Mode Static Level Name Screen
//
// Video 0 data at iso 0x00129000 x // Video (1871 frames) : Story Introduction
// Video 1 data at iso 0x02129000 x // Video (1752 frames) : Before Anime Level 1
// Video 2 data at iso 0x041ea800 x // Video (1042 frames) : Title Song
// Video 3 data at iso 0x0558d000 x // Video ( 999 frames) : Middle Anime Level 1
// Video 4 data at iso 0x0697f000 x // Video ( 467 frames) : Before Anime Level 2
// Video 5 data at iso 0x0729b000 x // Video ( 399 frames) : Before Anime Level 3
// Video 6 data at iso 0x07952800 x // Video ( 596 frames) : Before Anime Level 4
// Video 7 data at iso 0x0823b000 x // Video ( 388 frames) : Before Anime Level 5
// Video 8 data at iso 0x08934000 x // Video ( 376 frames) : Before Anime Level 6
// Video 9 data at iso 0x090be800 x // Video ( 591 frames) : Before Anime Level 7
// Video A data at iso 0x09b84800 x // Video (2133 frames) : You Beat the Boss!
// Video B data at iso 0x0bd43800 x // Video ( 568 frames) : After Credits
// Video C data at iso 0x0c85b800 x // Video ( 183 frames) : Type-A Launching
// Video D data at iso 0x0cbb7000 x // Video ( 176 frames) : Type-B Launching
// Video E data at iso 0x0ceb1800 x // Video ( 177 frames) : Type-C Launching
// Video F data at iso 0x0d257000 x // Video ( 243 frames) : Sakuraigar Launching
//
// Adpcm ? data at iso 0x0d6a1800   // Start of audio data
//
// Startup code at iso 0x12566000 x // ADPCM Music Test Mode
// Startup code at iso 0x12596000   // Huge Text Printing Level Name Screen
// Startup code at iso 0x125a6000 x // Play Anime Level Intro video
// Startup code at iso 0x125aa000 x // Anime Mode, Level 3 (normal difficulty)
// Startup code at iso 0x126aa000 x // Anime Mode, Level 1 (normal difficulty)
// Startup code at iso 0x127aa000 x // Anime Mode, Level 4 (normal difficulty)
// Startup code at iso 0x128aa000 x // Anime Mode, Level 5 (normal difficulty)
// Startup code at iso 0x129ca000 x // Anime Mode, Level 6 (normal difficulty)
// Startup code at iso 0x12b0a000 x // Anime Mode, Level 7 (normal difficulty)
// Startup code at iso 0x138ba000 x // Play Sakurigar Level Intro Slideshow
// Startup code at iso 0x1393a000 x // Normal Mode Front End (between levels)
// Startup code at iso 0x13982000   // Art Design Slideshow - Part 3
// Startup code at iso 0x139ea000 x // Trial Mode (contains front end graphics)
// Startup code at iso 0x13aca000 x // Anime Mode, Level 1 (low difficulty)
// Startup code at iso 0x13bca000 x // Anime Mode, Level 2 (low difficulty)
// Startup code at iso 0x13cca000 x // Anime Mode, Level 3 (low difficulty)
// Startup code at iso 0x13dca000 x // Anime Mode, Level 4 (low difficulty)
// Startup code at iso 0x13eca000 x // Anime Mode, Level 5 (low difficulty)
// Startup code at iso 0x13fea000 x // Anime Mode, Level 6 (low difficulty)
// Startup code at iso 0x1412a000 x // Anime Mode, Level 7 (low difficulty)
// Startup code at iso 0x1428a000 x // Anime Mode, Level 1 (high difficulty)
// Startup code at iso 0x1438a000 x // Anime Mode, Level 2 (high difficulty)
// Startup code at iso 0x1448a000 x // Anime Mode, Level 3 (high difficulty)
// Startup code at iso 0x1458a000 x // Anime Mode, Level 4 (high difficulty)
// Startup code at iso 0x1468a000 x // Anime Mode, Level 5 (high difficulty)
// Startup code at iso 0x147aa000 x // Anime Mode, Level 6 (high difficulty)
// Startup code at iso 0x148ea000 x // Anime Mode, Level 7 (high difficulty)
// Startup code at iso 0x14a4a000 x // Play End-of-Game Video
// Startup code at iso 0x14b1a000   // Play End-of-Game Credits
// Startup code at iso 0x14bea000 x // Anime Mode, Level 2 (normal difficulty)
// Startup code at iso 0x14d2a000 x // Normal Mode, Level 2 (no level 1)
// Startup code at iso 0x14e2a000 x // Normal Mode, Level 3
// Startup code at iso 0x14f2a000 x // Normal Mode, Level 4
// Startup code at iso 0x1502a000 x // Normal Mode, Level 5
// Startup code at iso 0x1512a000 x // Normal Mode, Level 6
// Startup code at iso 0x1522a000 x // Normal Mode, Level 7
// Startup code at iso 0x1532a000 x // Sakurigar Mode, Level 1
// Startup code at iso 0x1542a000 x // Sakurigar Mode, Level 2
// Startup code at iso 0x1554a000 x // Sakurigar Mode, Level 3
// Startup code at iso 0x1566a000 x // Sakurigar Mode, Level 4
// Startup code at iso 0x1578a000 x // Sakurigar Mode, Level 5
// Startup code at iso 0x158aa000 x // Sakurigar Mode, Level 6
// Startup code at iso 0x15a2a000 x // Sakurigar Mode, Level 7
// Startup code at iso 0x15bd7800   // Art Design Slideshow - Part 4
// Startup code at iso 0x15c46000   // Art Design Slideshow - Part 4 (again?)
//
// END OF ISO   at iso 0x15cff800   // END OF ISO
//

SamIAm

#22
Elmer is off for a few days. After the work he's put in, he certainly deserves a break. Though he'll probably want to weigh in later with his programmer's perspective, you might like to know what's going on now.

The in-game text, the in-game icons, the menus, the title screen, the continue screen, the post-death/stage-clear screen...all of that is basically in its final form, fully translated. We spent a while settling on a color for the in-game text, and I played through the game again and again to polish the display timings. It's all looking very slick.

Now, we are focusing on optimising the FMVs for quality.

-----

The process of subtitling the FMVs has always looked something like this:

1. Convert FMV files ripped directly from the game to lossless AVI. Audio is lost at this stage for whatever reason. We used tools made by some Japanese guy to do this.

2. Cut off the 16 pixel tall black-ish borders at top and bottom, apply a 32 pixel pure black strip to bottom, apply subtitles over that, and output to AVI again.

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.

4. Merge the audio from original rips with the .mix files produced by MPCONV2, sprinkle additional formatting fairy dust, and insert into the game.

The big deal is stage 3, where we convert the subtitled AVIs to MIX. Allow me to talk about MPCONV2 for a moment. This tool is very limited...almost as if it wasn't made with real developers in mind...and when it comes to quality, it only allows you to specify a ceiling for the data rate of the FMVs. For example, you could set it at 200KB/s, and the data rate would never exceed that as it plays the entire video.

Alternatively, 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.

-----

The PC-FX has a 300KB/s rated drive, and so until recently I had been encoding the videos with a 295KB/s ceiling (for peace of mind). Basically, this output looks very good. However, there are three problems:

1. There is a minor drop in overall quality due to lossy-encoding. Of course, the source is also lossy, but we inevitably loose just a little bit more quality on top of that. This could be alleviated somewhat if we had a higher data rate ceiling.

2. The subtitles, which are yellow, occasionally have some blue dots appear around them. They're still easy to read, but the effect is distracting. This is merely another case of compression artifacts, and its caused by moments when the video image needs an unusually large share of the bandwidth.

3. In areas with lots of black, compression artifacts can be particularly bad, and occasionally outright hideous.

About #3 - MPCONV2 gets a little overzealous with black, and occasionally it assigns black areas a special kind of 16x16 pixel pure-black block that is super-efficient in terms of data compression but god awful in terms of visual appeal. In these areas, I have been creative with video editing, introducing white fades or otherwise slightly brightening all the frames between visual cuts. Most of these additions you won't even notice, and it solves the problem satisfactorily. However, there is a slight chance that MPCONV2 could be hacked so as to never use these blocks, which would be sweet.

Please don't panic when you see that video, though. There are very few instances of this problem in the game. That one is by far the worst, and I've covered everything up pretty nicely.

-----

But now, the Big News. About a week ago, elmer made a fantastic tool that lets us look at data rates on a per-frame and per-second basis within each .mix file. This has led to many fascinating discoveries.

1. Encoded at 300KB/s, anywhere from 40-80% of the video content is actually sub-250KB/s depending on the specific FMV. It will only rise to the ceiling at certain peaks.

2. Even when encoded at the ceiling-less Quality=0 setting, the majority of the video content is still sub-300KB/s, and only a couple of seconds in all of the game's FMVs combined exceed 350KB/s.

3. Additionally, we also discovered in short order that the PC-FX is using a buffer when it streams the videos, and it can actually handle brief spikes over 300KB/s. I have tested this on real hardware. The size of the spikes it can handle would surprise you.

The result of all this is that we have a couple of interesting potential methods of improving the quality of our subtitled FMV.

One thing that I tried was to encode a video in two versions: one at 300KB/s and the other at Quality=0. Breaking down the two files into individual frames, I erased certain large frames from the Quality=0 version and replaced them with frames from the 300KB/s version. This produced something that looked very sigificantly improved, worked on real hardware, and was easy to make.

(Keep in mind that since the PC-FX's playback is JPEG based, every frame is stored completely. You couldn't do this with an MPEG format).

---------

HOWEVER...elmer has also come up with a whole other method which appears to work well.

Go alllll the way back to the beginning. You rip the FMV files from the game, you convert them to lossles AVI. Here's where things take a turn.

If you never apply the subtitles to the AVIs, and stop after having the video moved 16 pixels up and applying a 32 pixel black strip to the bottom, they compress into MIX much better. If you compare sizes of no-subs MIX output files, there is almost no difference between the ceilingless Quality=0 setting and a 300KB/s-ceiling setting (for the files I have reviewed so far, anyway).

Elmer found out something cool. I don't have a firm grasp on the technical details, but it seems you can effectively have the HuC6271 display two JPEGs at once. What we can do is to encode the video and the subtitles separately with MPCONV2, initially outputting individual files for each, then merging them into one so that they are both displayed simultanously. The result on screen is identical at a glance, but this method lets us encode the subtitles in a way that they are always flawless regardless of how busy the video image is.

However, the question here is whether the subtitles and the video can balance out nicely. If we have to drop the quality of the video to make room for the subs, then that might not be cool. If we have to lower to quality of the subs to the point that artifacts start appearing, then it's kind of pointless.

I have a lot of work to do to test this.

-----

So, we have two methods of improving the FMVs to choose from at the moment:

1. Comb high-quality, >300KB/s versions of MPCONV2 output for better frames that will still fit within buffer tolerances.

In short, the advantage of this method is that there's a natural balance between the video and the subtitles. Artifacts around the subtitles will only appear at peak moments when the image itself demands more of the data. The disadvantage, of course, is that any artifacts around the subtitles look bad.

2. Encode the subtitles separately from the video, then combine them.

The advantage of this method is that we can force the subtitles to always look clean. The disadvantage of it is that the clean subs might come at the cost of the quality of the video, though again, this would be only for brief moments, and would probably be very minor.

I am actually inclined to go with option #2, as long as the subs can be totally clean and the video not compromised beyond a negligable degree.

----

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.

2. Write an entirely new compressor that encodes video in multiple passes and generally does things smarter and better than MPCONV2.

These things are complicated and challenging enough that we might wait and put out a "remastered" version sometime later.

----

Anyway, this is what I have been doing with myself for the past week or two. If you're wondering why Zeroigar is taking so long even though we've had the basic stuff done for so long, it's because getting it to look as good as it possibly can takes a while. I'm just grateful to elmer for going the extra mile with me.  :D

esteban

#23
Do you have to shift video 16 pixels up?

I was thinking: keep existence video, as-is,  but display subtitles on bottom of screen (thereby overlapping video by 16 pixels). Black outline around yellow/ white text usually accounts for any conflict with video content.

It is not elegant, but it saves a lot of work. :)
IMGIMG IMG  |  IMG  |  IMG IMG

SamIAm

Quote from: esteban on 06/19/2015, 07:03 AMDo you have to shift video 16 pixels up?

I was thinking: keep existence video, as-is,  but display subtitles on bottom of screen (thereby overlapping video by 16 pixels). Black outline around yellow/ white text usually accounts for any conflict with video content.

It is not elegant, but it saves a lot of work. :)
For that to work, we would have to re-encode the entire bottom 16 pixel row of the video where the first row of subtitles would overlap. If we did that, line between the original video and the recoded video would probably be visible, and the quality between the two would be inconsistent.

Plus, the black-ish borders in the original videos are fuzzy with dark-grey compression artifacts that look like black borders from a super low-quality VHS tape. I'd hate to leave just one, and I'd hate to put subtitles over the other, so it's a no-win situation.

The re-encoded videos with the new pure-black 32 pixel border at the bottom look really good, if I do say so myself. There really isn't as much quality loss as you would expect (thank god this isn't MPEG), and even the 295KB/s videos preserve most of the quality of the originals. The current battle is just about squeezing every last drop of quality we can.  :D

spenoza

Was this game released on any other platform at all? Is there any higher-quality source for the videos to maybe re-encode?

SamIAm

Quote from: guest on 06/19/2015, 07:46 PMWas this game released on any other platform at all? Is there any higher-quality source for the videos to maybe re-encode?
Nope. It's a PC-FX exclusive.

SamIAm

#27
I'm sorry, you guys, I was totally wrong about encoding in Quality=0 having that "rising tide" effect on certain small frames. You know, improving them but leaving them within the data rate limit of a 300KB/s-ceiling file.

What actually happens in that enabling Quality=0 allows for some frames to leap dramatically in quality. For example, if the frame-size limit of a 300KB/s file is 25KB, and a certain frame within that is 17KB, you wouldn't expect that it has room to improve. Lo and behold, however, that if you remove the size limit altogether, it might rocket up to 27KB. That's what confused me.

I edited that big post I made.

esteban

IMGIMG IMG  |  IMG  |  IMG IMG

elmer

I'm looking forward to seeing the results of the experiments when I get back.  :)

From what I tried, "high quality" + separate subtitles gave really good results with much smaller spikes in the data rate than "high quality everything" ... it'll be interesting to see if that holds for some of the more difficult videos.

SamIAm

#30
GREAT news, you guys.

Remember this?

Quote3. 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

IMGIMG IMG  |  IMG  |  IMG IMG

dshadoff

Quote from: SamIAm on 06/25/2015, 01:24 AMThe 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

Quote from: dshadoff on 06/25/2015, 08:16 PMI 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.

https://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.


Quote from: dshadoff on 06/25/2015, 08:16 PMSo, 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 ...

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

Quote from: SamIAm on 06/18/2015, 11:37 PMAnd 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.  :D

This gives us a couple of benefits ...
  • There is absolutely no loss in video quality.
  • The files with the Q0-encoded subtitles are slightly smaller than the Q0-encoded all-in-one files.
  • The translation patch will be much, much, much smaller, and won't need to include any of the original copyrighted game content.
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!  :wink:

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.

Quote from: elmer on 06/26/2015, 01:20 PMUnfortunately, 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.

https://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

Quote from: SamIAm on 06/26/2015, 07:11 PMOne 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.


QuoteI'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

Quote from: elmer on 06/27/2015, 06:43 PMThe 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.

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+++ +++ +++ +++ +++ +++ +++ +++ ---


IMG

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

Quote from: dshadoff on 07/04/2015, 07:24 AMI 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.


NightWolve

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

elmer

Quote from: NightWolve on 08/26/2015, 12:45 AMHuh, 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. :D

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

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

NightWolve

Quote from: elmer on 08/26/2015, 12:56 AMI enjoyed the commentard that was so down on us pirating the game ... such a brainiac!  #-o
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


NightWolve

Quote from: elmer on 08/26/2015, 11:12 AM
Quote from: ParanoiaDragon on 08/26/2015, 12:16 AMMade 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!  :D
But, but, but piracy!!!!! Are you SURE all 40 own an original copy or will they seek a download ??  :mrgreen:

elmer

Quote from: NightWolve on 08/26/2015, 01:51 PM
Quote from: elmer on 08/26/2015, 11:12 AMLooks like there's been 40 downloads of the patch since that article went up yesterday ... not bad!  :D
But, but, but piracy!!!!! Are you SURE all 40 own an original copy or will they seek a download ??  :mrgreen:
I'm sure that most of them are just looking forward to buying an official "original" copy from PCEWorks when Tobias releases a box-set of translated PC-FX games!  :wink:

Gredler

Quote from: elmer on 08/26/2015, 02:17 PM
Quote from: NightWolve on 08/26/2015, 01:51 PM
Quote from: elmer on 08/26/2015, 11:12 AMLooks like there's been 40 downloads of the patch since that article went up yesterday ... not bad!  :D
But, but, but piracy!!!!! Are you SURE all 40 own an original copy or will they seek a download ??  :mrgreen:
I'm sure that most of them are just looking forward to buying an official "original" copy from PCEWorks when Tobias releases a box-set of translated PC-FX games!  :wink:
For the love of it

NecroPhile

There's been an awful lot of downloads for ze patch.  Unless most of 'em are playing it in mednefen, where the heck are all these PC-FX owners?
Ultimate Forum Bully/Thief/Saboteur/Clone Warrior! BURN IN HELL NECROPHUCK!!!

o.pwuaioc

Quote from: NecroPhile on 08/26/2015, 03:14 PMThere's been an awful lot of downloads for ze patch.  Unless most of 'em are playing it in mednefen, where the heck are all these PC-FX owners?
I think some people download something for the sake of downloading it...