VIDEO - 3dfx voodoo emulation (SDL1)

Here you can discuss the development of patches.

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby tlk » 2018-2-27 @ 18:47

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).
tlk
Newbie
 
Posts: 11
Joined: 2017-7-12 @ 22:55

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby Serious Callers Only » 2018-3-18 @ 10:30

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
Member
 
Posts: 376
Joined: 2003-4-26 @ 21:34

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby tlk » 2018-3-21 @ 17:04

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...
tlk
Newbie
 
Posts: 11
Joined: 2017-7-12 @ 22:55

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby tlk » 2018-3-21 @ 17:10

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.
tlk
Newbie
 
Posts: 11
Joined: 2017-7-12 @ 22:55

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby Serious Callers Only » 2018-4-12 @ 16:44

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.
Serious Callers Only
Member
 
Posts: 376
Joined: 2003-4-26 @ 21:34

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby fyatwyrio » 2018-4-19 @ 21:37

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.
fyatwyrio
Newbie
 
Posts: 3
Joined: 2009-3-02 @ 23:33

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby fyatwyrio » 2018-4-20 @ 15:02

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.
fyatwyrio
Newbie
 
Posts: 3
Joined: 2009-3-02 @ 23:33

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby tlk » 2018-4-21 @ 17:31

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...
tlk
Newbie
 
Posts: 11
Joined: 2017-7-12 @ 22:55

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby leileilol » 2018-5-04 @ 02:07

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
User avatar
leileilol
l33t++
 
Posts: 9801
Joined: 2006-12-16 @ 18:03

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby DMJC » 2018-5-21 @ 21:07

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.
DMJC
Newbie
 
Posts: 8
Joined: 2010-2-24 @ 13:24

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby Marty2dos » 2019-1-22 @ 06:34

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? ... =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.

Code: Select all
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;
         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
Code: Select all
/* 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:
Image

Image

Image


What is the right color mask code and what is the Output format on return? RGB888? RGB565?
Code: Select all
   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
Marty2dos
Newbie
 
Posts: 35
Joined: 2013-6-04 @ 01:43

Re: 3dfx voodoo chip emulation is back!

Postby GiSWiG » 2019-2-06 @ 05:32

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
GiSWiG
Member
 
Posts: 229
Joined: 2013-2-28 @ 18:43

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby Yesterplay80 » 2019-10-01 @ 09:26

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. :cry:
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 440
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby kjliew » 2019-10-01 @ 12:46

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. :cry:

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
Member
 
Posts: 479
Joined: 2004-1-08 @ 03:03

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby Yesterplay80 » 2019-10-01 @ 13:36

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)
User avatar
Yesterplay80
Member
 
Posts: 440
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby kjliew » 2019-10-01 @ 14:00

I just updated the thread and uploaded the latest patch for recent DOSBox SVN
viewtopic.php?f=32&t=42449&p=789805#p406327
kjliew
Member
 
Posts: 479
Joined: 2004-1-08 @ 03:03

Re: VIDEO - 3dfx voodoo emulation (SDL1)

Postby Yesterplay80 » 2019-10-01 @ 14:30

kjliew wrote:I just updated the thread and uploaded the latest patch for recent DOSBox SVN
viewtopic.php?f=32&t=42449&p=789805#p406327

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)
User avatar
Yesterplay80
Member
 
Posts: 440
Joined: 2016-2-23 @ 11:02
Location: Germany

Previous

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest