While playing JCs combined Peru & Rome packs, I noticed that on some later levels, there is a tendency for the passport textures to be 'forgotten'.
For example, when I die in St. Francis Folly and the menu ring pops up, I see the new red passport cover appear, but just before the passport opens and the save games are shown, the red cover vanishes and the old black passport is shown.
I tried this with my own equiv file which is currently mapping the passport to all levels and the same thing happened.
Is this a problem texture memory? The Equiv file? Duplicates (of which there aren't any in both these cases)?
I noticed in the changes.txt file for version 1.31 this comment:
Improve texture caching, making it less prone
to drop textures and making it handle badly
defined texture-space rectangles. Befo […] Show full quote
Improve texture caching, making it less prone
to drop textures and making it handle badly
defined texture-space rectangles. Before this
change Descent II sometimes crashed or
took minutes to print the menues under
Windows 98.
My own repeats file is quite large as I still haven't removed a lot of the sprites and icons from the second level, but none of the repeats are the passport. Would any repeats AT ALL affect this texture 'forgetting'?
Also, I'm a bit confused by the format of this repeats.log file -- it doesn't seem too useful as is. Wouldn't it be better to avoid the manual cross referencing and pump out all the relationships for a given texture together?
For example, the first and last entries in JCs above. These are clearly the duplicates. I think a more useful format would be:
EDIT: Somethings wrong with this as those two graphis are completely different! Either one replaces the other without JC realising, or JC has in fact edited the equiv.txt file to handle it but the changes aren't picked up by the tool?
My own repeats file is quite large as I still haven't removed a lot of the sprites and icons from the second level, but none of the repeats are the passport. Would any repeats AT ALL affect this texture 'forgetting'?
I think there are two issues.
If repeats give paths to two distinct texture files, then the choice between the two may alternate through a sceen.
If there are a great many repeats then you can run out of graphics memory. I wouldn't expect this latter issue to cause problems with just a single texture.
Gambit37 wrote:
Also, I'm a bit confused by the format of this repeats.log file -- it doesn't seem too useful as is. Wouldn't it be better to avoid the manual cross referencing and pump out all the relationships for a given texture together?
Yeah, I was aware that the presentation informs you of repeats but gives little help in tracking them down. This feature of the tool was just what was possible via my existing interfaces. It may be quite a difficult task to improve it.
Gambit37 wrote:For example, the first and last entries in JCs above. These are clearly the duplicates. I think a more useful format would be: […] Show full quote
For example, the first and last entries in JCs above. These are clearly the duplicates. I think a more useful format would be:
Sorry, I'm feeling a bit thick today: how should I read that?
Gambit37 wrote:
EDIT: Somethings wrong with this as those two graphis are completely different! Either one replaces the other without JC realising, or JC has in fact edited the equiv.txt file to handle it but the changes aren't picked up by the tool?
The tool would not miss the changes. It has no built in knowledge of the equiv files.
Gambit37 wrote:For example, the first and last entries in JCs above. These are clearly the duplicates. I think a more useful format would be: […] Show full quote
For example, the first and last entries in JCs above. These are clearly the duplicates. I think a more useful format would be:
Dang! I thought I'd got rid of all dupes...how did they creep back in? I'll have to go and investigate....! I get the vanishing passport thing as well btw!
The weird thing is that they are different images for different locks, so you must have had the intention of making them unique. Guess there's a mixup in the equiv file somewhere?
EDIT: Somethings wrong with this as those two graphis are completely different! Either one replaces the other without JC realising, or JC has in fact edited the equiv.txt file to handle it but the changes aren't picked up by the tool?
The tool would not miss the changes. It has no built in knowledge of the equiv files.
Based on the output, it's clear the tool reads the equiv file and any mapping files to work out the duplicates. Is there anything else I should know about how it works?
After resolving JCs duplicates, this problem still exists.
It's weird because you see the new passport initially, then the old one appears -- and when you escape out and the passport closes, the new one comes back again!
It concerns me that this could affect other textures and compromise our ability to re-texture the entire game. Anyt thoughts on what's going on?
I don't believe it! Noooooooooooooooooooo! Not a bug in Glidos! It's my favourite thing ever and I thought it was perfect. You have shattered the illusion.
In some of the levels, there is 1 PIXEL different on the passport cover. Took me a while to discover it, but boosting the brightness in Photoshop and setting the difference on the two versions of the image revealed it.
To fix it in an equiv file for game version 1 (PHD files dated 25/10/1996) do this:
Find this block in the equiv file and cut it to the clipboard:
In some of the levels, there is 1 PIXEL different on the passport cover. Took me a while to discover it, but boosting the brightness in Photoshop and setting the difference on the two versions of the image revealed it.
Nice one Gambit.
Gambit37 wrote:
Find this block in the equiv file and cut it to the clipboard...
What you describe is exactly what the combining tool does. So you can get the same effect by picking any line from the first group, and any line from the second, e.g.:
