Great news kekko, this fullfil my dream!!!

Thanks kekko.

This is awesome news! 😀

...just hope I can set it up.

first screenshot of the opengl accelerated 3dfx emulation 😜

Nice. Screwed your weekend? 😉

wd wrote:

Nice. Screwed your weekend? 😉

🤣

Awesome, how well dows it work?

well, I just added a simple and not much optimized texture caching algorithm, and it's already going insanely fast 😀
there are still hundreds of bugs and many missing features
- proper opengl video mode switch
- simple non textured polys
- triangles z-sort(or zbuffer)/perspective correction/alpha/filtering/lighting
here's also the latest experimental patch (apply after patch voodoo_20101127.diff at page 10)

I partially fixed texture alpha; need a hand from opengl experts with perspective correction/depth testing, I'm not sure on how to make it work. Any suggestion will be appreciated 😀

Thanks! I recently tested your patch, and the Speed Incrase is HUGE, I finished the first level of Tomb Raider 1 at fullspeed, of course the graphics were all glitchy, but it worked.

Hey all. I recently downloaded ykhwongs dosbox build with your voodoo emulation. I couldnt believe when i saw that spinning logo when GLquake launched. The only problem with his build is that the FPS is abysmal. Like playing Aces over europe 🤣. Anyhows, kekko (and the others working on this project) u have made my christmas and new year. I havent played some of the games i have tonight in 7 years. Even if the Framerates crap.
-Quaker (merry Christmas)

amazing work so far!!!

As a one and only warning i'll remove ALL "fps is too low" postings without further note.

Oh whoops my bad 😐. great work guys keep it up.

need a hand from opengl experts with perspective correction/depth testing

How are you doing your projection handling? If you are using glOrtho, I don't see your issue at all, since there is nothing to correct 😒

Are you sure all your coordinates for the textured quads are right?

I'm using glOrtho, and also

1	glEnable(GL_DEPTH_TEST);
2	glDepthFunc(GL_LEQUAL);
3	glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);

then when drawing triangles, I use glVertex3f(x,y,z), which is (mostly) working for depth testing, but not for perspective corrected textures.

I'm attaching the latest experimental code, with some preliminary depth testing and more stable videomode switch (thanks hal 😀 )
I moved all opengl code in the new include "voodoo_opengl.h"

I have to wonder why:

1if (FBZMODE_Y_ORIGIN(v->reg[fbzMode].u))
2		glOrtho( 0, v->fbi.width, 0, v->fbi.height, 0.0f, -1.0f );
3	else
4		glOrtho( 0, v->fbi.width, v->fbi.height, 0, 0.0f, -1.0f );

Wouldn't it make sense if you use something like:
glOrtho(0, outwidth, 0, outheight, -1.0, 1.0);

instead rather than from 0.0f for nearZ?

How exactly does this renderer work? Is there just one singular texture or many being used?

I took the values for z planes from openglide. changing these values seem to make things worse 😖
there are many textures, uploaded in the emulated texture ram; when the renderer calls a triangle for the first time, I upload its texture to the actual video card and then I link the emulated texture start address to a textureID, through a std::map container.

Ah, so that explains the depth tests then.

I take it with the texture manager/cache, you are also taking care of textures not in use (eg. garbage collection)? I would imagine if textures are constantly allocated, there would be mem leaks....

that's handled by function ogl_texture_clear

1void ogl_texture_clear(Bit32u texbase) {
2	std::map<const Bit32u, GLuint>::iterator t;
3	t=textures.find(texbase);
4	if (t != textures.end()) {
5		glDeleteTextures(1,&t->second);
6		textures.erase(t);
7	}
8}

I hope it's working right (how do I check if video memory has been freed?)

One thing to keep in mind is that all (hopefully?) coordinates should already be pre-transformed. Voodoo did not have onboard transform&lightning (the first chip to have that was IIRC nVidia Geforce). Therefore, OGL should be set up in way to allow passing coordinates directly and not transforming them in any way.
Do you have a sample of where textures do not work correctly (a glide sdk test perhaps?).

ps. I guess video memory is not actually freed...you should check if any of the new textures overwrites an old texture mem address and release it then...