PNG alpha channel: yes I think it might, but it needs some experimentation

Corner bug: you sure you don't have an old copy of Glide2x.dll hanging around, maybe in your Windows folder? I can't see anything wrong here... unless its in the capture itself: presumably you'd have noticed if the captured textures had white corners?

Nope, the only Glide DLL I have is the one from Glidos 1.25, which seems to be 0.09rc6. The small white lines in the corners are not part of the captured textures. (Actually they're not always white, their colour is sometimes light brown, grey, black...) It seems the only textures affected are the 64x64 ones (whatever their colour depth). Not sure if that's relevant though.

Sure its not the transparency bug then, just happening to show on a corner? Try putting a bright green border around the crate texture. See if... I'm grabbing at straws aren't I.

Oh yeh, and I did upload v1.25 twice, the first time with an old version of Glide2x.dll. Its just possible you picked up your copy inbetween the two uploads.

Do you see the corner bug when using the TRX textures?

I downloaded Glidos again, just to be on the safe side. The corner bug is still there. I made a battery of tests and, following my legendary instinct, I'm now almost certain it's related to the size of the texture (colour depth doesn't seem to matter).

I took a standard texture (the crate) and tested it in a number of different resolutions: 256x256, 128x128, 32x64, 64x32, 32x32, 64x64 (the original one, and one resized from 256x256). All of them display correctly, except for the 64x64 ones (both of them) which display a small white line in the lower right corner (as I said, it's not always white -- pressing F4 repeatedly sometimes changes the colour of the line, it may be grey, light brown, etc).

My own custom textures aren't affected since none of them are 64x64. I took one of them, resized it to 64x64 and, you guessed it, the corner line appeared. Incidentally, I checked the main textures of TRX and none of them are 64x64 either. The solution would be simple: don't use any 64x64 custom texture! 😁 Though it doesn't fix the bug per say, and as a developer I'm sure you'd want to discover the real cause of it...

For the record, I made some further tests with GlideWrapper and there's no corner bug on 64x64 textures. It has to be noted however that GlideWrapper doesn't seem to recognize the 96-64-32 colour as a transparent colour (thus everything that should be transparent is brown). Not sure if that can help.

You know as much as I do 😕

My crazy theory is gaining some credibility! I resized a snow texture in the TRX package from 256x256 to 64x64 and here's the result:

I think you could send some 64x64 textures to Glidos as that might help you both to understand each other better 😀

64x64 specific? That's going to be an interesting one. I've got some idea what would cause something like that.

I've tried to install the Textures to no avail at this point and i was wondering if anyone had any suggestions
I have set the game display to normal. F4 doesn't do anything, except cause the game to stutter. The textures do not change My levels are dated 11/5/1996. I have glidos 1.25, VDM sound, and used the tr1 advanced installer.
Any help would be much appreciated

Have you added the line

TextureOverride: Yes

to the glidos.ini file?

Yes, i've updated the glidos.ini file

set display to mipmapping, not normal

also make sure textures are in glidos\textures\ folder

Not sure if you have tackled the 'corner bug' yet but I have a couple of observations about it .

1. It never seems to happen with modified textures ( for me at least ) only with the original textures. I have tested it with two versions of TR , (an old one (probably the original release ) and a newer one that has all the 3d patches included as extra folder on the disk) and gotten the same results .

2. It only happens to the (original ) textures the first time they are called up . if you switch between mipmapping and normal a couple of times then the holes disappear.

3. they are holes . They are sections on the texture the game engine is cutting out as if they were the dreaded brown color . when veiwed without the holes (after switching from mipmap and back) there is a noticeable discoloration in that same location ( on every 'original' tile) . it looks kind of like a white rectangle that smears throught the spectrum as it drops off the bottom of the texture .

One thing to consider ( maybe ?) is that I am using the mipmap textures as my hi-res textures instead of the normal textures . I don't think that would make a difference but one never knows .

At any rate to be clear , I encountered the same problem as some of the other fellows , i.e. when using texture captures the game absolutely refused to use some of the modified textures ( notably some of the ones on the page for lara's front side) , but I noticed that if you did your captures when the game was set to "mipmapping" instead of normal it captured the same exact textures but stored them in different memory folders . for example the texture set (from the Lost valley level 3a) in the folder Ba8fab4....(etc) contains the exact same textures as the folder B689935.......(etc). the only difference being that the BA8fab4 folder was captured under normal , while the B689935 folder was captured under mipmap .
So the short of it is that the game will play back modified textures from the mipmap folders with no problem even if it will not play those exact same textures back from the normal folder .
The plus of it is (for me using the mipmap captures)that "normal' remains game original , and mipmap contains the hi-res . Also the floor and wall textures load fine from both places so doing it this way allows one to quickly switch back and forth between two sets of test textures .

Don't know if any of that helps at all

( p.s. glidos does not work (with TR at least ) if you have sci-tech's Gldirect installed on your box )

Er,looks like I forgot to log in, that last post was from me , so blame Rild for anything in that rankles. 😉

All interesting stuff. Sounds like the corner bug is down to a few pixels not being set, and having the previous memory values left there. Initially the previous values are the special transparent colour, but after a few F4s they are overwritten with something else. I will try to have a look at that.

The difference in capture folder between TRs mipmapping and normal setting is to be expected, and I'd also expect a slight difference in the captured textures. Not sure what difference, but some slight difference. My intention was always that capture would be done in normal mode, but I guess it doesn't matter, so long as people don't try to mix textures from the different modes.

Actually I am quite happy about having the mip captures and the normal captures going into there own private folders , er , but about crossing the streams and mixing the textures....

if you do a run through capture on normal and then run throught the same level again on mip , glidos just puts all those folders into the capture file together and if you rename it textures and run it it seems quite capable of switching between the two sets of folders without any problems .

Near as I can figure there is very little or no noticeable differenece between the mip captures and the normal captures (though, in game , I have noticed a very slight coloration difference on small clusters of pixels in certain mostly light or mostly dark textures) , and actually I have switched them back and forth (moved files from the normal folder into the corresponding mip folder ) a lot . The only irregularity I have found is that occasionally a texture gets , how to say it ? smeared (the textute resembles something a TV would produce if the vertical hold was out of sync) , but this is pretty rare and so far has been ( I think) related to me not cleaning up the transparent brown color.

After a little experimentation I found that one can smear a texture containing the transparent area if the transparent area ( that brown ) contains a number of scattered isolated single pixels in it that are nearly identical in color to the 966432.
( I first noticed this as a frustrating event when trying to paletize transparent things, PSP7 kept changing the solid brown colors and the resultant solid+single scattered pixels color caused the transparent textures to smear )

if your interested I'll try to find somewhere to paste up a couple of images of the texture smearing so that I can show them here .

But back to the corner dealio ...

I have a bit of an correction , or addendum to that eariler post :

I still have not seen it happen on new or hi-res texrtures or modified textures ( like simply making the old textures 256x256 and 24bit ) , but everytime I have seen it happen has been when there are a mixture of new textures being displayed at the same time, though it seems somewhat intermitent , so I would tend to agree with your analysis about a memory artifact ( there is more on this in just a second ) .

here is the correction to my eariler bit :
If the corner bug is not present right away somtimes flipping between modes ( mip/normal ) will cause it to appear and in these instances it will not go away (but it still does not effect modified textures) .
sometimes the initial corners are not cut-out but instead are kind of a blue white flipping F4 causes these to dissappear too , though I have not been able to ascertain if they will randomly pop up later when they are not an initial condition .

now the bit about the memory correspondes to some screen weirdness
I experience sometimes with the in-game (not start-up) title screen background and sometimes when exiting glidos ( I say sometimes because it is an intermitant thing )
My screen is full of artifacts everywhere ( they resemble the artifacts you get when you have bad video memory or have pushed your vid cards memory too far by over clocking it ). the artifacts resist a plain old windows screen refresh and will persist as I open new aps , But if I start Mad Onions 3d mark 2001(not run the program just get to the initial menu screen ) it clears all the artifacts .

So I can pretty safely assume that ther is definitely some memory artifacting going on somewhere .

I hope that helps some , I just want to make sure that you know I ain't complaining just trying to help a bit . By the way glidos is an excellent app thanks a million for creating it .

thanks again and keep up the excellent work 😀

One other thought occurs to me and is somewhat related to the way textures are placed in TR .

The corner thing might have something to do with how the textures are tagged to thier corresponding polygons . Alot of the textures seem to be placed sloppily , but a close examination of them reveals that they are actually being placed on the "inside" of the polygon . Lara's belt front is a perfect example of this .

after working with the textures for a while it is obvious the original TR team created the texture designs to work around this exact problem ,

What does this mean, to be placed on the inside of the polygon? Is the texture reflected?

Some thing I noticed is that sometimes a square texture is placed on a distorted square (a trapezium to be precise). This causes the texture to display in a distorted way, as though pulled across one of the diagonals. If you run into that problem, I know how to preskew the texture so as to exactly counteract this problem.

Mmm, have you browsed through the previous pages of this thread? According to my own experimentations, the 'corner bug' is only triggered by 64x64 textures (no matter what their colour depth). You don't see it on your custom textures simply because you're probably using 256x256 tiles.

About the corner artifact disappearing when switching between normal and mipmap modes: well, actually the corner glitch doesn't disappear, it only changes its colour according to the textures your camera is pointing at when you press F4. Give it a try and you'll understand what I mean.

As for the issue about some parts of a texture becoming transparent (even when 966432 is not used), it's due to Glidos downsizing a 24-bit palette to a 16-bit one. A whole range of close colours (16M/65536=256 to be exact) are reduced to only one. Ie, if you happen to use, say, a 966431 colour in your 24-bit texture, chances are it will be converted on the fly to 966432, which is the closest match in a 16-bit palette. This shortcoming should be worked around when OpenGlide and Glidos support 24-bit internally.