OK, I really need to find some time to try this, might inspire me to get working on texturing again...

Then again, real life is currently far more interesting. (read: women) 😉

Antonijadis wrote:

Next problem is when you rerun equiv.tool all the changes that you made will be lost. Can this be solved with the update that you mention?

Yes. I posted later that my suggestion that you alter the Capture folder or the equiv file was a bad idea.

If you want to add equalities that the automatic process misses then just put them in a separate equiv file on their own. I'm in the process of writing a tool that will combine your own equiv files with the automatically generated ones.

Gambit37 wrote:

Then again, real life is currently far more interesting. (read: women) 😉

No, terrible things. 😁 Be faithful to Lara.

Glidos wrote:

Yes. I posted later that my suggestion that you alter the Capture folder or the equiv file was a bad idea.

If you want to add equalities that the automatic process misses then just put them in a separate equiv file on their own. I'm in the process of writing a tool that will combine your own equiv files with the automatically generated ones.

Ooo, great man! 😘 You always get a solution. 🤣

Women? Never heard of it. Is it available on the PS2?

Women? Never heard of it. Is it available on the PS2?

yes, but even the minutest irregularity in the disc causes it to behave irradically , the load times for any changes in game play are HUGE , and there is an irritating bug in the game that causes the sound to almost constantly make extremely irritating noises. PLus when you even look at other games , Women may refuse to operate at all .

The task is a little harder than you realise.

possibly, but the key to being lazy is being sneaky 😉

We need capture folders for the entirety of each game version. I think we are going to need to get help with this.
...Yes, sorry, I can't see a way to avoid that. On the other hand, its not that bad to capture a level ...

hhhmmm, if the complete texture rectange is mapped as a superset of the individual texture rectangles then each (per level) .phd data folder then the individual texture co-ords ( for each individual tr version)is fixed ( only the folder name that contains them changesin glidos) and must contain a hard coded map key that TR uses to find specific textures . My thought was that it might be possible to extract this map key from each .phd file in lieu of doing and transfering the dissassembled texture captures .

z9d10 wrote:

hhhmmm, if the complete texture rectange is mapped as a superset of the individual texture rectangles then each (per level) .phd data folder then the individual texture co-ords ( for each individual tr version)is fixed ( only the folder name that contains them changesin glidos) and must contain a hard coded map key that TR uses to find specific textures . My thought was that it might be possible to extract this map key from each .phd file in lieu of doing and transfering the dissassembled texture captures .

No the strange keys are created by Glidos. All that TR sends to Glidos are the textures that you see as Complete.bmp. Glidos analyses the texture data and creates a key for each.

Also the co-ords of the subtextures are not fixed. The problem is that the TR level editor, used by Core when building TR, collects all the little textures into the big squares, and does so differently for the different TR builds. So it isn't even the same partitioning of subtextures into large ones.

z9d10 wrote:

My thought was that it might be possible to extract this map key from each .phd file in lieu of doing and transfering the dissassembled texture captures .

Somehow I'm starting to find myself really liking this thought of yours. 😁 Maybe its possible. If the 256x256 textures are actually in the .phd files, then I think you are right that a list of the coords of the subtextures will be in there too. But it might be that the 256x256 blocks are formed only for driving Glide, so it may be the voodoo version of TR that is packing the textures into blocks.

If the level editor is open source, I'll take a look.

Here's a new version of the tool. This one can combine two files. E.g., here's a file that says the two very slightly different versions of the door in Vilacabamba should be considered as identical.

1GLIDOS TEXTURE EQUIV
2
3BeginEquiv
47E5129F80DD26B3F59CEA33D1BFC2AC2\(64--128)(192--256)
599A9ECC11E164D754899E5F069ADA6AC\(128--192)(192--256)
6EndEquiv

The idea is that you keep a little file like this where you record textures that aren't the same but you think should be. You can then at any time combine it with one that has been autogenerated from a Capture folder.

z9d10 wrote:

My thought was that it might be possible to extract this map key from each .phd file in lieu of doing and transfering the dissassembled texture captures .

Here ya go:

Great, er.....how does it work?

er... you mean "how should you use it?"?

Yes! (sorry!)

Select one of the .phd files on your TR cd, using the top browse button. Select a folder where you want a Capture subfolder, using the second from top browse button. Then press the capture button, and you get all the .bmps as though you'd played through the whole level with Glidos in capture mode.

wow!!! You are totally amazing! 😀

This is excellent idea z9d10, and Paul doing a god job as always of course. 😎 When we see this I wonder is there possibility to do this with .rpl files and is there possibility to allot them a better resolution.
Paul what are you doing about connection of two equiv. files?

I think I have a description of .rpl format somewhere, but what were you thinking we could do with them?

The tool has a facility for joining two equiv files. That's described in an earlier post... or were you thinking of something else?

Glidos wrote:

The tool has a facility for joining two equiv files. That's described in an earlier post... or were you thinking of something else?

Yes, but this isn't work like I imagine. Let me explain you. When I combine two equiv file (old one who has been modified, and new one who has taken from capture) I gat totally mixed texture. Can I get this: the line that was deleted from old equiv file to not appear in new one, and the line that was add to old one to appear in new eqiv file?

Glidos wrote:

I think I have a description of .rpl format somewhere, but what were you thinking we could do with them?

I just wonder Is there any manner to improvement the fmv?

The joining facility is intended only for one type of use. It is just for handling the case where you notice some textures that are slightly different, but should be considered the same. You can make up your own little equiv file, which says which differing textures you want to consider as being the same, and join it with an automatically generated one.

If the automatically generated one says e.g.,

1BeginEquiv
2TexPathA
3TexPathB
4TexPathC
5EndEquiv
6
7BeginEquiv
8TexPathX
9TexPathY
10TexPathZ
11EndEquiv

and your little one says

1BeginEquiv
2TexPathA
3TexPathX
4EndEquiv

then the joiner knows that this implies that they are all the same, so you get the result

1BeginEquiv
2TexPathA
3TexPathB
4TexPathC
5TexPathX
6TexPathY
7TexPathZ
8EndEquiv