VOGONS


VIDEO - 3dfx voodoo emulation (SDL1)

Topic actions

Reply 80 of 139, by tlk

User metadata
Rank Newbie
Rank
Newbie

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).

Reply 81 of 139, by Serious Callers Only

User metadata
Rank Member
Rank
Member

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).

Reply 82 of 139, by tlk

User metadata
Rank Newbie
Rank
Newbie
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...

Reply 83 of 139, by tlk

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 84 of 139, by Serious Callers Only

User metadata
Rank Member
Rank
Member

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.

Reply 85 of 139, by fyatwyrio

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 86 of 139, by fyatwyrio

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 87 of 139, by tlk

User metadata
Rank Newbie
Rank
Newbie
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...

Reply 88 of 139, by leileilol

User metadata
Rank l33t++
Rank
l33t++

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.

apsosig.png
long live PCem

Reply 89 of 139, by DMJC

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 90 of 139, by Marty2dos

User metadata
Rank Newbie
Rank
Newbie

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.

UINT32 voodoo_ogl_read_pixel(int x, int y) {
UINT32 data[2];
UINT32 mode=GL_RGBA;
UINT32 j;

if ((x < 0) || (y < 0) || (x >= (INT32)v->fbi.width) || (y >= (INT32)v->fbi.height)){
return 0xffffffff;
}
switch (LFBMODE_READ_BUFFER_SELECT(v->reg[lfbMode].u)) {

case 0:
//LOG_MSG("VOODOO: /* front buffer in use */ ");
VOGL_SetReadMode(true);
if ((cached_line_front_y != y) || (x+1 >= cached_line_front_width)) {
if (cached_line_front_length<(INT32)v->fbi.width) {

if (cached_line_front_data!=NULL)
{
free(cached_line_front_data);
}

size_t span_length=((v->fbi.width+64u)&(~15u));
cached_line_front_data=(UINT32*)malloc(sizeof(UINT32)*span_length);
cached_line_front_length=(INT32)span_length;
}
glReadPixels(0,(int)v->fbi.height-y,(int)v->fbi.width,1,mode,GL_UNSIGNED_BYTE ,cached_line_front_data);
cached_line_front_y=y;
cached_line_front_width = (INT32)v->fbi.width;
}
data[0]=cached_line_front_data[x];
data[1]=cached_line_front_data[x+1];
break;

case 1:
{
//LOG_MSG("VOODOO: /* back buffer */ ");
VOGL_SetReadMode(false);
if ((cached_line_back_y != y) || (x+1 >= cached_line_back_width)) {
if (cached_line_back_length<(INT32)v->fbi.width) {
if (cached_line_back_data!=NULL)
{
free(cached_line_back_data);
}
size_t span_length=((v->fbi.width+64u)&(~15u));
cached_line_back_data=(UINT32*)malloc(sizeof(UINT32)*span_length);
cached_line_back_length=(INT32)span_length;

}
glReadPixels(0,v->fbi.height-y,v->fbi.width,0,mode,GL_UNSIGNED_BYTE ,cached_line_back_data);
cached_line_back_y=y;
cached_line_back_width = (INT32)v->fbi.width;

}
data[0]=cached_line_back_data[x];
data[1]=cached_line_back_data[x+1];
break;
}
case 2:
//LOG_MSG("VOODOO: /* aux buffer in Use*/ ");
mode=GL_DEPTH_COMPONENT;
Show last 12 lines
			VOGL_SetReadMode(false);
glReadPixels(x,(int)v->fbi.height-y,2,1,mode,GL_UNSIGNED_INT,&data);
return ((data[0]>>16)&0xffff) | (data[1] & 0xffff0000);

default:
E_Exit("read from invalid buf %x",LFBMODE_READ_BUFFER_SELECT(v->reg[lfbMode].u));
break;
}
return ((RGB_BLUE(data[0])>>3)<<11) | ((RGB_GREEN(data[0])>>2)<<5) | (RGB_RED(data[0])>>3) |
((RGB_BLUE(data[1])>>3)<<27) | ((RGB_GREEN(data[1])>>2)<<21) | ((RGB_RED(data[1])>>3)<<16);
}

Voodoo Types.h

/* macros to extract components from rgb_t values */
#define RGB_ALPHA(rgb) (((rgb) >> 24) & 0xff)
#define RGB_RED(rgb) (((rgb) >> 16) & 0xff)
#define RGB_GREEN(rgb) (((rgb) >> 8) & 0xff)
#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:
aufnhame00049.jpg

aufnhame00051.jpg

aufnhame00052.jpg

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

	return ((RGB_BLUE(data[0])>>3)<<11) | ((RGB_GREEN(data[0])>>2)<<5)  |  (RGB_RED(data[0])>>3) |
((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

Reply 91 of 139, by GiSWiG

User metadata
Rank Member
Rank
Member
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!

Steamer/GOG-er: ASUS Crosshair IV Formula | AMD Phenom II X6 1100T 3.7GHz all cores | Mushkin 8GB DDR3 RAM 1333 w/ 6-6-6-18 1T | Dual AMD Radeon HD 6850s in CrossFireX | X-Fi Titanium | Dual-boot Windows XP and Vista

Reply 92 of 139, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

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 full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 93 of 139, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 94 of 139, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
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!

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 96 of 139, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
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.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 97 of 139, by Genju

User metadata
Rank Newbie
Rank
Newbie

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! 😀

Reply 98 of 139, by Marty2dos

User metadata
Rank Newbie
Rank
Newbie

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 😀
aufnhame00062cyj4y.pngaufnhame00063ppkz5.pngaufnhame0006421jz2.pngaufnhame00065jukg4.pngaufnhame00066kwjdt.pngaufnhame000676ej19.pngaufnhame00068sekt8.pngaufnhame000695jkt8.pngaufnhame000713vjyl.pngaufnhame00072cijtp.pngaufnhame00073kdjnh.pngaufnhame00074fuk7l.pngaufnhame000754zksj.pngaufnhame000768xkmh.pngaufnhame00077apj0e.pngaufnhame00078ydkux.pngaufnhame000797xkd0.png

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

Reply 99 of 139, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
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.