3dfx voodoo chip emulation

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

Re: 3dfx voodoo chip emulation

Postby Miki Maus » 2010-9-25 @ 16:53

Reporting that Whiplash and Starfighter 3000 now work. Carmageddon on the other hand throws GPF.

And a question: Is rasterizer fully software or is it hardware accelerated?
User avatar
Miki Maus
Member
 
Posts: 197
Joined: 2004-10-18 @ 22:19
Location: Cave

Re: 3dfx voodoo chip emulation

Postby kekko » 2010-9-25 @ 19:39

try using ovl/dos4gw from a working game. the rasterizer is written in software.
User avatar
kekko
Member
 
Posts: 480
Joined: 2004-3-24 @ 18:56

Re: 3dfx voodoo chip emulation

Postby robertmo » 2010-9-26 @ 06:36

here is what i noticed in dosbox, i wonder whether it is true for all dos games:

http://www.falconfly.de/voodoo1.htm

the .ovl from here works in pure dos:
Diamond Monster 3D V1.08,

the .ovl from here works in pure dos:
Orchid Righteous 3D V3.00.00
Diamond Monster 3D V1.10

the .ovl from here doesn't work in pure dos but works inside windows:
3dfx Voodoo1 V2.16
3dfx Voodoo1 V3.00.01
Diamond Monster 3D V4.10.01.1600

the .ovl from here doesn't work in pure dos but works inside windows:
3dfx Voodoo1 V3.01.00
Last edited by robertmo on 2010-9-26 @ 09:52, edited 1 time in total.
User avatar
robertmo
l33t
 
Posts: 4758
Joined: 2003-6-18 @ 10:35

Re: 3dfx voodoo chip emulation

Postby robertmo » 2010-9-26 @ 08:30

about the quake3 differences on different windows: right now the only difference is that on win98fe game has more blury textures
Last edited by robertmo on 2010-9-26 @ 09:50, edited 1 time in total.
User avatar
robertmo
l33t
 
Posts: 4758
Joined: 2003-6-18 @ 10:35

Re: 3dfx voodoo chip emulation

Postby robertmo » 2010-9-26 @ 08:42

while redguard looks ok,

some dos games don't have 2d statistics/letters on 3d pictures:
screamer 2
grand theft auto

carmageddon and pyl also have black screen menus and i have to navigate menu blindly to get to the game
User avatar
robertmo
l33t
 
Posts: 4758
Joined: 2003-6-18 @ 10:35

Re: 3dfx voodoo chip emulation

Postby kekko » 2010-9-26 @ 12:53

h-a-l-9000 wrote:They use the TrexInit1 reg to make the texturing chip output config data instead of pixel data. Apparently there is no other way to read from these chips.


Finally found the trexinit1 register on voodoo3 specs; when writing bit 18 (send_config) to that register, the renderer gives tmu config data as result, using it as texel during rendering.
If bit 6 of tmu config is true, second tmu is detected.
Now both tmus are correctly detected, for a total of 8mb texture ram :)
User avatar
kekko
Member
 
Posts: 480
Joined: 2004-3-24 @ 18:56

Re: 3dfx voodoo chip emulation

Postby OSH » 2010-9-26 @ 13:07

Kekko, great work! I'm waiting impatiently for binary test version!!!
User avatar
OSH
Member
 
Posts: 183
Joined: 2007-10-28 @ 23:34

Re: 3dfx voodoo chip emulation

Postby kekko » 2010-9-26 @ 14:31

robertmo wrote:while redguard looks ok,

some dos games don't have 2d statistics/letters on 3d pictures:
screamer 2
grand theft auto

carmageddon and pyl also have black screen menus and i have to navigate menu blindly to get to the game


that happened because 16bit lfb write access was not implemented yet.
Here's the modified code, fixes 16bit writes, tmu config detection and window width.
The graphics should be fine now. Let me know if you notice any relevant rendering error.
Attachments
dosbox_voodoo_20100926.zip
(51.34 KiB) Downloaded 581 times
User avatar
kekko
Member
 
Posts: 480
Joined: 2004-3-24 @ 18:56

Re: 3dfx voodoo chip emulation

Postby gulikoza » 2010-9-26 @ 18:54

Not much for me to add here. Great job everyone! Amazingly how quickly it progressed!
The following patch makes dosbox compile with gcc again. There are two inline asm functions used that have been rewritten in C (very quickly :happy:), if those are performance bottlenecks it might be worthwhile adding the at&t syntax versions for gcc. Also "fixed" a bug...in find_rasterizer the address of a local variable was being returned which crashed dosbox. It's a quick&dirty fix, most likely resulting in memory leaks, but it seems that rasterizer pool that was used in the original code is commented out.
Tested TombRider with Monster 1.08 ovl and seems to work fine (albeit a bit slow) :happyhappy:. A minor issue is that background is not displayed when returning to the menu, but I do remember real 3dfx cards having the same problem!
Attachments
dosbox_3dfx.diff
(3.13 KiB) Downloaded 393 times
User avatar
gulikoza
Oldbie
 
Posts: 1705
Joined: 2004-6-25 @ 14:53

Re: 3dfx voodoo chip emulation

Postby kekko » 2010-9-26 @ 19:40

Hi gulikoza, welcome back :)
thank you for the fixes. The find_rasterizer function has lost much of its meaning, since we don't need the custom rasterizers some arcade machine need; it needs a cleanup, like the rest of the code.
The performance is an issue, I'm still thinking about a way to thread the rasterizer. If you have some good ideas, let me know :)
User avatar
kekko
Member
 
Posts: 480
Joined: 2004-3-24 @ 18:56

Re: 3dfx voodoo chip emulation

Postby h-a-l-9000 » 2010-9-26 @ 19:51

