xdaniel's Random Junk

[xdaniel]

Taking a break from coding and Zelda hacking, I'm back at what I'd probably call my origins - translation hacking:

 

 

You might recognize what this is if you're from either Japan, I believe Singapore or the Philippines, Australia or Germany. Don't think any other countries ever got the anime the game's based on.

 

Anyway, this is more or less the extend of my work so far; the copyrights and title menu, options screen and some other file (containing those blue tags in the corner and some battle text). All in-game dialogue is stored as images as well, which isn't exactly helpful for dumping and reinsertion, but I'll be focusing on menus and such first anyway...

[xdaniel]

Yeah, not much interest in simple, boring translation hacking, not to mention for an obscure game based on an obscure anime

 

Anyway, not much to say about the translation, but I started writing a little tool to help with data extraction, conversion and insertion. So far it's capable of extracting files from the CD's file system, capable of loading data from the game's CGEAR.DAT/CGEAR.DIR pair (a virtual FS; think Zelda's DMA table, just with one file containing the table, and another with the data) and capable of displaying 4-bit and 8-bit CI TIM images. No editing capabilities whatsoever yet, but I'll get there at some point.

 

[Malqua]

Looks good, bro. What languages do you translate?

[xdaniel]

Well, I know German (of course), English and a tiny bit of Japanese - enough for menus and system messages, but not for character dialog and such, tho. So I guess I can translate between those to an extend.

 

Edit:

 

 

In-program TIM extraction and replacement, using proper 8-bit palletized PNGs even. Works very well, even with multiple palettes per TIM, multiple definitions of the same color, etc.

 

Still need to implement saving, tho...

Edited July 28, 2011 by xdaniel

[xdaniel]

 

CD image support is out because using the DiscUtils library, I would've had to rebuild the whole image to modify a single file inside it. Reading and extracting from an existing image is perfectly simple, but replacing a file is impossible. So yeah, now the program's "only" capable of editing CGEAR.DAT's virtual file system anymore, although that's where the bulk of data that requires translation is anyway, thus no big loss there.

 

All the bad news out of the way, the good news:

 

- With removing CD image support, I was able to simplify the code quite a bit, making it a bit easier to manage for one

- The TIM manager has been improved and now spits out and imports 8-bit and 4-bit palletized images

- The GUI now also gives a nice little palette preview and exports a Paint Shop Pro-compatible palette file

- The file list now has user-editable descriptions that get stored in an external XML file

 

And with that, unless I find some serious bugs, actual translation work shall commence again~

 

Edit: ...like so:

 

 

Edit 2: ...and so:

 

 

Working with actual TTF fonts instead of writing graphical text (more or less) pixel-by-pixel, using custom-drawn pixel fonts, is quite a new experience for me. The only thing I've actually done using a custom pixel font here, is the "Dash Attack", "Dash Guard", etc. text in the screenshot of the 1P Customize screen above; everything else is Arial or other fonts.

Edited August 2, 2011 by xdaniel

[xdaniel]

Seeing how I'm coding so much in C# these days, trying out XNA wasn't much of a stretch...

 

 

Initially, I was just following along with XNA Resources' shoot'em up tutorial, but ended up deviating from it in several aspects, and implementing some features and ideas that weren't part of the tutorial - to be exact, support for multiple background layers with parallax scrolling at different speeds, automatic scroll speed changing at specific level positions, and a simple color fading class used for a kind of ambient lighting.

 

The graphics are still from the tutorial, and, well... there isn't much else to show. It's still very empty, there are no proper player or enemy actors yet, etc., etc. I tried making a video to show the parallax and scroll speed changes in action, but it always ended up way to choppy to see anything properly...

 

