I just changed glTexCoord2f to glTexCoord4f in ogl_draw_triangle.
also tried what you said but the few textures that don't break are still not perspective corrected.
damn 3d graphics libs! 😜

The distortion caused by changing the Z values is known and expected. In normal 3D rendering 4th parameter for all of the vertexes (W) get calculated as a natural part of the transformation math and is always set correctly for the depth so things just kind of work out. The PowerVR handles that because you don't actually get the original Z value, you are passed either 1/Z or 1/W. I think that's why I was thinking you needed to divide originally, because for the PowerVR everything is already an inverse.

You shouldn't have to change your glOrtho call, though out of curiosity what are you passing in for the near and far parameters? Do you do any manual scaling of the Z parameter? If so make sure you're always using the original value when messing around with glTexCoord calls.

This stuff is way more confusing that it needs to be. Is your patch checked into the main tree or a branch? I don't have a Dosbox build environment setup at the moment but I could try getting one configured and mess around with it a bit.

near and far z parameters are 0.0, -1.0. these values are from openglide sources.
Here's the complete source, ready to build with visual studio.

the code in functions get_st and get_depth, that calculates s, t and depth values, is directly taken from the software scanline renderer, which is located in src/hardware/voodoo_data.h file, as a macro, called RASTERIZER, at the end of file.
the opengl code is all located in src/hardware/voodoo_opengl.h file.

the software renderer works just fine (aaron giles did a great job), it recreates the correct original pixel pipeline from the chip (specs here).
It's just I'm not sure if some of the strange tricks done in software (i.e. depth calculation) are possible through opengl, or at least I don't know how to port that (and if I actually need to).

You can switch back to software rendering by changing v->ogl flag in the voodoo constructor, in voodoo_main.cpp file.

let me know if you need more info.
thanks.

Thanks. That code is a lot more complicated that I was expecting. I'm trying to trace the various Z/W calculations. It looks like there's is some clamping going on that might be counter-productive for texture coordinates. I'll have to play around.

One issue, I'm getting a build error saying "Unable to create directory "E:\Stuff\Dosbox\DOSBox-0.74"". I'm assuming there's a hard-coded path somewhere in the project file I need to tweak accordingly.

Is there a specific game where you can get to a noticeable error quickly for testing (like in the menus)?

TouchMonkey wrote:

Thanks. That code is a lot more complicated that I was expecting. I'm trying to trace the various Z/W calculations. It looks like there's is some clamping going on that might be counter-productive for texture coordinates. I'll have to play around.

thank you for your help 😀

TouchMonkey wrote:

One issue, I'm getting a build error saying "Unable to create directory "E:\Stuff\Dosbox\DOSBox-0.74"". I'm assuming there's a hard-coded path somewhere in the project file I need to tweak accordingly.

yep, sorry, I forgot to fix that. navigate through menus:
Project->dosbox Properties->Linker->change "Output File" path
that's for vs2008, i hope it's the same with vs2010

TouchMonkey wrote:

Is there a specific game where you can get to a noticeable error quickly for testing (like in the menus)?

you can try tomb raider 3dfx demo PC 3dfx Demo: City of Vilcabamba (2.2 mb).
errors should appear from the start (spinning passport)
starting the game, the errors should be more noticeable.

Well, the texture perspective issue ended up being a pretty easy fix. It's basically what I mentioned before except using W instead of Z.

1	glTexCoord4f(s0 * w0, t0 * w0, 0.0f, w0); glVertex3f((float)v->fbi.ax/16, (float)v->fbi.ay/16, z0); 
2	glTexCoord4f(s1 * w1, t1 * w1, 0.0f, w1); glVertex3f((float)v->fbi.bx/16, (float)v->fbi.by/16, z1);
3	glTexCoord4f(s2 * w2, t2 * w2, 0.0f, w2); glVertex3f((float)v->fbi.cx/16, (float)v->fbi.cy/16, z2);

If you make that change in voodoo_opengl.h the textures stop shifting as you move around. The floor tiles become static and the lines between the blocks on the wall columns will stay straight no matter what angle you're looking at them. It's pretty noticeable if you just load that Tomb Raider demo and spin around in the starting hallway or just outside while looking at the stone column on the left.

At the bottom are Before and After screenshots detailing the fix. VERY easy to see how the lines between the stones on the column are now correct, and the textures aren't distorted.

There are some other texturing issues though. It looks like some of Lara's body parts are loading completely transparent, and the wall textures look like it doesn't quite fit (wrong texture?)... but maybe it does I haven't tried the software renderer yet 😀

There's also some clipping issues related to the depth buffer issues I wrote about a while ago. It's annoying because OpenGL will always sort of "squish" depth values no matter what you give it. Good article linked below, specifically question "12.040 Depth buffering seems to work, but polygons seem to bleed through polygons that are in front of them. What's going on?" and "12.050 Why is my depth buffer precision so poor?"

http://www.opengl.org/resources/faq/technical … depthbuffer.htm

