wrote:And, if I now have an equiv file for the entire game, doesn't this make LINK files somewhat redundant?
Yes, the equiv file is a big improvement on link files. In some ways its like a set of automaically generated link files, but better because it is independent of mapping style.
wrote:If link files are redundant (in terms of pointing to a duplicate texture), how does the image assignment work? Where do I put my texture?
Exactly where you put them now, except that many are no longer needed.
wrote:If I replace Lara's eye in level 14 and supply the equiv file, I assume the new eye appears in all levels? How about if I place it level 2 instead? Does it matter where -- is Glidos looking in all folders for the image and then using that in all EQUIVVED folders? Isn't that inefficient?
You can put it in any level. I believe the way it works is fairly efficient, provided you don't put unnecessarily repeated textures in several levels.
wrote:Trying this out with a complete set of captured folders, and I can't get anything at all. […]
Trying this out with a complete set of captured folders, and I can't get anything at all.
I have a simple mapping file in my textures folder. Just has this as contents:
GLIDOS TEXTURE MAPPINGROOT: F:\Projects\Tomb Raider Xtra\Captures_TR_COMBINED\
Ah, that probably wont work. If you use mapping files at all, you have to put the mappings in explicitly, even if its just a whole list of identical pairs
A45FC9D43C39AA73B A45FC9D43C39AA73B68AE00C45892B8C8A 68AE00C45892B8C8A
Those are not real examples (names not long enough) but you know what I mean.
wrote:If link files are redundant (in terms of pointing to a duplicate texture), how does the image assignment work? Where do I put my texture?
You can still use link files if you like, but the only point in doing so is to map nasty names to nice ones.
wrote:1) A duplicated texture must be in the first folder specified in a beginEquiv/endEquiv block
Nope. Any one will do.
2) All other copies of the texture must be deleted to avoid graphical weirdness
Yes. Bad to have unnecessary copies. Could run your video card out of texture memory.
3) Equiv files seem to ignore root mapping files -- major problem!
Equiv files are independent of anything that appears in the mapping files.
Are you saying you'd expect the equiv file to be read from the root?
So, in reality, equiv files are useless for stand-alone level releases. I'm now not sure how to manage this.
If it is important to you that a release for one level has no texturing affect on any other level, then yes, useless. But I don't see why that is a requirement.
How do we make a stand-alone release compatible with a future "massive pack" that has multiple levels textures and would make use of an equiv file?
You - for example - create the pack for Vilacabamba by using the caves level, plus the equiv file, with as few additions as possible. You can also delete any images that are not used by Vilacabamba to keep the new level as small as possible. When a user installs both levels, all common files will be overwritten.
wrote:Another observation based on quick perusal of the captured folders created by the new .phd extracting tool: Some textures are not extracted
Ah, that's a bug then. What textures are missing? (just a few examples).
while others that are not required for a given level ARE extracted (for example, Lara's track suit from the house level appears in the complete BMP for lots of levels but is never used).
There will still be significant cleaning up I feel.... 😉
What you want core to clean up the .phd files? 😁 I'm afraid the format of the textures in the file does not include a "never used" bit.
Thanks for all the answers. I'll need to re-read all this over the weekend... still confused! 😉
But:
Yes. Bad to have unnecessary copies. Could run your video card out of texture memory.
I think I nearly experienced that -- it took *ages* to load a level with the full game equiv file as obviously it was loading all the copies. How do propose we manage to delete all the duplicates? This would be a huge manual task. Is there a way you could use the equiv file as a basis for a 'clean up' script/tool?
wrote:Ah, that probably wont work. If you use mapping files at all, you have to put the mappings in explicitly, even if its just a wh […]
wrote:Trying this out with a complete set of captured folders, and I can't get anything at all. […]
Trying this out with a complete set of captured folders, and I can't get anything at all.
I have a simple mapping file in my textures folder. Just has this as contents:
GLIDOS TEXTURE MAPPINGROOT: F:\Projects\Tomb Raider Xtra\Captures_TR_COMBINED\Ah, that probably wont work. If you use mapping files at all, you have to put the mappings in explicitly, even if its just a whole list of identical pairs
A45FC9D43C39AA73B A45FC9D43C39AA73B68AE00C45892B8C8A 68AE00C45892B8C8AThose are not real examples (names not long enough) but you know what I mean.
Well, I tried it this way and it still doesn't work. Are you sure that when using EQUIV files the root mapping file is being parsed? It seems like it's ignore which now makes things very difficult.
OK, well, I don't know what was going wrong before with my whole-game equiv file.
I just tried a simple test with a couple of folders and just uisng a simple equiv file to share a passport image between the Title and the Caves. This worked fine both with the folders copied into the Textures folder and also using them on another drive and a root mapping file pointing to them.
I think the reason this didn't work before is that I hadn't deleted all duplicates.
I am still uncertain the best way of managing this on a level-by-level basis. Some things that spring to mind:
1) To manage the duplicates requires a fair bit of effort -- it seems it would be eaiser to texture the whole game in one go!
2) An equiv file of anything over a few definitions becomes difficult to manage because we don't know what folder/image name corresponds to an actual image. We would need to
a) comment the equiv file with notes about what image each block refers to.
b) then, we need to constantly refer to our folders and manually delete duplicates
c) and for this to work, you have to keep track of all the dependencies so that if you have deleted the passport from all the GrecoRoman levels for example, the user MUST install the peru levels first.
I am not keen on any of (2)!
Am I simply making things too complicated?
Forget the above, I've found my own way of doing this.
However, I need some help. I have version control problems with my own packs!
I have a equiv.txt for my entire extracted set of graphics. I've put my new letters in to the title pack and the equiv file handles remapping so that the letters show up in every level. However there are discrepancies. The lowercase "i" and "l" do not work in some later levels -- the old images are being used, in St. Francis Folly for example.
I've checked the equiv file by searching for the relevant mapping between the title and the folly -- the equivalences are there OK. I also opened the original bitmaps from both levels in Photoshop and performed a difference blend and they are both exactly the same, as one would hope.
I've removed all TLNK files for my letters and I don't even have a folder for the folly yet, so I have no idea why this won't work.
Any advice/tips?
Further investigation reveals that the letters not working are the three that we doubled in width: "i" , "l" and "1".
The only levels that show my correct images are Title, Caves and Vilcabamba.
Duh! As you were.... I had missed some old captured bitmaps in my Vilcabamba folder that were overriding the new replacements... it's all fine now.
Well done. You sorted it. I would have tried to help, but I've been away this weekend