But, well, considering that this is kinda fun to do (especially when I'm deviating from the tutorial ), maybe you'll get to play something based on this at some point?

 

Edit: More to see now:

 

 

Basic player actor implemented, though so far only capable of flying around the screen. Also added a very simple particle engine for the thruster exhaust, partially based on an example from the 'net, partially on an earlier experiment of mine in SDL.

 

Enough for today, it's past 4am again...

Edited August 4, 2011 by xdaniel

[xdaniel]

 

(Also, for some reason I keep getting timeouts when browsing the forums...?)

 

Edit: Even better now~

 

[BlackRose]

Looks incredible xdan! Can't wait for this to be released, it will truly help out many users in the zelda hacking community, including the URA team!

[Secant]

<content>

 

(Also, for some reason I keep getting timeouts when browsing the forums...?)

 

Edit: Even better now~

 

<eyegasm images>

HOLY SHIT DO I DETECT ALPHA CHANNELS?

 

YOU, SIR, HAVE WON COPIOUS INTERNET MONIEZ.

[Zeth Ryder]

Wow Xdan this is very very impressive, I like the new effects with the maps, between day and night transition. Actor spawning already as well? I'm thoroughly impressed! Now I do have a question, sometimes people could side jump through the wall in the collision on spinout's old converter, is this the case with the newly generated collision?

[xdaniel]

Naxy: It's not perfect yet, tho http://core.the-gcn.com/public/style_emoticons/default/thumbsup.gif The water surface works right, while Link always appears in front of the waterfall, for example.

 

Zeth: I've been side-jumping all over the place just now and did not go through any walls, tho that's not to say it might still happen on a map with more complicated collision and such.

 

Edit:

 

 

Capable of changing the scale, BGM value, scene injection offset and collision model, as well as adding/deleting rooms, changing their injection offset and each group's alpha value. Every group in an .obj model is a Display List, so it's a good idea to make ex. water a separate group from your other geometry.

 

Actors and everything else not mentioned cannot be changed via the GUI yet.

 

Edit 2:

 

 

Objects can now be added/edited/deleted.

[DeathBasket]

This is looking great. I take it the map in your viewer is before conversion?

Do you have any plans for converting to just a display list rather than a map/scene?

[xdaniel]

DeathBasket: Yeah, the map's representation in the program is a preview based on the source information (.obj model, etc), mainly for actor placement and such; it doesn't read back the converted data.

 

Also, while I don't have concrete plans for just converting into Display Lists yet, the code's flexible enough for that, so either I'll add that somehow/make a new tool for it, or someone else can do so once the source is released (which I guess I'll do with the first release).

[SanguinettiMods]

Xdan, I'm curious. What kind of texture support does this have?

[xdaniel]

SanguinettiMods: As in, what texture sizes are supported, what N64 formats are they converted into?

 

On the N64 side:

 

- RGBA 16-bit, max. 4096 byte (ex. 64x32)

- CI 4-bit, max. 4096 byte (ex. 64x64)

- CI 8-bit, max. 2048 byte (ex. 64x32)

- IA 8-bit, max. 4096 byte (ex. 64x64)

- IA 16-bit, max. 4096 byte (ex. 64x32)

- I 4-bit, max. 4096 byte (ex. 128x64)

- I 8-bit, max. 4096 byte (ex. 64x64)

 

Any texture works as long as it fits into one of those "categories", so to speak. And the converter's also trying to figure out the best texture format to convert the texture into, by looking at things like size, color depth, actual color count, alpha channels, etc.

[SanguinettiMods]

Yes, what sizes are supported.

 

That's awesome! Does that mean the biggest size is 128 x 64? I was wondering what the Largest sizes of textures were, and what file types were supported.

 

Also, does it darken the textures or Lighten the textures like Spinouts?

[xdaniel]

128x64 for grayscale I-type textures only. 16-color textures can be up to 64x64 (CI 4-bit), 256-color textures up to 64x32 (CI 8-bit) or whichever other combination of width/height that doesn't exceed the maximum per texture type. As long as a texture, when converted, is smaller than either 4096 or 2048 bytes (depending on the type converted to, see the list), it should work... Well, uh, I'm bad at explaining this, sorry.

 

