well, thanks. we're still far from completing it, but not too far 😀
notice the flame on the right of the last shot, that should be bright actually, this is a kind of map that seem to be usually used i.e. for water surface, smoke or flames; at the moment it's not handled..

I still need to post a big part of the pipeline from the software rasterizer, which is structured this way:
- PIXEL_PIPELINE_BEGIN macro for stipple(needed?) and depth (how to fix this... definitely need a hand with it)
- TEXTURE_PIPELINE macro: the first part gets the texel, the second part is quite long and seems important, it calculates "c_other" color and alpha, does some blending, inverts the color (why?). if there's someone that can explain...
it's called two times, because this (emulated) card has two texture units, but i don't know how they interact each other (two textures on the same triangle?)
- CLAMPED_ARGB macro: just does some more clamping? do we need it?
- COLORPATH_PIPELINE macro: this seems quite long and quite important, maybe that's why I don't understand a single thing of it...
- PIXEL_PIPELINE_END: fogging, blending (again?), dither (not needed i guess) and final pixel write

I must be honest and say there are things not easy to understand, even if it seems the software rasterizer respects the pipeline described in the sst1 specs, it even uses the same names for those color variables "c_other" and such

i changed this

1			glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL_CLAMP); 
2			glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T,GL_CLAMP);

to this

1			glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL_REPEAT); 
2			glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T,GL_REPEAT);

it fixes the remaining texture issues with GTA, which looks very nice now.
the texture coordinates were clamped when outside of the range.

now I'm experiencing some color flickering with vertices, sometimes the color flickers, or the triangle appears in solid black;
assuming that the values are correct, is there any parameter i can change to make opengl handle this automatically, as done for texture coordinates?

I'm doing some nice progress, I cleaned up the code a bit and I got better and smaller code.

Now I'm trying to implement some of the missing features, but I need some help from an opengl expert. let's start with these questions:
- how to perform operations on a triangle's texture (or color) directly in opengl, i.e. adding/subtracting a color, XORing a texture(color)?
- how to use two textures, with different s,t, on the same triangle, in a simple and portable way?

well, i had many other questions, but then I thought of posting them later.
thanks.

Just a quick question, are you going to extend the voodoo support for higher resolutions than the "standard" like some wrappers do?

It's mostly a issue for windows 95 games but interstate76 for instance, looks much better like that.
Of course, game resolution screen options look confused when you do that, so you are ineffect no-oping a api command if you do that.

1. would be hard without the shaders...you'd probably need some trick and use several textures in a way so that their result adds up to desired value; the easiest way would be programming the shaders

2. By using multitexture extension (and MultiTexCoord())

@Serious Callers Only: probably when everything else works...but even then, it might not be possible since the emulation works very differently from how the wrappers work.

thanks. actually, for point 1, i'm reading that opengl should make available some predefined "blending" operations, in order to combine two textures and/or colors (any combination); i hope i understood correctly 😜
I guess that if a 15-yr old hardware did that with a fixed pipeline, opengl should support something similar.

Blending is usually tricky to deploy (doubt you can do XOR with it anyways) so don't count on it too much.
As gulikoza says you have pretty much fine control over the operations in shaders but that may not be what
you want to use.

maybe glBlendEquation does what you need.

thank you all.
I guess what it really needs it something simple, it may seem complicated from the code and the docs, but perhaps opengl does that natively.
let's start with texel pipeline right after fetching the color from the texture.
the card has two texture units called in sequence, so, the final texel of TMU1 may be the input for TMU0.
c_local and a_local are the current texture pixel color and alpha.
c_other and a_other are the previous TMU texel color and alpha (when calling TMU1 they are 0).

this is for a single texel, but maybe it can be translated in a couple of functions called in sequence, which applies to the whole triangle.
they just seem to combine two colors, i.e. texel+texel or texel+pixel, subtracting, inverting a color, blending. It seem easier to understand from the code.

the software rasterizer translate this pipeline in this http://pastebin.com/jTHZ1a51

there is also the color and alpha pipeline, which combines the previous results with iterated color/flat color/etc.
iterated pixel is the pixel from interpolation of vertex color (gouraud)
color0 and color1 are colors stored in two registers
texture and lfb, well, you know what they are.

this translates in the following code http://pastebin.com/yEauDMzr

also in this case, I guess it's something which seem way complicated, if you just look at the pixel path, but maybe it's not.

after that, there's also fogging, alpha blending and dithering, before getting the final pixel, but let's ignore that for the moment.

i hope all this tells something to an opengl expert. I'm here for any question, if I may be of help.
Thank you.

Well it's hard to recommend a specific path since I'm not familiar with the software rasterizer. Mutlitexturing is not a problem, opengl handles this through multitexture extension (which was merged into core in opengl 1.2, so it should be supported pretty much by everything). See here for an example: http://www.opengl.org/resources/code/samples/ … tes/node62.html

