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?

try using ovl/dos4gw from a working game. the rasterizer is written in software.

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

about the quake3 differences on different windows: right now the only difference is that on win98fe game has more blury textures

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

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 😀

Kekko, great work! I'm waiting impatiently for binary test version!!!

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.

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!

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 😀

Wonder if the triangle commands could be converted back to glidewrapper/d3d/whatever API calls.

scope in Pył (Pyl) (Dust) is not working

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

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

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)

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

1voodoo_main.cpp
2In file included from voodoo_main.cpp:18:
3voodoo_data.h:1905: error: integer constant is too large for ‘long’ type
4voodoo_data.h:2006: error: integer constant is too large for ‘long’ type
5In file included from voodoo_main.cpp:22:
6voodoo_func.h:81: error: integer constant is too large for ‘long’ type
7voodoo_func.h:89: error: integer constant is too large for ‘long’ type
8voodoo_func.h:97: error: integer constant is too large for ‘long’ type
9In file included from voodoo_main.cpp:22:
10voodoo_func.h:2482: error: integer constant is too large for ‘long’ type

I applied the latest patch from gulikoza - any idea what's wrong?

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

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

1RASTERIZER(generic_0tmu, 0, v->reg[fbzColorPath].u, v->reg[fbzMode].u, v->reg[alphaMode].u,

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.

1voodoo_func.h: In function ‘void recompute_video_memory(voodoo_state*)’:
2voodoo_func.h:44: sorry, unimplemented: inlining failed in call to ‘void VOODOO_ShowMsg(const char*, ...)’: function not inlinable
3voodoo_func.h:1280: sorry, unimplemented: called from here
4voodoo_func.h:44: sorry, unimplemented: inlining failed in call to ‘void VOODOO_ShowMsg(const char*, ...)’: function not inlinable
5voodoo_func.h:1311: sorry, unimplemented: called from here

What compiler exactly are you using? Try checking that function for forced inlining and just remove that.