[PSX] Megaman Legends 1 Research Thread

[kion]

Okay, so I've made a new generally worthless thingy. Link: mml.dashgl.com/tools/mml1_psx_pbd/

I got a little more carried away with MML2 than I expected. And for the most part I managed to get most of the reaverbots, and then got carried away with making a file format, and then got stuck working on the flags for trying to merge polygons. So I'm going back to MML1 to try get the assets that I missed out on, and improve on my support for exporting file formats. Plus lets face it, MML1 is just the better Megaman Legends game.

So the files we're looking at specifically are the files in the CDDATA/DAT/ directory of the playstation version of Megaman Legends 1. Most of the files in the directory start with "ST". And that's generally because most of the data in the game is stage data. Each stage has a base file, such as ST03.BIN, which I think (and have tested a little) contains the geometry for the stage. And then files such as ST03_00.BIN contain the scenario, and contain all of the NPC data to occupy the stage.

So what's left besides the environment and NPC/enemy data? The answer is really not much. Pretty much the only information left is the model data for the Megaman player character which is stored in the data. Specifically the files list below, are the player model data.

ARM00L.BIN
ARM00R.BIN
ARM01R.BIN
ARM02R.BIN
ARM03R.BIN
ARM04L.BIN
ARM04R.BIN
ARM05R.BIN
ARM06R.BIN
ARM07R.BIN
ARM08R.BIN
ARM09R.BIN
ARM10R.BIN
ARM11R.BIN
ARM12R.BIN
ARM13R.BIN
HEAD00.BIN
HEAD01.BIN
LEG00.BIN
LEG01.BIN

Each one of these contains a different part that can be swapped out. Such as the special weapons for the right arm, the helmet or the hair, and the normal shoes versus the jet skates. There's also a lot of information stored in INIT_DAT.BIN. So it's kind of a challenge to track down where the information for Megaman is specifically because it's kind of scattered all over. For instance, each one of the files for the special weapon will have the model for the special weapon, the sound effect for the weapon, and the animation for the weapon inside the file. So I guess it just made it easier for them to manage the data that way. But I still don't know where Megaman's bones are. Though again, I expect some information to be in INIT_DAT.BIN, but there could be more hiding else where.

So I should probably make a list of files contained in some of these archives to be able to track where I've looked, and if there are any patterns in the names of the files that could give hints as to their function.

[kion]

So ultimately my goal in this thread is to shift from general information to focusing more on environments, but I want to get a general outline of what's in each file to mapped out so we can have an idea of what's where. So

DEMO_DAT.BIN

Contains information for the title screen. We have information for the Servbots that run around, the title logo, as well at the menu and the background tiles.





EXIT_MAP.BIN
EXIT_SUB.BIN
EXIT_SUP.BIN

Not really sure what these are for. In terms of textures, all they have are the gauge hud, and common effects used in game for textures. Which means I might have to take a more in-depth look at what's inside. Though there aren't any quick and dirty hints that give an idea of what these actually do.

FONT.BIN
GAUGE.BIN
KAIFONT.BIN

Nt really a lot of textures in here. Probably just fonts (and the gauge for the ui), so I probably don't need to dig into these files too mcuh.

MAP_A1.BIN



MAP_A2.BIN



MAP_B1.BIN



MAP_B2.BIN



MAP_B3.BIN



SUB_KEY.BIN



SUB_WPN.BIN



SUPPORT.BIN
SUPPORT2.BIN



The support files both have the same textures, so could be one for the Flutter, one for the support car. Which might mean there are differences in the file, but not in the textures.

[Dashe]

You sure that's the support car? I thought the support car was green inside and the R&D room on the Flutter was reddish brown. Does the game just invert the colors for the weapon roulette?

[kion]

The previous post was to get a general outline going. There are actually three textures in each of the support files:

SUPPORT.BIN





SUPPORT2.BIN





So we have green for the Support car and then Red for the Flutter. That's a detail that completely went passed me. For the weapon roulette, and for the game in general, to save on video memory, all of the in-game textures only use 16 colors. So what they'll do is create an image, and then draw different sections of the the image with different pallets. So the red version of the weapon selection is with Pallet 0, and then if we select pallet 1, we get the following:



This effect is often used on the gauge, which looks like this for the different pallets:

[RyanLEO]

Always love seeing stuff like this, do you have a copy of the files? Or is there a link somewhere? Haven't been here for a long time :/