Wonder if the triangle commands could be converted back to glidewrapper/d3d/whatever API calls.
1+1=10
h-a-l-9000
DOSBox Author
 
Posts: 4512
Joined: 2005-2-23 @ 00:14

Re: 3dfx voodoo chip emulation

Postby robertmo » 2010-9-26 @ 19:58

scope in Pył (Pyl) (Dust) is not working
Attachments
pyl.PNG
pyl.PNG (258.87 KiB) Viewed 4710 times
User avatar
robertmo
l33t
 
Posts: 4758
Joined: 2003-6-18 @ 10:35

Re: 3dfx voodoo chip emulation

Postby kekko » 2010-9-26 @ 20:14

h-a-l-9000 wrote:Wonder if the triangle commands could be converted back to glidewrapper/d3d/whatever API calls.


some detection routines are based upon reading lfb after triangles drawing; the lfb itself can be written directly. I'm not sure everything would work the same way.
I'm wondering how the wrappers face the problem...
User avatar
kekko
Member
 
Posts: 480
Joined: 2004-3-24 @ 18:56

Re: 3dfx voodoo chip emulation

Postby gulikoza » 2010-9-26 @ 20:27

Writing to LFB is easy...disable z-buffer and draw a textured quad to the screen (previously "blue-screening" the texture, which was returned to the application as the LFB) and drawing it with alpha test enabled. I've written such code for openglide (before, it was using gldrawpixels which is very slow). LFB reads are slower, but most 3D APIs have support for reading back the buffer (which is slow because it waits for all the drawing operations to finish and then reading back the result). But then again, the wrapper works with Glide calls (grLfbLock()/grLfbUnlock()), I'm not sure how the LFB is handled in the emulation...
User avatar
gulikoza
Oldbie
 
Posts: 1705
Joined: 2004-6-25 @ 14:53

Re: 3dfx voodoo chip emulation

Postby robertmo » 2010-9-27 @ 06:44

carmageddon quits to dos after a short play (the higher gfx details the quicker it quits, with almost lowest details you cannot even make a full circle, while with higherst shortly after first turning)

FATAL devpixmp.c:123
(Glide) (some random ascii chars here often too)

----------

X-wing vs Tie-Fighter movies are messed up, looks like screen is not being properly cleared (the not cleared parts are blinking). I think similar thing happens if you shrink the screen in tomb raider 2 (F3). The game (3d flight) itself doesn't start at all. (i was using xvt flight school which is a demo of xvt, located on a x-wing 95 cd)
Attachments
xvt.PNG
xvt.PNG (49 KiB) Viewed 4615 times
User avatar
robertmo
l33t
 
Posts: 4758
Joined: 2003-6-18 @ 10:35

Re: 3dfx voodoo chip emulation

Postby thedoctor45 » 2010-9-27 @ 15:29

I get this error message when attempting to compile the Voodoo DOSBox source on my Mac OS X machine:

Code: Select all
voodoo_main.cpp
In file included from voodoo_main.cpp:18:
voodoo_data.h:1905: error: integer constant is too large for ‘long’ type
voodoo_data.h:2006: error: integer constant is too large for ‘long’ type
In file included from voodoo_main.cpp:22:
voodoo_func.h:81: error: integer constant is too large for ‘long’ type
voodoo_func.h:89: error: integer constant is too large for ‘long’ type
voodoo_func.h:97: error: integer constant is too large for ‘long’ type
In file included from voodoo_main.cpp:22:
voodoo_func.h:2482: error: integer constant is too large for ‘long’ type


I applied the latest patch from gulikoza - any idea what's wrong?
User avatar
thedoctor45
Newbie
 
Posts: 37
Joined: 2010-7-12 @ 16:40

Re: 3dfx voodoo chip emulation

Postby gulikoza » 2010-9-27 @ 17:01

You can try appending ULL to the large constants (example: 0x7fffffffffffffffULL) on those lines. Constants seem to be interpreted as a 32-bit value even if they are larger
User avatar
gulikoza
Oldbie
 
Posts: 1705
Joined: 2004-6-25 @ 14:53

Re: 3dfx voodoo chip emulation

Postby thedoctor45 » 2010-9-27 @ 20:03

ok I changed the values in voodoo_data.h and those errors are gone now but I don't know what to change in voodoo_func.h

Code: Select all
RASTERIZER(generic_0tmu, 0, v->reg[fbzColorPath].u, v->reg[fbzMode].u, v->reg[alphaMode].u,
User avatar
thedoctor45
Newbie
 
Posts: 37
Joined: 2010-7-12 @ 16:40

Re: 3dfx voodoo chip emulation

Postby thedoctor45 » 2010-9-27 @ 22:50

UPDATE:

I have searched voodoo_data.h for further numbers that could be too long and the problem seems to have vanished now - however it still won't compile

this is what I get now.

Code: Select all
voodoo_func.h: In function ‘void recompute_video_memory(voodoo_state*)’:
voodoo_func.h:44: sorry, unimplemented: inlining failed in call to ‘void VOODOO_ShowMsg(const char*, ...)’: function not inlinable
voodoo_func.h:1280: sorry, unimplemented: called from here
voodoo_func.h:44: sorry, unimplemented: inlining failed in call to ‘void VOODOO_ShowMsg(const char*, ...)’: function not inlinable
voodoo_func.h:1311: sorry, unimplemented: called from here
User avatar
thedoctor45
Newbie
 
Posts: 37
Joined: 2010-7-12 @ 16:40

Re: 3dfx voodoo chip emulation

Postby wd » 2010-9-28 @ 06:20

What compiler exactly are you using? Try checking that function for forced inlining and just remove that.
wd
DOSBox Author
 
Posts: 10818
Joined: 2003-12-03 @ 21:23

PreviousNext

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 3 guests