VOGONS


3dfx voodoo chip emulation

Topic actions

  • This topic is locked. You cannot reply or edit posts.

Reply 102 of 386, by robertmo

User metadata
Rank l33t++
Rank
l33t++

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-09-26, 09:52. Edited 1 time in total.

Reply 105 of 386, by kekko

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

Reply 107 of 386, by kekko

User metadata
Rank Member
Rank
Member
robertmo wrote:
while redguard looks ok, […]
Show full quote

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

Reply 108 of 386, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

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 😀), 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) 😁. 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

  • Filename
    dosbox_3dfx.diff
    File size
    3.13 KiB
    Downloads
    400 downloads
    File license
    Fair use/fair dealing exception

http://www.si-gamer.net/gulikoza

Reply 109 of 386, by kekko

User metadata
Rank Member
Rank
Member

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 😀

Reply 112 of 386, by kekko

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

Reply 113 of 386, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

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

http://www.si-gamer.net/gulikoza

Reply 114 of 386, by robertmo

User metadata
Rank l33t++
Rank
l33t++

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
    Filename
    xvt.PNG
    File size
    49 KiB
    Views
    4704 views
    File license
    Fair use/fair dealing exception

Reply 115 of 386, by thedoctor45

User metadata
Rank Newbie
Rank
Newbie

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

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?

Reply 118 of 386, by thedoctor45

User metadata
Rank Newbie
Rank
Newbie

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.

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