I've always thought the wall textures were interesting, would like to see if I could use this to view a bigger version of your img here: i.imgur.com/vq3qZTP.png

[kion]

Sept 21, 2018 9:34:19 GMT -5 RyanLEO said:

Always love seeing stuff like this, do you have a copy of the files? Or is there a link somewhere? Haven't been here for a long time :/

I'm being careful to avoid distributing files in favor distributing programs that can read the files. For previewing textures you can find the page here: mml.dashgl.com/tools/mml1_psx_tex/. You can click on the browse button and then select a .BIN file from either the JP or EN version of Megaman Legends 1 for PSX. And then either right click and save or click on the export button to save the png.



For models and other assets you can check out all the tools I've made here: mml.dashgl.com/ and the source code is all available here: gitlab.com/kion-dgl

Sept 21, 2018 9:34:19 GMT -5 RyanLEO said:

I've always thought the wall textures were interesting, would like to see if I could use this to view a bigger version of your img here: i.imgur.com/vq3qZTP.png

The Playstation has a technical limitation of 256x256 for sprite size. A few games get around this by combining multiple sprites into one image to display on the screen. But in the case of Megaman Legends 256x256 is the full size of the image. To increase the resolution you will either need to do some photoshop magic, or break into the offices of Capcomand pray you come across the mother load. If you're interested in how the game lays out memory you can download the no$psx emulator and you can preview the game's video memory.

[kion]

Okay, so looking into stages (i guess). Right now looking into ST09.BIN, which is the area where you save the junkshop man, which is easier than other areas to locate and debug.

So first file in the archive is a program? Scrolling through it, it looks like there are a bunch of pointers (for i guess jumping to routines maybe?). Not sure how the programmers structured this stuff. But I'm going to ignore this for now.

000000000: 00000000 a0ea0100 3f000000 00001080  ........?.......[/div]000000010: 00000000 00000000 00000000 00000000  ................
000000020: 00000000 00000000 00000000 00000000  ................
000000030: 00000000 00000000 00000000 00000000  ................
000000040: 2e2e5c70 726f6762 696e5c72 335f7374  ..\progbin\r3_st
[div]000000050: 30392e62 696e0000 00000000 00000000  09.bin..........

Next file is a MAP.IDX file. Not sure what IDX stands for (indexes?). The data seems to be a pointer followed by two dword values.

00001f800: 00000000 e44b0000 0b000000 00c01580  .....K..........
00001f810: 00000000 00000000 00000000 00000000  ................
00001f820: 00000000 00000000 00000000 00000000  ................
00001f830: 00000000 00000000 00000000 00000000  ................
00001f840: 2e2e5c4d 41505c44 4154415c 53543039  ..\MAP\DATA\ST09
00001f850: 5f4d4150 2e494458 00000000 00000000  _MAP.IDX........

Third file, Map.MDT.

000025000: 00000000 02310000 08000000 00401680  .....1.......@..
000025010: 00000000 00000000 00000000 00000000  ................
000025020: 00000000 00000000 00000000 00000000  ................
000025030: 00000000 00000000 00000000 00000000  ................
000025040: 2e2e5c4d 41505c44 4154415c 53543039  ..\MAP\DATA\ST09
000025050: 5f4d4150 2e4d4454 00000000 00000000  _MAP.MDT........

What ever this data is, it seems to have a header of 0x09 things, followed by a dword and a pointer.

Not sure what the data is, I can try reducing the number on the header, or replacing one entry with another entry to see what happens (probably crashing).

