Well, I just changed the vector back to a Record ** pointer, can you test it in RB3D and others and do a Beta release?
I want some feedback on how fast it is.
I am working on the mipmap stuff and I will see how to speed up the direct buffer access.
that is all folks... 😀

GoldFinger wrote:

Well, I just changed the vector back to a Record ** pointer,

Great. I'll grab the update.

can you test it in RB3D and others and do a Beta release?
I want some feedback on how fast it is.

I'll test everything I've got.

I am working on the mipmap stuff and I will see how to speed up the direct buffer access.
that is all folks... 😀

Good. Love to know what's wrong with my mipmap routine for paletted textures. Works great on squares, but...

The direct buffer access: I have a very much faster algorithm for scanning for the changed area. If that's the change you were thinking of, probably best to let me commit mine first. I built it into Glidos; I need to move it to OpenGLide. If you have some other completely different approach then all the better.

Its fast. I don't have any games where I can make measurements, but there are some very clear speed ups, especially for Glidos games. Many games play movies by sending 565 texstures; this is obviously sped up. All the LFB writes in Glidos get turned into 565 textures too, and that is faster. Also the Glidos VESA support gets turned into 565. Specifically, Grand Theft Auto, Descent II and Redguard seem faster.

On the Windows side, can't see much difference in Red Baron, but Unreal seems very much smoother. Actually its rediculously smooth. Although I have a GF3, I don't find all D3D and OpenGL games runn smooth. One that did was Max Payne; it really stood out as smooth, and Unreal now seems every bit as smooth as that. No measurments, so perhaps I'm seeing things.

Only one problem, Redguard lost its nice yellow hazzy sun in favour of a big black sqaure, so I had to disable the new method for alpha tesxtures. Redguard is the only game I know that uses them, and it uses them only for the sun, so it doesn't really matter that we are not ussing the fastest method.

Anyway, very nice bit of work.

Another little problem. I tried out Undying, and it works with v007b4 of OpenGLide (very nicely, which is good news), but with the latest version there are some tress and lanterns that are coming out as redish and transparent. I think its just one texture format that's playing up. I'll try to find out which. Also some problems in the menus.

Just remembered something else. There is a hack I put in for Lara's shadow in Tomb Raider. I think I want to keep this hack, but I really must move it out of OpenGLide into Glidos. I've no idea why I put it in OpenGLide in the first place. Can somebody hassle me if I forget about it again.

It was GR_TEXMFT_4444 that was upsetting Undying. Looks like none of the OpenGL versions of 4444 match the Glide one.

Are you testing all Unreal engines? I'll test 'em today if you want...I think I have 'em all..except for that fantasy one based on that book...dangit can't remember the name. 🙁

Hey, can someone point me to some way of downloading redguard and Undying, I CAN make the 4444 texture work ok, but I need some way to test it.

Redguard playable demo here (35.29 MB):
http://download.com.com/3000-2095-900551.html?tag=lst-0-1

Undying playable demo here (96.9 MB):
http://download.com.com/3000-2095-5531531.html?tag=lst-0-1

I think both demos support Glide. I could be wrong, though.

NOTE:
There's a texture patch for Undying: http://www.dlh.net/cgi-bin/dlp.cgi?lang=eng&s … gp10.zip&ref=ps

Warez? We know no warez here, Fabio. See the disclaimer at the bottom of the page?

This site hosts no abandonware. There is no material that is knowingly illegal here.
zetafleet.dom will not be held responsible for users' posts.
This disclaimer is brought to you thanks to the BSA.

Better Undying demo link:
ftp://ftp.ea.com/pub/archive/ea/demos/undying … ndying_demo.exe

Great, but I think I already figured it out the correct form for both the 4444 format and the Alpha one, can someone try it in the above games?
Anyway I am downloading the demos, but it takes some time.

Yes, I've just updates my local copy with your changes. I'll give it a try.

Big success on 4444. Undying menus, trees and lanterns look just how they should. I didn't know abiut that GL_RGBA_EXT stuff; neat. 😀

A8 is not so good. Rather than a big square black sun in Redguard, I now have a big square yellow sun. What you are doing now maps an alpha value

A onto 1AAA.

Your previous attempt was

A onto A000.

What the original that worked does is