Source texture files should be able to be anything C# supports by itself, so bitmaps, PNGs, JPGs and many others. As for lighting and darkening textures, I don't think that's needed as the converter calculates proper vertex normals, which means the model adheres to the game's lighting like the regular outdoor maps (Hyrule Field, Kakariko, etc) do and thus lightens and darkens according to that.

[DeathBasket]

Source texture files should be able to be anything C# supports by itself, so bitmaps, PNGs, JPGs and many others. As for lighting and darkening textures, I don't think that's needed as the converter calculates proper vertex normals, which means the model adheres to the game's lighting like the regular outdoor maps (Hyrule Field, Kakariko, etc) do and thus lightens and darkens according to that.

 

I believe Sanguinetti is referring to the texture files themselves, not how they display in-game. Textures output from spinout's wotf.py appear noticeably darker than the original images, as if their brightness was reduced by half. I'd dig out an example but I should be getting to bed about now.

[SanguinettiMods]

I believe Sanguinetti is referring to the texture files themselves, not how they display in-game. Textures output from spinout's wotf.py appear noticeably darker than the original images, as if their brightness was reduced by half. I'd dig out an example but I should be getting to bed about now.

 

Sort of... I was wondering what the Highest resolution was for any type of texture, What File type would be supported in maps or be best to use, and if the textures are altered at all during conversion. (Brightness/Darkness wise)

[Zeth Ryder]

Now comes the curious question, is this importing maps the correct way compared to the old map porting methods?

[xdaniel]

Not yet, sadly, it's still just modifying the scene table. I'm for now concentrating on getting a working importer with support for actors and the like going, then after the first release, I'll go back to trying DMA table modification/rebuilding.

 

Edit:

 

 

Actor adding/editing/deleting; no mouse-based movement yet.

[JDYoungLink1]

Xdaniel You Rock I grant you 1 million epic points spend as you like lol http://core.the-gcn.com/public/style_emoticons/default/thumbsup.gif .

[spinout]

Now comes the curious question, is this importing maps the correct way compared to the old map porting methods?

 

What do you mean by that? Putting entries in the file table? If that is what you mean, do realize that correctly using the filetable can require (unless you are lucky) an ENTIRE re-build of the ROM. That means every ROM pointer in code (the overlay, actor, scene, and object tables, I'm sure there are more which aren't even known) - and every pointer in maps and scenes (map pointers, static background JFIF pointers) along with the pointers in the filetable must all be recalculated. Why is this? Because the way OoT looks up files is a binary search - which requires all files to be in order.

 

Sorry for the rant, and if this isn't what you were talking about, :oops:

[DeathBasket]

Why is this? Because the way OoT looks up files is a binary search - which requires all files to be in order.

Couldn't we rewrite it as a linear search or would that be too slow in some cases?

[xdaniel]

Guess I'm not going to try too hard with DMA table rebuilding and such then...

 

Anyway, some more progress. XML loading and saving is pretty much done, so that...

 

 

...equals...

 

 