000025800: 09000000 5e43171c 4c401680 33332322  ....^C..L@..33#"
000025810: 54451680 403e1413 a04e1680 3d3a070b  TE..@>...N..=:..
000025820: 98511680 3a2a1e26 32521680 41311423  .Q..:*.&2R..A1.#
000025830: 1a5b1680 3932211e 92601680 2a371a14  .[..92!..`..*7..
000025840: 4e681680 282a2112 5e6c1680 00000000  Nh..(*!.^l......

Next file is a stage, i mean .STG file.

000029000: 00000000 f8830100 32000000 00401980  ........2....@..
000029010: 00000000 00000000 00000000 00000000  ................
000029020: 00000000 00000000 00000000 00000000  ................
000029030: 00000000 00000000 00000000 00000000  ................
000029040: 2e2e5c53 43525c44 4154415c 53543039  ..\SCR\DATA\ST09
000029050: 2e535447 00000000 00000000 00000000  .STG............

It looks like this one has a specific format for the header, and massive chunks of data for what ever these point to.

000029840: 00000000 00000000 60721980 70721980  ........`r..pr..
000029850: 80721980 60721980 70721980 80721980  .r..`r..pr...r..
000029860: 0001000a c89d1a80 00000000 00000000  ................
000029870: 00000000 00000000 90721980 a0721980  .........r...r..
000029880: b0721980 90721980 a0721980 b0721980  .r...r...r...r..
000029890: 0002000a c89d1a80 00000000 00000000  ................

And then next a .HED file.

000042000: 00000000 60080000 03000000 00a01380  ....`...........
000042010: 00000000 00000000 00000000 00000000  ................
000042020: 00000000 00000000 00000000 00000000  ................
000042030: 00000000 00000000 00000000 00000000  ................
000042040: 2e2e5c53 43525c44 4154415c 53543039  ..\SCR\DATA\ST09
000042050: 2e484544 00000000 00000000 00000000  .HED............

This is a really short file with pointer, data, pointer, data.

After this is a list of TIM images:

Which I'm going to go out on a limb and say those look like the stage textures.

So going back to the list of files, that means we have a program, which could be things like spawn/despawn points, door radius, which areas to load, unload, cycles and things like that. Which leaves what the functionality of IDX, MDT and STG files are. My prediction about how the game manages stage files, is that the game defines a grid of tiles. So the grid is going to be a maximum number of squares, and either defined or underfined for a square in the grid. Each defined square is probably going to have an index to a list of defined squares. And each defined square is going to need to have x,y,z position coordinates for each vertice, a list of either triangles or quads to define the faces (potentially just quads if everything is square), and then a list of uv values for the texture for each face.

So right now there are two approaches. Once approach is to go back over xDaniel's Dash Test program, to see if there are any hints to work from, as I think he did work out some of the grid system (maybe?). The other option is testing, changing values and seeing what happens to try and narrow down what the functionality of these files is. There also is the need to export these files outside of the archive, and then remap the pointers to inside the file, and then create a spreadsheet which the different sections of each file marked off, to see if that gives any clues. For right now I'll go with random testing.

As for testing methods, there are two methods. One is to create a save state and change the save state directly. I don't like doing this too much, as I keep loosing track of what I'm doing with which save state to use, and having to pack and repack the states all of the time confuses me. So the other option is to make a save state right before loading the stage and then editing the disk image file with any changes. This generally makes it easier to track the changes in the game data, with how it affects the game. So I can start by commenting things out, and seeing what breaks respectively.

[kion]

I guess I'll cross reference with ST04 (the Apple Market). Not sure if sticking with one place is going to be the best idea, but for now we'll just focus on looking at the different file formats that make up the base map archive. So first up we have the IDX file. So the header looks something like this:



Looks like there isn't much there. The first value 0x01f8 is pretty easy, it's the length of the data. Not sure what 02 is. And then 0x80150c00 is the area in the memory where the data is going to be copied to, which really means this is the number to be subtracted to adjust for local pointers.



The size of 0x01f8 gives us a size of the data, which is marked by the red dot. Aside from that the pattern for this file type is pretty simple, it's a list of two values followed by a pointer. So we don't know what this file format does exactly, but we can try and make some guesses based on what we know about the game. The game uses a systems of tiles, and this is an IDX file, it could be the place holder for the indexes used for the map tiles. So the two values before each pointer could be some kind of identifying tile type, or tile properties (such as whether to check collision or treat the tile as a floor or wall). And the last pointer could be the pointer to where the 3d vertices are after being loaded into memory.

So there are a few things we can do to test these guesses. We can try commenting out a series of indexes to see if anything changes. We can try overwriting other entries with clones to see if we can get indices to repeat. We can to delete all of the two values before each pointer to see what happens. Basically just keep messing with things to see if we can get things down into predictive behavior.

Edit:



Okay, I wasn't expecting to get such immediate results, but I'll take it. Looks like replacing some of these values with 0 removes some of the tiles in the Apple Market. And you can run over and jump into the abyss with the NPC that fell in.

Edit:



And what happens when we copy and paste the same value over and over again? Looks like we get the same wall everywhere, so the AppleMarket now ends at Hipbone (and the Jetlag Bakery is now a Wall too).

[kion]

Next is the MDT file. Not much in the header, I think 0x1cc is the file length. We see 0x02 in the same place as the IDX file, so I guess we'll have to look at other files to see if that number changes. Could be some kind of area flag (or something else completely unrelated).



Which leaves the data itself:



Not much here. There seems to be some kind of header with 0x06, followed by six value/pointers. So same thing we can comment these out and see what happens. It could be the different parts of the area that get loaded:
1. the main apple market
2. the junk shop
3. the tailer
4. high neck record shop
5. electronics shop
6. hipbone

Which means that we might overwrite these pointers to see if we can load a different area. As for the data itself, we have a bunch of bytes, but nothing that seems to go over 0x29, which we'll have to see if that matches up with the number of indices (i didn't actually count before).

