VOGONS

Common searches


VIDEO - 3dfx voodoo emulation (SDL1)

Topic actions

Reply 80 of 96, 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 96, 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 96, 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 96, 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 96, 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 96, 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 96, 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 96, 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 96, 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.

by the way, DOSBox is not for running Windows 9x

Reply 89 of 96, 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 96, 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 96, 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 96, by Yesterplay80

User metadata
Rank Member
Rank
Member

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 (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 93 of 96, 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 96, by Yesterplay80

User metadata
Rank Member
Rank
Member
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 (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 96 of 96, by Yesterplay80

User metadata
Rank Member
Rank
Member
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 (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)