As for other problems, the problem here as I understand is you'd need to take a step back and basically rewrite the low-level software code into high-level opengl commands, using regular opengl state calls. In theory it should be possible (since voodoo is quite successfully emulated with opengl wrappers) but the question is, does enough information exist at this low level to use opengl directly. If you try to just "port" the software codepath to opengl, then probably you'd have more success with the shader way, since that could probably duplicate the software code almost exactly.

thanks. I think it's not important to achieve accurate emulation through opengl; at the moment, for example, it's drawing triangles in full 32 bit instead of the original dithered 16bit of the software rasterizer.
From what I understood, even if it seems way complicated from the pipelines, it just a matter of a couple different coloring and blending modes, which probably are supported in opengl by a couple functions. on the other hand, as you said, wrappers already do all this and I guess they don't use shaders and such techniques.
I tried to understand what openglide sources do, but my poor understanding of opengl and the high complexity of the code, didn't help me very much.
about your question, I'm quite confident that we already have any info we need, with enough detail. I noticed that the data and even variable names used by documentation and software rasterizer match what I managed to see in the wrapper and voodoo high-level (developer) programming docs.

For the info I meant info about the emulation states...as in if several high-level functions call the same low-level function, you'd have a hard time figuring exactly what to do in that particular function for example 😀.
As for openglide, where do you have the problems? I have a hard time understanding the texturing functions (due to Glide poor handling of the texture memory), but the rest seems more or less straightforward. The most interesting function for you in this step would probably be RenderDrawTriangles() which seems to duplicate the pixel pipeline (along with RenderAddTriangle()).

thanks. I've just added multitexturing through glActiveTextureARB; it's working quite fine, quake2 looks very good and incredibly fast 😁
I guess (hope) that the rest of the texel pipeline it's just a matter of setting texture parameters, with glTexEnv and maybe other functions.

latest voodoo code.
unfortunately multitexturing atm breaks most of the games which use one TMU only, even if I make it call the function set only for TMU0 for them.

I've just added multitexturing through glActiveTextureARB; it's working quite fine

This is plain great (not the glActiveTextureARB in particular but the progress you've achieved),
I had not expected getting that far but I'm lacking both experience in the voodoo technology
as well as ideas how this translates. Props to gulikoza as well for work on the "big picture"
as well as detailing information. Nice.

This version crashes for me before anything shows. Apparently ogl_draw_triangle() is called a bunch of times before OpenGL is actually initialized. I've added a simple check in the beginning of ogl_draw_triangles() which works around the crash:

1if(!glMultiTexCoord4fARB || !glActiveTextureARB) {
2		LOG_MSG("Draw triangle called, extensions not loaded!");
3		return;
4}

This is the output I get:

1DOSBox version SVN
2Copyright 2002-2010 DOSBox Team, published under GNU GPL.
3---
4CONFIG:Loading primary settings from config file dosbox.conf
5Memory sizes above 31 MB are NOT recommended.
6Stick with the default values unless you are absolutely certain.
7MIDI:Opened device:win32
8DOS keyboard layout loaded with main language code YU for layout si
9DOSBox switched to max cycles, because of the setting: cycles=auto. If the game runs too fast try a fixed cycles amount in DOSBox's options.
10Draw triangle called, extensions not loaded!
11Draw triangle called, extensions not loaded!
12Draw triangle called, extensions not loaded!
13.... (snip) ...
14Draw triangle called, extensions not loaded!
15Voodoo output 640x480
16OpenGL init
17Extensions loaded

The previous version works, although I have a feeling OpenGL is just silently failing in those first few runs. I was trying to see the multitexture problem but surprisingly, the new (multitexture) version almost works better than the previous 😀. What hardware do you use? I have Ati HD4850...
I could never see the main menu with opengl output and until the multitexture version, output was kinda flickering always. Now it doesn't flicker 😀
Also you should use SDL_GL_GetProcAddress(), wglGetProcAddress() is windows only.

@wd
thank you for the kind words 😀 it's great to have a friend like you. you helped me with this much more than you think.

@gulikoza
thanks. this version has many changes against the code released previously; the missing polygons were fixed before multitexturing.
I'm aware of the missing passport in tr menus, it seems a matter of z buffer, which I don't know how to solve, since the menu background has a lower z than the passport and the other things...
about the crashes, that's not the issue I was refering to, I mean that some games, like tr4, show darker textures, as if it was blending primary texture with black... I added some check to prevent instancing of the second texture when not needed (already present in the last sourcecode) but it don't seem to be enough.
my card is an nvidia 9800gtx+

which I don't know how to solve, since the menu background has a lower z than the passport and the other things...

How are they drawn? Like first they render the background using a single textured quad, and then the rest which is 3d?

it seems everything in tr menus is made of triangles in 3d space: background, texts, passport and the other things; perhaps the draw order depends by some other thing.
I also tried to handle glDepthFunc the way openglide does, which conceptually is very similar to glide itself, but it doesn't seem to be enough to fix that.

I also tried to handle glDepthFunc the way openglide does

Is any of the functions like glDepthFunc, glDepthRange, glDepthMask or GL_DEPTH_TEST set to anything unusual, or used at all during the buildup of the menu?