I think parts of Lara are transparent because non-textured color drawing is not implemented.

Thank you. For some reason I was sure the W values I calculate were wrong, so I discarded them.
the textures should be fine, at least with this game; other games, i.e. gta (dos) or tomb raider 4 (win/d3d) show some wrong textures.
the perspective seem to be fine now, just some shaking when moving camera, perhaps a s,t coords precision error?
the "missing parts" actually are there, but they don't show up because of some depth calculation error; i tried to comment the calculation of z through the get_depth macro, so it uses the iterated values, and they show up. but they're not colored. moreover many depth errors show up with triangles.
btw I don't know how correctly color them and especially how to color/shade textures.

Kekko try calling:

SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 24);

before SDL_SetVideoMode(). Default is 16-bit and is probably too low for Glide (OpenGlide uses a special precision fix when Depth Buffer is only 16-bit).

hmm it doesn't work. I guess the depth calculation itself is wrong somehow.

Hmm, I knew British girls can be a little pale sometimes, but this is ridiculous 😀

Keep up the great work, gentlemen!

Even better than using a 24-bit depth buffer, you can try using floating point depth buffer using the official GL_ARB_depth_buffer_float extension. Not sure how that would work since you're using SDL to do most of the graphics initialization.

http://www.opengl.org/registry/specs/ARB/dept … uffer_float.txt

Coloring each vertex should be relatively easy. It looks like you're already calculating each vertex's R/G/B values, so you just need to remove the line:

glColor3f(1.0f, 1.0f, 1.0f);

And change your drawing lines a bit:

1	glColor3f(r0, g0, b0); glTexCoord4f(s0 * w0, t0 * w0, 0.0f, w0); glVertex3f((float)v->fbi.ax/16, (float)v->fbi.ay/16, z0); 
2	glColor3f(r1, g1, b1); glTexCoord4f(s1 * w1, t1 * w1, 0.0f, w1); glVertex3f((float)v->fbi.bx/16, (float)v->fbi.by/16, z1);
3	glColor3f(r2, g2, b2); glTexCoord4f(s2 * w2, t2 * w2, 0.0f, w2); glVertex3f((float)v->fbi.cx/16, (float)v->fbi.cy/16, z2);

That doesn't seem to change much in the TR demo but should be more correct anyway.

Great to see this thread moving along again!

Here's a EF2000 screenshot. The sky uses shaded polygons, so is temporarily missing. Love the apocalyptic effect though. 😀

TouchMonkey wrote:

Even better than using a 24-bit depth buffer, you can try using floating point depth buffer using the official GL_ARB_depth_buffer_float extension. Not sure how that would work since you're using SDL to do most of the graphics initialization.

http://www.opengl.org/registry/specs/ARB/dept … uffer_float.txt

i'm not sure of what's going on with depth calculation, maybe it's not just a matter of precision, it may just be plain wrong.
If you manage to spot something about this, please let me know.

TouchMonkey wrote:

Coloring each vertex should be relatively easy. It looks like you're already calculating each vertex's R/G/B values, so you just […]
Show full quote

Coloring each vertex should be relatively easy. It looks like you're already calculating each vertex's R/G/B values, so you just need to remove the line:

glColor3f(1.0f, 1.0f, 1.0f);

And change your drawing lines a bit:

Copy code to clipboard

1	glColor3f(r0, g0, b0); glTexCoord4f(s0 * w0, t0 * w0, 0.0f, w0); glVertex3f((float)v->fbi.ax/16, (float)v->fbi.ay/16, z0); 
2	glColor3f(r1, g1, b1); glTexCoord4f(s1 * w1, t1 * w1, 0.0f, w1); glVertex3f((float)v->fbi.bx/16, (float)v->fbi.by/16, z1);
3	glColor3f(r2, g2, b2); glTexCoord4f(s2 * w2, t2 * w2, 0.0f, w2); glVertex3f((float)v->fbi.cx/16, (float)v->fbi.cy/16, z2);

That doesn't seem to change much in the TR demo but should be more correct anyway.

i've already done that in my test code, but you need to change the division from 1<<12 to 1<<20.

It seems I managed to fix texture "shaking" by changing this code:

1	/* adjust S/T for the LOD and strip off the fractions */
2	s >>= ilod + 0;//was ilod+18
3	t >>= ilod + 0;

and commenting out the clamping in the code just below that.
then I divided float values of s,t by 1<<18 to get higher precision .

shadows!

Just realized I accidentally used glColor3f instead of glColor4f. Forgot that you'd already calculated the alpha as well so you might as well use them. You mentioned you had already made that change so you may have done it that already, but I wanted to correct my mistake anyway.

Should be glColor4f(r0, g0, b0, a0); etc

Looks like you're making some good progress!

thanks. actually i've some troubles with alpha, maybe the division is wrong.
still need some help with fixing the depth once for all. I guess my get_depth macro should be dumped. any idea?

enjoy tomb raider 4 with lighting 😀

my last version of voodoo_opengl.h

Amazing work! 😲

Nice shots!