Antonijadis wrote:

Yes it's works! 😁 Well nearly. 😒 Some textures didn't be copied. 😕

Which textures? See if they are listed together in equiv.txt. It may be that the textures are very similar but slightly different. e.g., there are two versions of a door in Vilacabamba. They differ by just a few pixels.

For cases like these, you can add extra lines to equiv.txt by hand.

Antonijadis wrote:

One question: How I can replace some textures that I don’t won't to look identical in every level?

Yes, but then you need to remove lines from equiv.txt by hand, or edit the textures in your capture folder to make them different. All gets a bit messy then because different authors will have different requirements. I haven't sussed how we should deal with this case yet.

I start with St. Francis Folly and Coloseum levels. Just few textures are copied from one to other. For example textures of the lion and gorilla didn't been copied and textures of the Pjer has been copied just halfway. The other textures has been copied just in 20-30%. 😠

Yes, but can you find out why? Are the textures different, or is it down to bugs in the tool or new Glidos?

Also, is your Capture folder complete for those levels?

If the textures are slightly different, you can copy one over the other in the capture folder, and rerun the tool.

Alternatively, you can edit the equiv.txt file by hand.

Glidos wrote:

Alternatively, you can edit the equiv.txt file by hand.

It's easy for 256x256 textures, but for little one texture like that for lion what difference make toward the mapping way. 😢

Certainly this wont be as useful as I hoped if TR is texturing common objects differently per level, but you still get the advantage that anything you do in the equiv file will work for all texture packs, independently of the author's folder managment.

Still seems surprising to me that the textures should be different. Have you confirmed that?

Also remember, if you don't run through the level far enough to see a lion, then the lion textures wont get captured.

There are three ways this can fail, and we need to find out which:

1) The textures that seem alike may be actually slightly different

2) The generator tool may have bugs, and not be logging all occurences of
common textures.

3) The new version of Glidos may be incorrectly using the equiv file.

O.K. Now it seems just fine. 😀 I do recapture of the levels and rerun "GenEquivMap". Things are work much, much better now. Not all textures has been copied, but most important like enemies tex., Lara tex., weapon tex., has been copied at all! Few textures ( 256x256 ) aren't goes thru equiv process. 😦 I don't know why is that. Anyway this gonna be great stuff Paul. Can't wait to moving smoothly with this. 😘

One more thing. Can you fix that png file have an priority over bmp file?

That's good news. Sounds like there will still be a need to fiddle manually with some textures, but this will at least save a fair amount of time.

Sorry, I don't understand what you say about 256x256 textures.

Also not sure about png prioritised over bmp. If you have a texture pack which includes equivalent textures, then probably you should delete all but one.

Glidos wrote:

If the textures are slightly different, you can copy one over the other in the capture folder, and rerun the tool.

Alternatively, you can edit the equiv.txt file by hand.

Actually, what I'm suggeting there is a bad idea. It will mess things up when you try to add in capture folders from later levels or other TR versions.

The thing to do is build up a separate little hand written equiv file, listing just the textures you've noted as being the same, although they have very slight differences. I can update the tool to combine this little equiv file with the one generated from the capture folders.

Glidos wrote:

Sorry, I don't understand what you say about 256x256 textures.
Also not sure about png prioritised over bmp.

I just wont to say that some "large" textures (256x256, 128x128 etc.) didn't been copied. For example: 3950CED5E8A35F99502BDFB595EC5F8A-(192--256)(64--128),but I think that's not for big worry because that textures can be easily find and replaced.
About priority of files: there is need for easy visual comparison between bmp and png so I think that while the work of the retexturing is in progress, the capture and textures folder should bee the same one ( I just change the name of the folder when I need capture or textured).Till now the png has priority( you don’t need to delete bmp to see what you made),but now glidos put down bmp file instead png.(if there one of course).This not happened for the level thru witch glidos was runed.

Oh I get the priority thing now. That's actually quite awkward to support now. And using the Capture folder as the initial Texture folder may be why you are seeing some textures not carried over.

Is there another way to work? Could you have both Capture and Texures folders open symultaneously?

With the large textures that seem to be missing. Its worth checking if they are actually slightly different between levels. I find if you bring both on screen together, and then go cross-eyed to superimpose the images, you can see slight differences very easily.

Glidos wrote:

Is there another way to work? Could you have both Capture and Texures folders open symultaneously?

Or each time you add a png, could you rename the bmp slightly so Glidos wont find it?

Paul, would it be possible to adapt the tool generate an equivalence file from a comparative analysis of the complete.bmp's rather than all the itsy bitsy textures? This would ensure that everything gets caught by the process and it would be much simpler to share just these from the different versions.

Wish I could, but no.

Well I could right a program that did it, but I guarantee it would run until the end of the universe before giving its results.

another way to check for slight differences between textures is to load them into whatever graphic program you use and overlay one atop the other as a new layer. Then simply click the visibility of that layer on and off ( rapidly is probably best ) . any differences will pop right out as if they are flashing.

Paul even if this mod only helps eliminate the need to handmake for every level all the lara/letters/menu/passport, etc links , I thank you in advance 😀

er, with this new tool/develpoment do you still need the capture files ?

z9d10 wrote:

er, with this new tool/develpoment do you still need the capture files ?

Yes, sorry, I can't see a way to avoid that. On the other hand, its not that bad to capture a level when compared with the process of retexturing it. And for the multiple versions of the game, we can get users to do the capturing.

OK... I am absolutely astounded! I had almost finished reworking Colosseum so I ran the gadget over my capture folders for the 3 levels Folly, Colosseum and Midas...I have just played Midas and it is almost completely retextured! It almost feels like somebody else did all the work! I'll need to do some tweaking, but this is minor compared to the hours saved! You are a magician Paul!

Woo hoo! So it is working. 😁 This is great if it save you from the drudgery and frees up your time for the artistic part of the job.

Glidos wrote:

Or each time you add a png, could you rename the bmp slightly so Glidos wont find it?

For now this could be a solution.
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?