I've since done lot more research and it's a bit of a mess on Linux (where there's no nGlide which is apparently stable and functional enough with AD and Carma to be shipped to unsuspecting customers by GOG).

My ppa has this patch if you're using ubuntu.

Though, this is the more demanding version of voodoo emulation for dosbox (not a wrapper) so you have to have a great computer to even run glide games.

I've honestly only found it useful for Tomb Raider 1 and Redguard (didn't try it for Carmageddon). While Archimedes Dynasty also has a 3dfx port, it doesn't seem different on this patch (indeed the executable has display bugs that don't appear in the other) and several of the other 3dfx games are actually windows games (and i didn't bother to test that out because it would require installing drivers on the windows images i use).

Serious Callers Only wrote:

My ppa has this patch if you're using ubuntu.

Though, this is the more demanding version of voodoo emulation for dosbox (not a wrapper) so you have to have a great computer to even run glide games.

I've honestly only found it useful for Tomb Raider 1 and Redguard (didn't try it for Carmageddon). While Archimedes Dynasty also has a 3dfx port, it doesn't seem different on this patch (indeed the executable has display bugs that don't appear in the other) and several of the other 3dfx games are actually windows games (and i didn't bother to test that out because it would require installing drivers on the windows images i use).

Hey thanks for the pingback.
What patch do you mean you use? I think versions of dosbox like -x and -ece both use kekko's 3dfx patch which AFAIU was adapted from Aaron Giles' work for the MAME project http://aarongiles.com/programming/emulation/ and it doesn't use a wrapper, it emulates voodoo hardware internally either in software or with opengl. Unfortunately it seems that this implementation (and/or its integration into dosbox as pointed out in the dosbox-x thread) is subpar to dosbox+nGlide solution, at least for the game(s) i'm interested in. But nGlide is of course windoze-only. And the only wrapper for Linux I know of is openglide which is long dead I think and probably even less desirable to use anyway...

Ah, I've taken a look at your (I think) PPA and lists the said patch. So it's actually the same one I've tried out. And I think the only alternative to it on Linux is the old gulikoza's build with openglide which I planned to try out (just in case) but haven't got to it yet.

Yeah, i think a good solution for 3dfx has to be on upstream, in the absence of a dosbox maintainer hero like we have for mt32 with munt. Seriously, that the coder maintains a dosbox patch on its repository is the only reason i bother to provide mt32 support, would be far too lazy otherwise.

In the end dosbox is fragmenting itself by not taking up at least the mt32 and 3dfx patches and integrating them better. It's getting to the point that there are a lot of people recommending installing MAME or PCEm even for dos programs, which is ofc, completely ridiculous.

Speaking of things nice to have, i'd love if dosbox got host device independent 'guest profiles' for 'typical pc on 1985, 1990, 1993, 1995' or some thing like that with predictable speeds.

Hi,
I was wondering if any of you have run into joystick axis issues when using kekko's voodoo hardware emu patch? I was using dosbox-ece to run the 3dfx version of Whiplash which uses internal code to access the hardware (no glide2x.ovl or anything). It runs fine except when calibrating the joysticks some of the axis between joystick 1 and 2 will get merged. Moving a joystick 1 axis will also move joystick 2's. This only happens when running the 3dfx version of the game and once I do it persists even when exiting the game. Running the normal version of the game the axis are fine, then I can run the 3dfx version and they are merged, then run the normal version again and they are merged no as well. I've also used a dos joystick test program and it will do the same. It will be fine before running the 3dfx executable of Whiplash, and then show the axis affect each other after running the 3dfx executable.
I thought maybe it was the 3dfx executable itself but then I tried a dosbox-x build and the joystick axis are fine when using the 3dfx executable. Unfortunately in dosbox-x fullscreen mode has been disabled while in 3dfx mode.

I decided to build my own dosbox using the "official" svn 4095 and only loading kekko's patch to eliminate the other patches dosbox-ece uses but my build also exhibits this same joystick behavior.

Does anyone know if there is a difference in the dosbox-ece and dosbox-x 3dfx and or joystick implementations?

Thanks.

Another note, even when I delete any joystick mappings from the mapper the 3dfx version of Whiplash will still read input from the joystick. It's way more erratic than normal but is read. The joycheck program and the normal version of Whiplash will not read the joystick when the mappings are deleted if run before the 3dfx version. If run after then they will also read it. Somehow the 3dfx access is turning on some base joystick code?

Once again this is happening in Dosbox-ECE and my build of the latest dosbox SVN and kekko's Voodoo patch. It does not happen in Dosbox-x.

Serious Callers Only wrote:

a good solution for 3dfx has to be on upstream

Preferably with the actual glide2ogl bridge built into host system's driver (rather than into DB), in the vein of D3D9 in Mesa for Wine/gallium-nine. At least on Linux. One can dream...

I disagree about that. A good upstream 3dfx emulator for Dosbox could probably be a fast software-rendered recompiler to cover itself for all output types and more degrees of authenticity.

I think DOSBox needs to be forked into WIN9XBox and provided as a VM specifically for running Windows 95/98 games. That's really the only segment remaining that normal Virtual machines seem to fail on for gaming.

Hello @ll,

I'm in trouble with a Color Mask on the Voodoo source "voodoo_opengl.cpp".

First, i have tried successfull Windows 95/98 Games on my Fork. I#m a German user and i iave a main thread of my Fork.
http://cgboard.raysworld.ch/thread.php?threadid=30046

I know. it gives no Support for the Win9x/3DFX theme but i hope you can me help.
On my post http://cgboard.raysworld.ch/thread.php?thread … tuser=0&page=10 with Flying Saucer see the GFX.

The first Pic show the unmodified backbuffer code. Heaven is Black and missing the Hud Gfx.

1UINT32 voodoo_ogl_read_pixel(int x, int y) {
2	UINT32 data[2];
3	UINT32 mode=GL_RGBA;
4	UINT32 j;
5
6	if ((x < 0) || (y < 0) || (x >= (INT32)v->fbi.width) || (y >= (INT32)v->fbi.height)){
7		return 0xffffffff;
8	}
9	switch (LFBMODE_READ_BUFFER_SELECT(v->reg[lfbMode].u)) {
10		
11		case 0:
12			//LOG_MSG("VOODOO: /* front buffer in use */ ");	
13			VOGL_SetReadMode(true);
14			if ((cached_line_front_y != y) || (x+1 >= cached_line_front_width)) {
15				if (cached_line_front_length<(INT32)v->fbi.width) {
16					
17					if (cached_line_front_data!=NULL)
18					{
19						free(cached_line_front_data);
20					}
21					
22					size_t span_length=((v->fbi.width+64u)&(~15u));
23					cached_line_front_data=(UINT32*)malloc(sizeof(UINT32)*span_length);
24					cached_line_front_length=(INT32)span_length;
25				}
26				glReadPixels(0,(int)v->fbi.height-y,(int)v->fbi.width,1,mode,GL_UNSIGNED_BYTE ,cached_line_front_data);
27				cached_line_front_y=y;
28				cached_line_front_width = (INT32)v->fbi.width;
29			}
30			data[0]=cached_line_front_data[x];
31			data[1]=cached_line_front_data[x+1];
32			break;
33			
34		case 1:
35		{
36			//LOG_MSG("VOODOO: /* back buffer */ ");	
37			VOGL_SetReadMode(false);
38			if ((cached_line_back_y != y) || (x+1 >= cached_line_back_width)) {
39				if (cached_line_back_length<(INT32)v->fbi.width) {
40					if (cached_line_back_data!=NULL)
41					{
42						free(cached_line_back_data);
43					}
44					size_t span_length=((v->fbi.width+64u)&(~15u));
45					cached_line_back_data=(UINT32*)malloc(sizeof(UINT32)*span_length);
46					cached_line_back_length=(INT32)span_length;
47
48				}							
49				glReadPixels(0,v->fbi.height-y,v->fbi.width,0,mode,GL_UNSIGNED_BYTE ,cached_line_back_data);
50				cached_line_back_y=y;
51				cached_line_back_width = (INT32)v->fbi.width;
52				
53			}	
54				data[0]=cached_line_back_data[x];
55				data[1]=cached_line_back_data[x+1];		
56			break;
57		}	
58		case 2:
59			//LOG_MSG("VOODOO: /* aux buffer in Use*/ ");
60			mode=GL_DEPTH_COMPONENT;

61			VOGL_SetReadMode(false);
62			glReadPixels(x,(int)v->fbi.height-y,2,1,mode,GL_UNSIGNED_INT,&data);		
63			return ((data[0]>>16)&0xffff) | (data[1] & 0xffff0000);
64			
65		default:
66			E_Exit("read from invalid buf %x",LFBMODE_READ_BUFFER_SELECT(v->reg[lfbMode].u));
67			break;
68	}	
69	return ((RGB_BLUE(data[0])>>3)<<11) | ((RGB_GREEN(data[0])>>2)<<5)  |  (RGB_RED(data[0])>>3) |
70	       ((RGB_BLUE(data[1])>>3)<<27) | ((RGB_GREEN(data[1])>>2)<<21) | ((RGB_RED(data[1])>>3)<<16);
71}

Voodoo Types.h

1/* macros to extract components from rgb_t values */
2#define RGB_ALPHA(rgb)		(((rgb) >> 24) & 0xff)
3#define RGB_RED(rgb)		(((rgb) >> 16) & 0xff)
4#define RGB_GREEN(rgb)		(((rgb) >> 8) & 0xff)
5#define RGB_BLUE(rgb)		((rgb) & 0xff)

"data[0]=cached_line_back_data[x]" and "data[1]=cached_line_back_data[x+1]" are 0 data.

If i change the Code and comment out the the both lines. Data[0] and Data[1] are not null data. There is a HUD Gfx and Heaven but the Color is mismatch. If try to adjust and adjst the Color and adding a return (just for fun) before "break" in the "case 1:". Then it look so:

What is the right color mask code and what is the Output format on return? RGB888? RGB565?

1	return ((RGB_BLUE(data[0])>>3)<<11) | ((RGB_GREEN(data[0])>>2)<<5)  |  (RGB_RED(data[0])>>3) |
2	       ((RGB_BLUE(data[1])>>3)<<27) | ((RGB_GREEN(data[1])>>2)<<21) | ((RGB_RED(data[1])>>3)<<16);

Edit: I make a Video: https://vimeo.com/312670288

zirkoni wrote:

James-F wrote:

GTA doesn't seem to be fooled by this.
Got the GLIDE2X.OVL in the PATH= I have set, the game finds it correctly, without it dosbox crashes.
Any idea?

Which glide2x.ovl is that? The version from a GTA 3Dfx demo seems to work (see attached file).

I'm not sure if this is the right spot but I just wanted to share that the glide2x.ovl from that post got my Screamer 2 working great! I used the original CD plus the S2_3DFX.EXE. For the configuration, I'm using DOSBOX ECE build 4185, output=opengl, cycles=fixed 100000. 80000 cycles seems to work too, 150000 seems to cause slight sound skipping issues.

There is some screen tearing but not really noticeable when you're focused on racing. I use DBGL so there is no glfullvsync in the gui but it appears to be on by default as the status window states VSync is on. Set to true or false does not seem to make a difference. I do know it is a new setting so it is in its infancy. I have an RX480 and a freesync monitor so I might do more playing around on the hardware/driver side of things.

Thanks!

FYI: Since SVN r4260 this patch is broken, because it looks for CPU_Core_Dyn_X86_RestoreDHFPUState(), which seems to have been removed completely. So, unless someone can update the patch, this Voodoo emulator isn't usable any longer. 😢

Yesterplay80 wrote:

FYI: Since SVN r4260 this patch is broken, because it looks for CPU_Core_Dyn_X86_RestoreDHFPUState(), which seems to have been removed completely. So, unless someone can update the patch, this Voodoo emulator isn't usable any longer. 😢

My version of Voodoo chip emulation patch does not have to call that function. That was always the case back then when I cleaned up and produce the my own patch from the source code. I think Kekko did not make a patch for his implementation back then, and his source code was not from clean source of DOSBox SVN, so I had some clean-ups to do.

I maintain my own clean 2-in-1 patch for DOSBox SVN that combines Gulikoza's Glide pass-through and Kekko's Voodoo chip emulation, and only those 2 and nothing else.

kjliew wrote:

I maintain my own clean 2-in-1 patch for DOSBox SVN that combines Gulikoza's Glide pass-through and Kekko's Voodoo chip emulation, and only those 2 and nothing else.

Where can I find your patch? Maybe I should give that one a try then!

I just updated the thread and uploaded the latest patch for recent DOSBox SVN
Re: Voodoo1 emulation and glide pass-through 2-in-1 patch for DOSBox SVN

kjliew wrote:

I just updated the thread and uploaded the latest patch for recent DOSBox SVN
Re: Voodoo1 emulation and glide pass-through 2-in-1 patch for DOSBox SVN

Thanks, I'll fiddle around with your patch when I find som time next weekend.

Looks like the patch stopped working again with the latest SVN changes (possibly related to the OpenGL shader stuff that was added?). Would be great if it could be fixed again! 😀

I have extremely revised the Voodoo Patch for my fork in the past. So that it adapts to the resolution of Dosbox itself and e.g. doesn't have a 640x480 window on the 4K desktop. I mean 1280x1024 in Dosbox Windowed mode use the same Resolution in Voodoo with the Internal Resolution of 1280x1024. I Added a few patches for a few games with shadow problems (under Win9x). Fullscreen/Windows switching works. If you have set fullresolution = desktop it takes the Desktop Resolution.

i moved the DHFPU code to voodoo_interface . However i'm not a super power Voodoo, Opengl Coder. I have spent many time to understand the voodoo code and there are lots of missings. The Based of the Patch is from Mame ~2010 or 2013. I done my Fork because Windows95 Games with QT2x/Qt3 or DirectX3/5 Hardcoded Support and with CDDA Audio Tracks without to heavenly edit on my Host System to run the games.

void Voodoo_PCI_Enable(bool enable) {
v->clock_enabled = enable;
CPU_Core_Dyn_X86_SaveDHFPUState();
Voodoo_UpdateScreenStart();
CPU_Core_Dyn_X86_RestoreDHFPUState();
}

Many old Voodoo Games (Dos/Win9x) works great 😀

You can take the code from Github Repo.
https://github.com/MartyShepard/DOSBox-Optionals

Genju wrote on 2020-03-28, 07:20:

Looks like the patch stopped working again with the latest SVN changes (possibly related to the OpenGL shader stuff that was added?). Would be great if it could be fixed again! 😀

If you look at the .rej files, then they are indeed simple enough to be merged by hand.