Modding Expeditions (KF)

[Holy_Diver]

Well, I already knew all of this for what it's worth. I thought it was funny your grid was square before, but just assumed you knew what you were doing.

But this image of the VRAM looks fishy to me, because it shouldn't be rainbow colored. That's just 4bit indices interpreted as 16bit colors probably. Also the VRAM is not static for the entire frame. So you will get a different picture of it depending on when you take your snapshot. I've used OGLE with (probably) ePSXe in the past, and got full color textures from it. It probably wasn't using the VRAM image precisely for a texture, but it did use a single sheet, which is safe if textures don't wrap or do filtering.

If you can use a strategy to figure out a direct mapping that's wonderful, and I encourage you to stay with it. But if we were to go a manual route of matching textures by eye, then I don't think a VRAM image like this is helpful since it looks almost like garbage. I do worry that the textures are so small that it's hard to tell exactly what many of them are. When I look at them arrayed across a white background they tend to look like dark patches to my eye.

What I did is "rip" the TIM images and name their files after their supposed positions in the VRAM. Then I looked at the Texture Page Numbers in the models (they address each of these pages) and try to line them up with the TIMs. Sometimes this is successful, but sometimes not. Like I think the item models may have TPNs that match the area that is showing the frame buffer in your image/in RetroArch's VRAM display option that looks very similar. Maybe these are TPNs for how they appear in the menu and not how they appear on the field. I don't know. I may be mistaken. The secondary frame buffer is probably, primarily used as the background in the menus. I wouldn't be surprised if items have two different models depending on if they are in the menus or on the field. There might be item models in the MO files, where I assume the object models live.

[Holy_Diver]

EDITED:

This also opens up other doors. Since we now know that texture page data is stored in set positions, and where the water texture is, we can check for that Texture page and those UV coordinates when loading the tileset, and change the division for the vertices, to fix the issue you were speaking of before, with overlapping edges. Tiles using specifically that texture can now have their vertices divided by 1024 instead of 1034, to automate even more of the process; Meaning it's no longer a choice between overlapping edges or gaps in the water.

I don't know if I follow. I expect the UVs go to the edge of the texture, and there is slight distortion. All I did is treat 1034 as a magic number, and change those vertices to 1024. I don't think you can do better. The only way to improve upon this is to develop a logic for diagonal walls, but I would worry about deceptive false positives in that case, and would rather do hand fixes. I don't think the railroad tracks stay in the 1x1 grid, and so it is not as simple as projecting an edge back to the grid boundary. I think it's not a problem to fix these cases by hand, since extensive hand work is going to be necessary no matter what.

[TheStolenBattenberg]

My grid was square purely because it isn't PSX vram, or anything of the sorts. It's an automatic atlas system I use in games to increase rendering speed, it just dumps textures into a giant image. It can be resized however, so I changed it to a 4096x512 atlas now. I'm also drawing it at a different size than it actually is, so it looks stretched in the images.

As it happens, that is exactly what that VRAM image is, as I said I took it from an EPSXE savestate, which is just a direct clone of PS1 video memory as it would be on the system, not loading files into the program. I was using the image to test if the image bounds lined up with the texture pages.

I don't actually plan on using the savestates of the PS1 or it's VRAM at all, but emulating how it works to get the texture pages, as I've done here:


Now you can see the textures as they would be in VRAM, and the actual texture page if you hover over them, exporting these texture pages allows us to use them as regular textures. For me I'll probably just get pointers to the textures and then put them into my atlas system, so I can draw everything without texture swaps.

There aren't items nor objects in MO files. Objects (including secret doors etc) are bunched along with the regular items in 'ITEM.T'. They also use the same database as Items, that's why that image with the yellow and purple dots I posted before looked so confusing, they use the same system but different parameters to say exactly what can be done with them.


I didn't think of using 1034 as a key number honestly, I thought the possibility of a vertex landing there wasn't worth the risk, but after finding out nearly all tiles are between -1024 and 1024, I suppose that's a much better way of doing it than what I was proposing.

