VOGONS


3dfx voodoo chip emulation

Topic actions

  • This topic is locked. You cannot reply or edit posts.

Reply 320 of 386, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

thanks wd. I found some references on transparency and z-sorting in opengl, it seems to be a not-so-straightforward matter. I'll try to study those info.

There's also another issue quite difficult to understand: how do I compare two colors in glsl if their components are float values? they may be not perfectly equal as if they were integers (software renderer).
That's an issue raised i.e. in chroma key testing or alpha mask. In fact at the moment many games show solid-filled polys where there should be some transparency.
If someone has some more info on this topic, please let e know.

Meanwhile, I managed to complete (I hope) alpha blending, mapping glide factors to opengl factors for glBlendFunc.
The result is quite nice. Many games now show fixed and almost perfect graphics, textures with water, smoke, clouds are showed correctly.

new code is in the attachment.

tr4_alpha_blending.jpg

Attachments

  • Filename
    voodoo_opengl.h
    File size
    28.78 KiB
    Downloads
    364 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    tr4_alpha_blending.JPG
    File size
    53.46 KiB
    Downloads
    310 downloads
    File license
    Fair use/fair dealing exception

Reply 322 of 386, by dosmax

User metadata
Rank Newbie
Rank
Newbie

I'm not sure if something like this is even possible in GLSL (no experience with that), but provided the floating point color values are in a range between 0 and 1 normally it should be easy to "convert" them to 0-255 integer values, which can be easily tested with a == test.

color_int.red = (int)floor(color_float.red * 255.0);
color_int.green = (int)floor(color_float.green * 255.0);
color_int.blue = (int)floor(color_float.blue * 255.0);

or simply

color_int.red = (int)(color_float.red * 255.0);
color_int.green = (int)(color_float.green * 255.0);
color_int.blue = (int)(color_float.blue * 255.0);

Another way might be to test the floating point values directly against each other with some kind of threshold, but for chroma keying of a specific color that is most likely based on a 24bit color value the above code may already be enough. And in a way it does nothing else anyway (with a threshold of 1/255).

Reply 325 of 386, by Serious Callers Only

User metadata
Rank Member
Rank
Member

The floats are 0F-1F or 0F-255F? If it's the second i guess that works fine.

(Watch out for -0F like the article says if you care about the IEEE representation when converted to integer though). If it was you producing them, i'd guess a "-0F" would not happen, unless you subtracted zero and zero maybe.
The article is worth reading. I'm not a floating point specialist. Take my words with a mountain of salt.

Reply 327 of 386, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

new release.
-more alpha blending fixes
-fixed texture caching on 2nd tmu (quake2)
-preliminary simple-case-only chromakey implementation
-alpha test

there are still many things left to implement on triangle rendering, and lfb writes should be (re)done in glsl and with proper color/depth pipeline.