<?xml version="1.0" encoding="utf-8"?>
<ZScene xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Name>testfield</Name>
  <Scale>1.5</Scale>
  <Music>2</Music>
  <InjectOffset>47185920</InjectOffset>
  <CollisionFilename>C:\oot-obj\Test_Field\Test_Field_Collision.obj</CollisionFilename>
  <SpawnPoints>
    <ZActor>
      <Number>0</Number>
      <XPos>0</XPos>
      <YPos>0</YPos>
      <ZPos>0</ZPos>
      <XRot>0</XRot>
      <YRot>32760</YRot>
      <ZRot>0</ZRot>
      <Variable>4095</Variable>
    </ZActor>
  </SpawnPoints>
  <Environments>
    <ZEnvironment>
      <C1>4599097</C1>
      <C2>4802889</C2>
      <C3>11836042</C3>
      <C4>12040119</C4>
      <C5>1315900</C5>
      <FogColor>9205870</FogColor>
      <FogDistance>2017</FogDistance>
      <DrawDistance>12800</DrawDistance>
    </ZEnvironment>
    <ZEnvironment>
      <C1>6904410</C1>
      <C2>4802889</C2>
      <C3>16777200</C3>
      <C4>12040119</C4>
      <C5>3289690</C5>
      <FogColor>6579320</FogColor>
      <FogDistance>2020</FogDistance>
      <DrawDistance>12800</DrawDistance>
    </ZEnvironment>
    <ZEnvironment>
      <C1>7887360</C1>
      <C2>4802889</C2>
      <C3>16418610</C3>
      <C4>12040119</C4>
      <C5>1973820</C5>
      <FogColor>7882290</FogColor>
      <FogDistance>2019</FogDistance>
      <DrawDistance>12800</DrawDistance>
    </ZEnvironment>
    <ZEnvironment>
      <C1>2639460</C1>
      <C2>4802889</C2>
      <C3>1315875</C3>
      <C4>12040119</C4>
      <C5>3289700</C5>
      <FogColor>30</FogColor>
      <FogDistance>2016</FogDistance>
      <DrawDistance>12800</DrawDistance>
    </ZEnvironment>
    <ZEnvironment>
      <C1>3942470</C1>
      <C2>4802889</C2>
      <C3>5250620</C3>
      <C4>12040119</C4>
      <C5>5255830</C5>
      <FogColor>4598573</FogColor>
      <FogDistance>65490</FogDistance>
      <DrawDistance>12800</DrawDistance>
    </ZEnvironment>
    <ZEnvironment>
      <C1>4938340</C1>
      <C2>4802889</C2>
      <C3>3670000</C3>
      <C4>12040119</C4>
      <C5>693950</C5>
      <FogColor>1333870</FogColor>
      <FogDistance>65490</FogDistance>
      <DrawDistance>12800</DrawDistance>
    </ZEnvironment>
  </Environments>
  <Rooms>
    <ZRoom>
      <ModelFilename>C:\oot-obj\Test_Field\Test_Field.obj</ModelFilename>
      <InjectOffset>56422400</InjectOffset>
      <ZObjects>
        <ZObject>
          <Value>12</Value>
        </ZObject>
        <ZObject>
          <Value>50</Value>
        </ZObject>
        <ZObject>
          <Value>22</Value>
        </ZObject>
      </ZObjects>
      <ZActors>
        <ZActor>
          <Number>18</Number>
          <XPos>-300</XPos>
          <YPos>60</YPos>
          <ZPos>-1000</ZPos>
          <XRot>0</XRot>
          <YRot>0</YRot>
          <ZRot>0</ZRot>
          <Variable>1</Variable>
        </ZActor>
        <ZActor>
          <Number>2</Number>
          <XPos>450</XPos>
          <YPos>130</YPos>
          <ZPos>-1100</ZPos>
          <XRot>0</XRot>
          <YRot>0</YRot>
          <ZRot>0</ZRot>
          <Variable>3</Variable>
        </ZActor>
        <ZActor>
          <Number>18</Number>
          <XPos>-150</XPos>
          <YPos>110</YPos>
          <ZPos>-1250</ZPos>
          <XRot>0</XRot>
          <YRot>0</YRot>
          <ZRot>0</ZRot>
          <Variable>1</Variable>
        </ZActor>
        <ZActor>
          <Number>27</Number>
          <XPos>-360</XPos>
          <YPos>0</YPos>
          <ZPos>-2850</ZPos>
          <XRot>0</XRot>
          <YRot>0</YRot>
          <ZRot>0</ZRot>
          <Variable>0</Variable>
        </ZActor>
        <ZActor>
          <Number>27</Number>
          <XPos>-120</XPos>
          <YPos>0</YPos>
          <ZPos>-2750</ZPos>
          <XRot>0</XRot>
          <YRot>0</YRot>
          <ZRot>0</ZRot>
          <Variable>0</Variable>
        </ZActor>
      </ZActors>
      <GroupAlpha>
        <int>255</int>
        <int>128</int>
        <int>128</int>
      </GroupAlpha>
      <ModelShortFilename>Test_Field</ModelShortFilename>
    </ZRoom>
  </Rooms>
</ZScene>

 

...and equals...