The UV's should be fine if you've divided them by 255. As texture pages are between 0 and 255 pixels there's no way there could be any distortion, I think it's literally impossible, or at least I haven't seen any.

[TheStolenBattenberg]

Hopefully this is more interesting to you:

[Holy_Diver]

The UV's should be fine if you've divided them by 255. As texture pages are between 0 and 255 pixels there's no way there could be any distortion, I think it's literally impossible, or at least I haven't seen any.

When you have so little precision for UVs there is bound to be distortion. If a tile goes from -1034 to 1034, then it stretches the texture from end to end. If it's just like a 2 triangle square floor that might be okay looking, however, if there are details or if it is tessellated for lighting purposes, then those little slivers (10) will be distorted, since 1 unit in the UV map cannot account for such a small difference at that scale.

I think if possible it would look much better to show the pages as grayscale palettes, or if you know what palette (CLUT) address they belong to, show them with the real colors. I don't think the rainbow static is of any value. It doesn't represent anything useful. We know they are 4bit images. If some pages are reserved for other kinds of images, then they could default to that kind. If pages 1~5 and 17 through 21 tend to not be used, they can be hidden along with the palettes. (E.g. to make room for a widened display.) I'm curious myself if the palettes are well organized or not. For example, Armored Core has organized palettes, because that's the basis of its Paint system. And games that use palette swap techniques can really benefit from well organized palettes. I'm trying to develop better palette like tools for SOM, even though if you don't like palettes you can think of them as masks instead.


EDITED: Do you think atlases are helpful? I don't think Direct3D 9 or OpenGL ES have portable facilities for work with atlases. If hardware isn't aware of the atlas layout, then it will just bleed across mipmaps unless you use gutters that are super wide, and ensure that the average color of sections in the atlas are approximate. And you lose the ability to wrap the texture. I'm not sure changing to another texture is such a big deal to warrant it.


P.S. I'm so accustomed to SOM I forget that it combines objects/items into one. But I looked a number of the models in ITEM.T and I don't think I ever once came across an object looking one. I will definitely take another look tomorrow. EDITED: I would like to turn my attention to door like objects (although I probably need a break from SOM after I get the next release out the door) but I wonder if their animations are not using the MO.T file, what then?

[Holy_Diver]

