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.
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.
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).
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.
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?
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.
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).
@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.
@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?
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.
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).
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.
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 :
1Making all in dos 2make[3]: entrant dans le répertoire « /home/max/Dev/dosbox-0.74/src/dos » 3g++ -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 4In file included from ../../include/SDL_config.h:42, 5 from ../../include/SDL_stdinc.h:28, 6 from ../../include/SDL_main.h:26, 7 from ../../include/SDL.h:28, 8 from ../../include/timer.h:23, 9 from ../../include/serialport.h:31, 10 from dos.cpp:33: 11../../include/SDL_config_minimal.h:38: error: conflicting declaration ‘typedef unsigned int size_t’ 12/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’ 13make[3]: *** [dos.o] Erreur 1 14make[3]: quittant le répertoire « /home/max/Dev/dosbox-0.74/src/dos » 15make[2]: *** [all-recursive] Erreur 1 16make[2]: quittant le répertoire « /home/max/Dev/dosbox-0.74/src » 17make[1]: *** [all-recursive] Erreur 1 18make[1]: quittant le répertoire « /home/max/Dev/dosbox-0.74 » 19make: *** [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) :
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:
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.
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.
Various 'modes' can be seen if the view is rotated around the aircraft.