So right now we can do two quick tests.
1. Move the pointers around to load in the wrong area
2. Replace the "tile" pointers with 0, or other values.

Edit:

So the results of the first test are pretty trippy. For the top pointers, I left the first value alone (since I figured that's the Apple Market area), and then copied the second pointer over the other pointers. So basically I would expect the same area (which turns out to be the junkshop) loaded for any door you walk into. And this is what it looks like:

<pre>00118f8e0: 5c858960 04edbf14 931b9fb4 848a185b \..`...........[
00118f8f0: 00ffffff ffffffff ffffff00 01462902 .............F).
00118f900: 00000800 00000800 06000000 35430811 ............5C..
00118f910: 34401680 3e3e0404 44411680 3e3e0404 4@..>>..DA..>>..
00118f920: 44411680 3e3e0404 44411680 3e3e0404 DA..>>..DA..>>..
00118f930: 44411680 3e3e0404 44411680 00000000 DA..>>..DA......
00118f940: 00000000 00000000 00000000 00000100 ................</pre>



So the junkshop gets loaded, but with a different pallet. So the value part could include parameters like the size of the tiles to load in, or the number of tiles. Might be worth messin with some of these values.



And walking into the electronics store gives the same result. Except this time with the electronics store pallet, the horroko is now on sale for 1,980 zenny.

Edit 02:

Hmmmm, not much luck with the body of the data itself. It looks like tile indexes. And I can comment out specific tiles, but I can't seem to get tiles to repeat or change (all floors or all walls or something). Even trying to change the tile index for a single tile just resulted in the tile not showing at all.



Kind of a sad panda on this one. Unless maybe these aren't the tile numbers, but the tile properties? Really not sure, I can comment out floor tiles, but the floor will still be there, but then you call into the abyss when you walk over the visible floor.

[kion]

Okay, so in summary so far. Going through the stage archive, we first have a .prog file, which I think is for things like pathing and or loading zones. Probably not the stage data itself. Next we have an IDX file which seems to give indexes which are pointers to somewhere else in memory. THen we have the MDT file, which defines the number of areas, and gives something that looks like tiles, but I was unable to change any of the tiles by editing that file. Which means the next file to look at is the STG file, which after that are just TIM files. So hopefully that means that the vertex, texture, uv (and possibly tile definition?) are all found in the STG file.

Though looking at the STG file, there is a header, but most of the file seems to be pretty complicated. So rather than a top down analysis, I think I'm going to try throwing things at the wall and seeing what sticks. So first thing that stuck, i was able to comment out the UV for a flag in the Apple Market by commenting out this part of the .bin file.



001194c90: 3ffe3fe0 1fc11fe0 00c100e0 1ffe1fe0  ?.?.............
001194ca0: 3ffe3fe0 33c11fe0 00c100e0 1fe01fc1  ?.?.3...........
001194cb0: 3fe03fc1 1fe01ffe 00e000fe 1fe01ffe  ?.?.............
001194cc0: 00e000fe 1fe033c1 3fe03fc1 00000000  ......3.?.?.....
001194cd0: 00000000 00000000 e017fe17 c000df00  ................
001194ce0: c03edf3e e000fe00 e017fe17 c03ec000  .>.>.........>..
001194cf0: df3edf00 fea0febf e0a0e0bf febfe0bf  .>..............

Edit:
And something else interesting to note is that the UV for all of the tiles seem to be grouped. So commenting out a continuous area to zero will make more and more stuff be a flat color. Which gives a little bit of a hint as to how the header might be laid out.



Edit:

Since I have the memory span of a goldfish, I'll post more spam while I'm thinking about things. My prediction for how the game manages tile data looks something like this:


So the game should have somewhere where tiles are defined (by a list of indices), and then each index is going to need to be defined as a 3d object somewhere. So far I've managed to bumble my way across the UV definition, for that 3d object. So I can try and poke my way around the file more to see if I can come across anything.

Also taking notes from Discord (Trege), each tile seems to have three indices. One for the floor tile, one for the object to be displayed on that tile, and one for the collision the tile interacts with. Also it seems like Downtown is a good place for testing, as it has candidates for objects that are displayed (houses), than can be added and removed, without creating holes in the ground for Megaman to fall into.

Edit:

More Notes. Here's a screenshot of the first tile in Downtown (credit: Trege)


And here's a list of tiles for downtown (credit: Trege)

Tile Types
Downtown's Tile ID List
00 = grass up right
01 = grass down right
02 = grass down left
03 = grass up left
04 = grass right
05 = grass down
06 = grass left
07 = grass up
08 = grass edge right
09 = grass edge down right
10 = grass edge down left
11 = grass edge up left
12 = grass up
13 = grass right
14 = grass down
15 = grass left
16 = sidewalk up right
17 = sidewalk down right
18 = sidewalk down left
19 = sidewalk up left
20 = sidewalk vertical up
21 = sidewalk horizontal right
22 = sidealk vertical down
23 = sidewalk horizontal left
24 = sidewalk ???
25 = sidewalk ???
26 = sidewalk ???
27 = sidewalk ???
28 = sidewalk ???
29 = sidewalk ???

Here's the position of the first tile in Downtown:



Here are some memory addresses for different values: (credit: Trege)

[Trege]

Just for archival purposes if anyone is wondering how to get the actual PS1 RAM Addresses from those addresses just subtract A8B6A0 from any of those addresses in the picture and you'll get the PS1's actual RAM equivalent, Shadyrounds figured that one out. I only found the addresses.

[kion]

Well, this wasn't quite my ambition of replacing everything with grass, but I'll take it (for now).



So far I've managed to get about two lanes replaced with grass. You can see the hex editor on the right, all of the tiles have been replaced with 0x0c (grass, credit: Trege). So the archive file is ST05.BIN, and the file within the archive is ST05_MAP.MDT. So you can search for that in the ROM and below it should be:

00003a800: 05000000 313a211b 2c401680 313a211b  ....1:!.,@..1:!.
00003a810: 2c401680 3c3d0805 22471680 3f3e0303  ,@..<=.."G..?>..
00003a820: 72471680 3e3e0404 84471680 0c800c80  rG..>>...G......
00003a830: 0c800c80 0c800c80 0c800c80 0c800c80  ................
00003a840: 0c800c80 0c800c80 0c800c80 0c800c80  ................
00003a850: 0c800c80 0c800c80 0c800c80 0c800c80  ................
00003a860: 0c800c80 0c800c80 0c800c80 0c800c80  ................
00003a870: 0c800c80 01000100 02000200 03000300  ................
00003a880: 04000400 05000500 06000600 07000700  ................
00003a890: 08000800 09000900 0a000a00 0b000b00  ................
00003a8a0: 0c000c00 0d000d00 0e000e00 0c800c80  ................
00003a8b0: 0c800f00 0f000100 01000200 02000300  ................
00003a8c0: 03000400 04000500 05000600 06000700  ................
00003a8d0: 07000800 08000900 09000a00 0a000b00  ................
00003a8e0: 0b000c00 0c000d00 0d000e00 0e000c80  ................

And the first appearance of 0x0c800c80 will be the first tile. So if you start replacing these, you can overwrite the ROM with something different, assuming the game doesn't feel like putting a hole in the ground where the tile should be.

Edit: I tried to record, but I don't think Wayland is supported for screen recording yet. So for now I just took a quick pitcure. Downtown has been converted into a pasture.



Pretty much just copied 0x0c80 over all of the tiles for flat grass.

[kion]

So incase my notes didn't do an effective job of showing to to turn Downtown into a Harvest Moon clone, here's a quick (rambly and poorly made video), that shows the process.



Edit:

Placing some notes here (so I don't lose it)
001191140: 00000000 00000000 00000000 00000000  ................
001191150: d05c1980 f45c1980 f45c1980 d05c1980  .\...\...\...\..
001191160: f45c1980 f45c1980 00090000 94971a80  .\...\..........
001191170: 00000000 00000000 00000000 00000000  ................
001191180: 185d1980 3c5d1980 3c5d1980 185d1980  .]..<]..<]...]..
001191190: 3c5d1980 3c5d1980 00000200 24981a80  <]..<]......$...
0011911a0: 00000000 00000000 00000000 00000000  ................
0011911b0: 605d1980 845d1980 a85d1980 605d1980  `]...]...]..`]..
0011911c0: 845d1980 a85d1980 00010200 f4981a80  .]...]..........
0011911d0: 00000000 00000000 00000000 00000000  ................
0011911e0: c45d1980 ec5d1980 145e1980 c45d1980  .]...]...^...]..
0011911f0: ec5d1980 145e1980 00020200 d4991a80  .]...^..........
001191200: 00000000 00000000 00000000 00000000  ................
001191210: 3c5e1980 605e1980 8c5e1980 3c5e1980  <^..`^...^..<^..
001191220: 605e1980 8c5e1980 00030200 649a1a80  `^...^......d...
001191230: 00000000 00000000 00000000 00000000  ................
001191240: a85e1980 cc5e1980 f05e1980 a85e1980  .^...^...^...^..
001191250: cc5e1980 f05e1980 00040200 049b1a80  .^...^..........
001191260: 00000000 00000000 00000000 00000000  ................
001191270: 0c5f1980 305f1980 545f1980 0c5f1980  ._..0_..T_..._..
001191280: 305f1980 545f1980 00050200 a49b1a80  0_..T_..........
001191290: 00000000 00000000 00000000 00000000  ................
0011912a0: 645f1980 885f1980 a45f1980 645f1980  d_..._..._..d_..
0011912b0: 885f1980 a45f1980 00060200 149c1a80  ._..._..........
0011912c0: 00000000 00000000 00000000 00000000  ................
0011912d0: b45f1980 d85f1980 fc5f1980 b45f1980  ._..._..._..._..
0011912e0: d85f1980 fc5f1980 00070200 b49c1a80  ._..._..........



And this segement in particular looks like the tile outside of the music shop.

001191180: 185d1980 3c5d1980 3c5d1980 185d1980  .]..<]..<]...]..
001191190: 3c5d1980 3c5d1980 00000200 24981a80  <]..<]......$...



So we have six pointers, some value and another pointer. So I noticed that stage tiles also seem to have a high, medium and low level of detail models. So that could explain the number of pointers. I guess I'll try commenting each one out one at a time, and then see if it has any kind of effect.

Edit:

First pointer - tile is still visible, but I fall through the floor
Second Pointer - tile is visible, dissappears when I walk a short distance away
Third Pointer - No change
Fourth Pointer - No change
Fifth Pointer - No change
Sixth Pointer - No Change
Value - No change
Seventh Pointer - No change

These results don't make any sense. I can simultaniously remove everything after the first two pointers and the tile still works. Though if only the first pointer is removed, the tile still appears but the collision doesn't work. The second pointer seems to be pointer to the distances to swap out the different LOD models. The first pointer seems to be collision, and if the first and fourth pointers are removed, the tile dissappears. Though that's completely weird that it would require two pointers to be removed for the tile to not display. Removing the first and fifth pointers causes the tile to disappear at a distance. And there might be something for low LOD, but I don't think the Apple Market can get far enough away. And on the reverse side of things leaving the fourth pointer on and removing everything else causes the tile to stil be drawn. Leaving the fifth pointer on and removing everything else will cause the tile to be empty when close, but appear when you get a little further away.

So we can draw some guesses as to the functionality of some of these pointers:


First pointer - collision
Second Pointer - LOD toggle
Third Pointer - unknown
Fourth Pointer - High LOD model
Fifth Pointer - Medium LOD model
Sixth Pointer - Low LOD Model
Value - Unknown
Seventh Pointer - Unknown

The file is ST04.STG inside ST04.BIN (btw)

[kion]

I guess I'll throw on a few more notes. So I tracked down the specific file location for the area in the STG file where I was able to toggle that one specific tile. And it's in ST04.STG at offset 0x610 in the file locally. I then went and adjusted the pointers for that one area to point inside the file, so I can track down where they point to. If the file structure seems simple enough, then I might be able to make some predictions on what the data on what's in the file. Otherwise hopefully the data will give me some areas to search and change and see if it affects anything in the client.

000000610: 00000000 00000000 181d0000 3c1d0000  ............<...
000000620: 3c1d0000 181d0000 3c1d0000 3c1d0000  <.......<...<...
000000630: 00000200 24580100 00000000 00000000  ....$X..........

So here ate the pointers (started with 0x1d18), and then I need to goto each pointer to see if there's anything to be made sense of. Though one thing that already makes sense while also not making sense, is the same pointers pop up over and over again in this file. Which makes sense, because a lot of tiles are pretty much the same, save a color pallet or a few details. So it would make sense that alot of the data would be repeated. And in this case it looks like we only have 0x1d18 and 0x1d3c.

Edit:

And then the position in the data is here:

001192c10: 02430100 1c00c07f 1d00887f bc7a1940  .C...........z.@
001192c20: 84091a08 7c7c1941 c40c1a0a 4c7a1940  ....||.A....Lz.@
001192c30: 640d1a01 02430000 1c00c07f 1d00887f  d....C..........
001192c40: 3c7b1940 940a1a04 047c1941 d40a1a02  <{.@.....|.A....
001192c50: 4c7a1940 640d1a01 02c30100 1800487c  Lz.@d.........H|
001192c60: 1800087c cc7c1940 740d1a09 147d1941  ...|.|.@t....}.A


Though one thing that's weird is commenting out any little part of this causes most of the tile to dissapeear.

Edit:

Not sure if I would call this "progress", but interesting enough to be noteworthy. While messing around with some of these values to try and see if I could get something to change instead of simply dissapear, after commenting out the 0x40 in the first line of

001192c10: 02430100 1c00c07f 1d00887f bc7a1940

to

001192c10: 02430100 1c00c07f 1d00887f bc7a1900

I noticed this weird shape in the middle of the room:



And then looked up to see:



That the window above High Neck Records was now smaller and infront of highneck records. So it looks like there could be some scaling going on with the environment. Where the tiles are declared smaller than they need to be and then scaled up.

So a little more testing:

from 0x40 to 0x10



and from 0x40 to 0x20



So it looks like scaling is definitey being used. And 0x40 is a pretty common byte that pops up in the STG file. So when it pops up, it could be often used for scaling of different tiles.


Edit:

Okay so found scaling on another 'tile'.



Except this is confusing me a lot for what does what.

001192c10: 02430100 1c00c07f 1d00887f bc7a19[b]40[/b]  .C...........z.@
001192c20: 84091a08 7c7c19[b]41[/b] c40c1a0a 4c7a1940  ....||.A....Lz.@

So it looks like I can't use bold inside a 'code' block. but I think it still makes it easier to see. Now the troubling part about this is that on the second one, 0x41, if you take off the 0x01 to make it 0x40 you start getting issues with the UV.



Which seems to indicate that they are really packing in the bytes. So originally I was hoping that the vertex and face definition for the enemies would be used. But that doesn't seem to be the case at all. It looks like they're using bytes or something really simple to make the basic shape of a tile, and then using scaling to get it to the size of what they need. For UV's as well, it looks like they might be using only 4 bits instead of 1 byte for each UV value respectively. So it could be that the UV values are in increments of 16 or something.

[kion]

My previous post is getting to the point where it's alittle cumbersome to keep editing. So from messing around with the STG file, I'm starting to be able to pick out some kind of structure.



So the first red box is the start of the High LOD tile in front of the record store, while the second red square is the medium LOD tile in front of the store. The yellow highlighted parts are the scale bits for the portion of the tile. Specifically the scale bits seem to be the upper four buts (0x10, 0x20, 0x40, 0x80), with the lower bits on the last byte (0x01, 0x02, 0x04, 0x08) being used for UV. Each tile is a selection of "segments". So in this case specifically, the tile is made up of three parts, the window, the floor, and the 'Apple' banner.

.

So in this case the same three segments are being defined twice, one for high and medium/low LOD. The green outline on the hex was for formatting. It looked like each segment was a dword followed by the uv/scale bits, and repeated. But it looks like that could be wrong since there is a dword right before the start of the medium/low LOD definition. So for now I'm going to hope that this means I have a 0x24 segment for the window, floor and banner that can be used for further testing to figure out specifically what these bits do.

I outlined the first green dword as it seemed to stick out. Originally it looked like there was some pattern of a dowrd followed by the scale byte. But looking at it with the screen cutout, it looks like there is a dword that follows the scale byte.

Edit:

More testing. It looks like these are pallet / image definitions.



So



and



Which means that so far there seems to be some kind of header. Leading dword(s) defining the pallet and images to be used. UV / scale, and then followed by a dword.