Hey, if you are on here before I wake up tomorrow (very likely, I'm going to bed) can you say what kind of TPN numbers you have for the ITEM.T models? Because mine are all over the place, and I'm beginning to wonder if I need to take another look at my code.

I think I remember looking at the RTIM.T files and thinking that they lined up. But for ITEM.T I'm not seeing any patterns. If your TPN values seem to match, please list a few for the first few models in ITEM.T.

Your textures are going to the right places, based on their TIM values. Looking over them, most of them don't have the same addresses, and when they do, they are almost always palette swaps. I've see the moon and clouds have the same address. But they are larger than normal. This suggests they are swapped out unless the address is altered prior to loading. It's conceivable most of the textures fit into memory, except for the odd swaps. It's hard to imagine items doing so though, but not inconceivable. I'm too bushed to scan the entire list in Explorer.

[TheStolenBattenberg]

I think if possible it would look much better to show the pages as grayscale palettes

I'll probably do that. The rainbow effect makes my head hurt, it was just a temporary way to see how it all worked. Makes me wonder how other BPP images work with tex pages though. are 16-bit images limited to 64x256?

Do you think atlases are helpful?

I honestly think atlases are great. Using them with a fixed function pipeline isn't good though, since you're mixing two things that really shouldn't go together, convenience and optimization. I control mine with a shader, by passing the texture 'x div w, y div h, w and h' in an array. That way I can generate/modify the texture coordinates, and since it's done in a vertex shader it's pretty fast too. I don't lose wrap functionality since I can control how the texture coordinates act with atlas parameters, like clamp or wrap or even more advanced modifiers like hscroll/vscroll. It's not really worth it if you're only using one or two textures, but if you've got more than a hundred in one scene it can be a real benefit, and it saves performance for even more shaders.

I think the best thing about them is being able to batch all static geometry into a few meshes, it's great for things like the KF2 tilemaps, since I can put them into chunks of 8x8 tiles and render the scene a lot more efficiently.

I'm so accustomed to SOM I forget that it combines objects/items into one. But I looked a number of the models in ITEM.T and I don't think I ever once came across an object looking one.

My mistake. Unfortunately finding out more about KF2 made some of the old data I'd collected invalid. I'm now 100% sure about both T Files, the texture data and static 3D models. But other data from the past should be double checked before committing to it. This is very much a massive puzzle, where one wrong piece may fit, but it'll make another hundred or so not until you figure out where you messed up.

I'd really like to get some more work done on the MO format, but I can't figure out what you were talking about with the deltas. Would you mind answering a few questions on them? Of course I don't think it will do much good until we figure out the rest of the header, and how exactly it works but it would be another step in the right direction. I'm feeling confident about the reversing so far, with the recent progress; and cracking the MO format really would be a cherry on top of the cake.

I think I remember looking at the RTIM.T files and thinking that they lined up. But for ITEM.T I'm not seeing any patterns. If your TPN values seem to match, please list a few for the first few models in ITEM.T.

Your textures are going to the right places, based on their TIM values. Looking over them, most of them don't have the same addresses, and when they do, they are almost always palette swaps. I've see the moon and clouds have the same address.

It seems to me that the RTIM file within FDAT.T is dumped into VRAM and doesn't get modified. Certain pages are definitely reserved for certain parts of the game, rather than data being all over the place. TPage 31 is reserved for the text images, which I don't think is too important. Honestly I think any good KF2 port would have to be re-translated or at the least brushed up, I think it's a great game but the Engrish drives me insane. Honestly though I can't actually recall seeing that cloud in game anywhere, it might've been intentionally overwritten with the moon.

As requested, unless you meant the texture coordinates, but if you need those for reference just multiply 64 by the index for the x. The Y will be less than 256.

Code: [Select]

TPNs:
Dagger (File_0 in ITEM.T): TPage # 10
Short Sword (File_1 in ITEM.T): TPage  # 10
Knight Sword (File_2 in ITEM.T): TPage # 11

All of the other items are either 10 or 11 as the TPage, and every single texture is stored in memory at once.

Honestly I found that trying to load TMD data by writing out the packet structure yourself never works out quite right, so if you haven't gone low level with it yet I'd suggest it. I've taken to actually splitting the control flags and branching for each property, ever since I did TMD data has loaded a lot more effectively, and the code re usability increases by a large margin, since there's only 4 paths instead of however many primitive types there are. I think it could be made into just two as well. As a bonus, there's no worry of unknown primitives either.

[TheStolenBattenberg]

Okay so I had another look at MO files, and I think, for lack of a better turn of phrase, we're in the shit.

I'm pretty sure now that this is vertex data, but encrypted some how. I've attached a .MO file from KF2, and a .MIM file from KF1 and a file spec I wrote for both of them. They are nearly identical, aside from the fact that .MIM files actually make sense. MIM files are I think chunks of vertex data, as their vertex count matches the size of the data blocks... From prior knowledge of the MO header and the simple to read MIM data, it was easy to analyse and reverse, but as it was an hour job, I haven't figured out every value yet, and the frames still allude me.

If MO is compressed in someway, I don't think we're going to be able to get the data without reversing the KF2 exes, because I have absolutely no idea how to go about uncompromising data... On the other hand, if the MO file isn't compressed, the MIM file will give me great incite on how to load a MO file,  because it seems like a dumbed down version of MO.

P.S:
The MO spec is highly incomplete still, I've only attached it as a reference with the MIM spec.

[TheStolenBattenberg]

You'll have to excuse the music, I find Soundgarden quite appealing and I forgot to mute audio recording on the video capture software:
Video

I haven't bothered to smooth between keyframes, and I think there's still a few issues, but I've managed to figure out FromSofts animation format for KFJ, and looking at the MO format from KF2 again, it doesn't seem too different.

There's no deltas here, just offsets to the vertex data in the TMD to apply rotation etc. There's still a lot to do here, since I'm currently not bothering to load exactly how the animations are played, nor am I applying the data to the vertices in the TMD like I think you're supposed to do...

After spending a while looking at the animation frame data though I think I might've seen these patterns before for Playstation sprite data in another game I've modified. It's possible From Soft just used a provided 2D animation controller on 3D data, because of the early libraries I predict they were using.

[Holy_Diver]

I think if possible it would look much better to show the pages as grayscale palettes

I'll probably do that. The rainbow effect makes my head hurt, it was just a temporary way to see how it all worked. Makes me wonder how other BPP images work with tex pages though. are 16-bit images limited to 64x256?

Do you think atlases are helpful?

I honestly think atlases are great. Using them with a fixed function pipeline isn't good though, since you're mixing two things that really shouldn't go together, convenience and optimization. I control mine with a shader, by passing the texture 'x div w, y div h, w and h' in an array. That way I can generate/modify the texture coordinates, and since it's done in a vertex shader it's pretty fast too. I don't lose wrap functionality since I can control how the texture coordinates act with atlas parameters, like clamp or wrap or even more advanced modifiers like hscroll/vscroll. It's not really worth it if you're only using one or two textures, but if you've got more than a hundred in one scene it can be a real benefit, and it saves performance for even more shaders.

I think the best thing about them is being able to batch all static geometry into a few meshes, it's great for things like the KF2 tilemaps, since I can put them into chunks of 8x8 tiles and render the scene a lot more efficiently.

Assuming the pages are just what addressable by polygons, if the texture is spread across adjacent pages then the UVs can sample outside the first page. But you've sown some doubts into me about how the UVs work with regard to the color mode. I think I've only just divided 255 by the width of the texture, since that works with MDL. But with TMD the size of the texture is not knowable. So I wonder if the meaning of 1U/V unit changes in 4-bit mode, etc. I've programmed a TMD loader, but left UVs with their raw values, and until now I've never worked with TMD+texture, so I can't really say. I have what looks like a Sony manual, that I can give you copy of. I should probably go over the UV section sometime...

Bottom line is if 1U is 1 pixel, then for 4-bit that is 4 pixels per 2 bytes. For 8-bit, 2 pixels per 2 bytes. I don't see how this is a problem, except that the range is 0~255, so a texture can never be more than 256 pixels. I would not guess this changes for 4-bit indexes, but I don't actually know. I think MDL must know the texture's dimensions, but I think the PlayStation doesn't care. But I don't know. MDL may be a bastard format. Or it may be reflecting some PS texture addressing policy that I don't know about.

As for atlases... yes I suppose if you pack wrapping coordinates in every vertex you can simulate wrapping, but at what cost? And it doesn't change mipmapping. I wonder if your projects don't take advantage of mipmapping/anisotropic filtering, which is basically what makes graphics appear uniformly solid today. I'm sure Direct3D 10 or so does have advanced atlas support, which just boils down to loading groups of textures into memory simultaneously. However it's certainly possible to develop custom mipmap levels, that do not bleed together, and stop short of final levels where the individual images become single pixels.

Strikeout: on second thought, I don't see how this can work... yes it can sample one pixel, but wrapping works by interpolating the corners of the triangles, and this will breakdown in most cases, and would require great care in others.

With graphics today you are probably fill (pixel shader) bound, and optimizing texture load/stores is probably not going to improve that. I think it's foolish to push the hardware to its limits. You want to work in a space where you are using about 25% tops. Dancing on the edge of a cliff is an idiot's game, and is certainly not of any form of artistic merit.