need a hand with:
-fixing/completing some alpha/chroma/transparency issue (see ef2000 screenshot, above);
-transparency and sorting, polys with transparency are on top of any other (it's not easy to change triangle draw order, so I need to find another way);

and also with:
- games with fmv intros (i.e. tr2/3) write video frames directly to the front buffer. If I add glDrawBuffer(GL_FRONT) to every write, it becomes slow of course. If I change drawbuffer just when LFBMODE_WRITE_BUFFER_SELECT changes, it seems to draw correctly one pixel only, then nothing more. any clue?
- how to properly handle window<->fullscreen switch?

Attachments

Reply 328 of 386, by bored

User metadata
Rank Newbie
Rank
Newbie

In EF2000, the 2D cockpit and MFD ovelays always start out with the problem described above. If you Shift-Q, then E to exit the mission, the scene looks normal in the split second before you go back to the mission menu. If another mission is started, the problem either reappears as before, but sometimes the cockpit and MFD overlays are fine...but in this case some artifacts appear near the horizon, which I'll try to illustrate with the following screenshot.
ef_ogl_17_04.jpg

Reply 329 of 386, by Miki Maus

User metadata
Rank Member
Rank
Member
kekko wrote:

and also with:
- games with fmv intros (i.e. tr2/3) write video frames directly to the front buffer. If I add glDrawBuffer(GL_FRONT) to every write, it becomes slow of course. If I change drawbuffer just when LFBMODE_WRITE_BUFFER_SELECT changes, it seems to draw correctly one pixel only, then nothing more. any clue?

I would do this by writing to texture (glTexSubImage2D), then displaying it on two triangles. You can increase texture upload speed by using PBOs (see here, useful for readbacks too).

Reply 330 of 386, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

@bored
thanks for reporting. could you please tell me you cpu/gpu specs?

@miki maus
thanks. actually, video rendering in these games appear to be a continuous flow of lfb frontbufffer writes, so no buffer swap or anything that tells us that a frame is over and/or another one is coming.

Reply 332 of 386, by Miki Maus

User metadata
Rank Member
Rank
Member
kekko wrote:

@miki maus
thanks. actually, video rendering in these games appear to be a continuous flow of lfb frontbufffer writes, so no buffer swap or anything that tells us that a frame is over and/or another one is coming.

Hopefully not one pixel at a time? As that would would painfully slow. 😖
An idea maybe, if you know how many pixels they are writing you could render texture when they fill the "framebuffer" e.g. when they write 640x480 pixels.

Edit:
Aren't they using grLfbBegin/grLfbEnd or grLfbLock/grLfbUnlock pairs before and after writing each frame?

Reply 333 of 386, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie
Miki Maus wrote:

Aren't they using grLfbBegin/grLfbEnd or grLfbLock/grLfbUnlock pairs before and after writing each frame?

Probably...but grLfbUnlock unfortunately does not get to the hardware. grLfbLock sets the lfbMode register, but grLfbUnlock never resets it according to the glide sources so there is no way of knowing then unlock was called.

http://www.si-gamer.net/gulikoza

Reply 335 of 386, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

I guess gulikoza is right, the lock/unlock mechanism is at driver level, so is not useful.
i think there is no correct and universally working way to detect when it finishes to draw to the front buffer, therefore, writing directly to the opengl front buffer seem the better (and only) way.

About the polys with wrong alpha , it seems I might be using alpha blending in a non correct way (it's enabled or disabled for every triangle). please have a look at my implementation, i'm waiting for your critiques.
This is mostly the first true "from-scratch" use of a modern 3d graphics library for me. Last time I coded something for 3d graphics , 3d accelerators were at their dawn (a software 3d engine with texture mapping, for dos, mid 90s).

thank you all for your help 😀

Reply 336 of 386, by Orka Borka

User metadata
Rank Newbie
Rank
Newbie

Is anybody getting any luck in building / running kekko's version under Linux or Mac Os X? or his patches are just tested under windows right now?

I've tried building the latest snapshot from this thread with both Ubuntu 10.10 and Snow Leopard; with Ubuntu it doesn't compile due to some incompatibilities between dosbox sources and GCC > 4.3 ( Ubuntu 10.10 ships with 4.4), while under Mac Os X 10.6 / macports it compiles without too much problems, but dosbox crashes when I try running the original Tomb Raider Glide Demo.

Reply 337 of 386, by xcomcmdr

User metadata
Rank Oldbie
Rank
Oldbie

same problem here (gcc 4.4.3, amd64, Xubuntu 10.04). I wanted to report some tests with screenshots if I ran into some not previously found bugs, but I tried the most recent sources today (dosbox_voodoo_opengl_glsl.zip posted on 2011-4-17 @ 05:24 pm) and it's still the same error reported a while back on page 4 :

Making all in dos
make[3]: entrant dans le répertoire « /home/max/Dev/dosbox-0.74/src/dos »
g++ -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -g -O2 -MT dos.o -MD -MP -MF .deps/dos.Tpo -c -o dos.o dos.cpp
In file included from ../../include/SDL_config.h:42,
from ../../include/SDL_stdinc.h:28,
from ../../include/SDL_main.h:26,
from ../../include/SDL.h:28,
from ../../include/timer.h:23,
from ../../include/serialport.h:31,
from dos.cpp:33:
../../include/SDL_config_minimal.h:38: error: conflicting declaration ‘typedef unsigned int size_t’
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/include/stddef.h:211: error: ‘size_t’ has a previous declaration as ‘typedef long unsigned int size_t’
make[3]: *** [dos.o] Erreur 1
make[3]: quittant le répertoire « /home/max/Dev/dosbox-0.74/src/dos »
make[2]: *** [all-recursive] Erreur 1
make[2]: quittant le répertoire « /home/max/Dev/dosbox-0.74/src »
make[1]: *** [all-recursive] Erreur 1
make[1]: quittant le répertoire « /home/max/Dev/dosbox-0.74 »
make: *** [all] Erreur 2

(it's a clean dosbox v.0.74 code base apart from "my" version of kekko's awesome threaded video patch (here, last post) to hardware.cpp, only with dosbox.cpp and memory.cpp copied over, all new files in src/hardware copied, and all the include files copied over. Am I missing someting ?)
It seems I do not have a voodoo.h (as kekko said it needed to be removed from the build process in order for it to succeed) :

% pwd
/home/max/Dev/dosbox-0.74
% ls ./* -R | grep voodoo
voodoo_data.h
voodoo_func.h
voodoo_main.cpp
voodoo_main.h
voodoo_opengl.h
voodoo_raster.h

Same error if I try to build the provided sources 'as is'.

PS : perhaps posts about building problems shoud be splitted into a new topic ? It would keep the thread clean, IMHO.

Reply 338 of 386, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

your building problems are not just off-topic, but they doesn't even seem to be related to the 3dfx code, so please just avoid posting these kind of issues.

just a quick update.
- cleaned up opengl code a bit
- removed few redundant functions
- improved texture handling
- added (kind of) trilinear filtering
- fixed buffer swapping, half-life should work just fine now

I still have troubles with fixing depth test and alpha blending:
352hsvr_th.jpg
If I play with GL_DEPTH_TEST and GL_BLEND functions (function ogl_draw_triangle), something gets fixed, while something else breaks.

p.s. I added an experimental build, even if this is still buggy and incomplete. Enjoy!
I cannot be held responsible for any damage caused to your PC.

Attachments

  • Filename
    voodoo_opengl_glsl2.zip
    File size
    58.37 KiB
    Downloads
    643 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    dosbox_mingw.zip
    File size
    824.98 KiB
    Downloads
    932 downloads
    File license
    Fair use/fair dealing exception

Reply 339 of 386, by bored

User metadata
Rank Newbie
Rank
Newbie

kekko, many thanks for persevering with this.

I'm posting this in the hope that it may be of some help since I'm getting some strange behaviour with EF2000, where what gets displayed is dependent on the camera position. This is illustrated in this picture.
ef_ogl3.jpg
Various 'modes' can be seen if the view is rotated around the aircraft.