First post, by GoldFinger

User metadata
Rank Member

Hey Paul,
Since you were the one who did the TexDB class can you explain exactly how it work?
I was going through it and found some strange things:

bool TexDB::Find( ...
Record * r;
FxU32 sect = startAddress / ( 32 * 1024 );

if ( sect >= TEX_SECTIONS )
sect = TEX_SECTIONS - 1;

As I understand you have divided the Glide memory area in 32k chunks, right?
If this is true, there is one funny stuff, since TEX_SECTIONS is 256:
32 x 256 x 1024 = 8 megabytes
that means that the performance of this method above 8MB is not too good. That may be one of our problems when enabling 16MB memory on some games (RB3D?).
I think that we should use a dynamic vector here like the STL vector template, it is fast and reliable.
Of course I can be very wrong as I did not go through all the code yet... 😀

Another thing is the vertex snapping thing, we should fix that soon.

Reply 1 of 2, by Glidos

User metadata
Rank l33t

Well spotted! I did sort of know about it, but since it didn't affect correctness, only efficiency, and I wasn't quite sure how best to fix it, I left it how it was. I'm thinking now that maybe, for such a small array, we could just make it miles bigger than needed.

The STL vector template may be just what we need. I'm afraid I don't know much about STL, so I can't really comment, but it sounds like the right sort of thing. Certainly, the point of separating out this part of the code into a class of its own was so that at a later date someone could put in place a more efficient implementation.

Oops, nearly forgot you asked how it works. The idea is that it keeps track of the memory intervals for which you have already made OpenGL textures. It is needed so that, for one, you can find the OpenGL textures again when you need it, and also so that you can throw away OpenGL textures when the memory they shadow is overwritten. My first version just kept a linked list of intervals, but later to improve efficiency I broke the single linked list into several lists, one per 32K chunk of memory.

There's a complication in that for paletted texture formats you might keep several OpenGL textures for a single Glide texture, but you might not (if you are using the paletted texture extension). Hence "Find" has to deal with being asked for either a match with the right paletted or a match with any palette. When you ask for a match with any palette, the caller of Find does need to know whether the palette matched or not. I deal with that by passing in a bool pointer. This is used as an out parameter to say whether the paletted mathced. If you pass NULL, then this is taken as meaning you want an exact match.

Sorry that isn't quite right. The things stored aren't just intervals; there is also info about what type of Glide texture is contained in the interval.

If I remember rightly, there are three main methods in the class. Add is used to store one of these interval-like things and return a newly allocated OpenGL texture name. Find is used to retrieve ones that have been previously added. Wipe gets rid of all the intervals that cross an area of memory, and destroy the associated OpenGL textures. Wipe is called every time a Glide texture is downloaded because any OpenGL texture that shadows a part of the downloaded area is out of date.

I suppose really it is a database of OpenGL texture names indexed by Glide texture descriptions (GrTexInfo), but with an intelligent wiping feature.

Reply 2 of 2, by GoldFinger

User metadata
Rank Member

Well I commited the modifcations on the texture stuff, I am not using the vector class but rather a dynamic vector pointer... 😀
You will see, this way we can remove some of the verifications but I did not do that for now, as I need more tests, please try it out.
Try Unreal and others in window mode too, I tryed Unreal, Unreal Tournament and some demos and they all worked better with the window resizing.