A onto A111.

Perhaps your A000 was right and we shouldn't really need A111. Perhaps the only reason we need A111 is because I screwed up the way alpha textures are used. Alpha textures was something I put in, so I may have gotten it wrong. On the other hand, if you can find a way that in effect gives A111, then that will make it work without us having to fiddle about elsewhere.

BTW, you forgot to check in the PGTexture.h. You should get a copy of WinCVS. I know everybody slags it off, but it is actually brilliant. With WinCVS, you will never forget to check in a file again. 😁

Cheers,
Paul.

That doesn't make sense, what I just said.

If your first attempt (like what you have now, but with GL_ALPHA replacing GL_INTENSITY) gave the effect A000 then I should have seen a round black sun, whereas what I actually saw was a big sqaure black sun (which is what you would expect from 1000 not A000). So I'm confused. Maybe I shouldn't be trying to think of alpha textures as having equivalent ARGB textures... although we have to for OpenGL v1.0

The Alpha in Glide is just like the INTENSITY in OpenGL, I can`t understand what is wrong, because the Alpha is just a way of doing AAAA, as is intensity in OpenGL, maybe I did the wrong combination in the parameters, I will check it out and see.

ALPHA and INTENSITY certianly give different results. The first give a black square, the second gives a yellow one (yellow is the constant color at the time of rendering). If you look at the version that works, it definitely mpas A to A111. The 1s seem to matter.

Looking at the definition of the differnt texturing methods BLEND, DECAL and MODULATE, there are lots of things that depend on how many components the texture has, but just as you say there is no mention of 1 component textures behaving differently depending on whether they are ALPHA or INTENSITY. Have nVidea got something wrong?

I have an idea. Let me go and try something. It won't work. 😀

Well, I gived it up on the Alpha stuff, I just changed it to faster function, Alpha textures are not that used... 😀
I am looking into the LFB stuff right now, speeding it up the most I can. I need someone to test it on the RB3D game but I will not commit the changes until I know they are ok as I am changing lots of stuff.

One of the main speed ups for LFB is to check the changed region two pixels at a time, by checking DWORDs for the value
BLUESCREEN | (BLUESCREEN<<16).

The loop can also be split into several parts, each with simpler tests. Below is the version from Glidos, but it assumes a certain frame size, and so isn't general enough for OpenGlide. It is a very complicated replacement for a single loop, but I think it at all times keeps the tests minimal.

1    int x, y;
2    int maxx = 0,    maxy = 0;
3    int minx = 1024, miny = 1024;
4    unsigned int *line;
5    
6    line = (unsigned int *) lfb_write[0];
7
8    for(y = 0; y < 480; y++)
9    {
10        for(x = 0; x < 320 && line[x] == BLUEBLUE; x++)
11            ;
12
13        if(x < 320)
14            break;
15
16        line += 512;
17    }
18
19    if(y == 480)
20        return;
21
22    miny = y;
23
24    minx = x;
25
26    for(x = 320-1; line[x] == BLUEBLUE; x--)
27        ;
28
29    maxx = x;
30
31    line = (unsigned int *) lfb_write[480-1];
32
33    for(y = 480-1; y > miny; y--)
34    {
35        for(x = 0; line[x] == BLUEBLUE && x < 320; x++)
36            ;
37
38        if(x < 320)
39            break;
40
41        line -= 512;
42    }
43
44    maxy = y;
45
46    if(maxy > miny)
47    {
48        if(x < minx)
49            minx = x;
50        
51        for(x = 320-1; line[x] == BLUEBLUE; x--)
52            ;
53        
54        if(x > maxx)
55            maxx = x;
56        
57        line = (unsigned int *) lfb_write[miny+1];
58        
59        for(y = miny+1; y < maxy; y++)
60        {

61            for(x = 0; line[x] == BLUEBLUE && x < minx; x++)
62                ;
63
64            minx = x;
65
66            for(x = 320-1; line[x] == BLUEBLUE && x > maxx; x--)
67                ;
68
69            maxx = x;
70
71            line += 512;
72        }
73    }

Oh great! All the formatting has gone. Oh well, you probably wouldn't have wanted to use it anyway.

put it in [code] tags. 😀 (I [code]'d this for you.)