OK, so let's start the discussion.
Does it work for anyone? the setup doesn't detect anything to choose from for me. I thought it was cause of winxp that doesn't support directx 11, but the same happens in win vista and 7.

The wrapper runs very fast for me, even on the above Ati card. Perhaps nGlide is a bit faster, but I'd have to benchmark it to make sure. One bug I found is that the HUD elements are not displayed in Carmageddon (works with nGlide, so it's hopefully not something I broke )

btw dosbox works faster with cycles max 105% (105 is actually 95%, while 100 is 90). It was left like that to be comparable with older dosbox versions that had 90% limit. 90 was called 100 so that people don't ask how to set 100.

I've fixed Extreme Assault LFB access, but there's still corruption visible (both nGlide and dgVoodoo). These stripes obviously come from LFB writes, if I disable LFB access, they're gone (and so is the HUD). I don't know where the problem is, since any access to the LFB goes directly to the wrapper...

you can run windows in dosbox i had gothic running, some time ago with kekko's pach. too bad i didn't make a screenshot as i couldn't reproduce that later as don't remember what i did (though it was all in different shades of gray (no textures) ). and i didn't make a screenshot cause i wanted to make one with textures

Took a hint from the nGlide compatibility page and updated EA to v 1.23. The corruption is gone, but it's now the same as with the old Glide patch version. Oh well...I thought rewriting the LFB handling would fix v1.01 (and the demo)

(to be clear, I was trying to fix the problems mentioned in "Tips and known issues" from the dgVooodoo2 README - perhaps the stride limit needs to be removed from dgvoodoo?)

(to be clear, I was trying to fix the problems mentioned in "Tips and known issues" from the dgVooodoo2 README - perhaps the stride limit needs to be removed from dgvoodoo?)

Well, as far as I remember, I run into 2 problems with lfb access (correct me if I'm wrong) in your internal wrapping solution in DOSBox:

- If something locks 2 different buffers simultaneously (like EA does with backbuffer and depthbuffer) then both of the locks return the same buffer pointer

- (Early) Voodoo cards organized their video memory in a way that a scanline is 1024 pixel width independently on the resolution used. It means that a lock stride is 2048 bytes for 16 bit lock formats and 4096 for 32 bit lock formats (EA hard-wires 2048 bytes, it does'nt care the stride returned from the lock call.)AFAIR, you assume that the stride is 2*xResolution for some reason, so dgVoodoo cannot return the expected 2048 or 4096. Yesterday I came across this problem again in GTA: if no PCI emulation was enabled, then the stride came from the DX driver which was not exactly 2*xResolution, so the texts got corrupted (800x600). If PCI emulation was enabled then the stride came from an internal buffer which used 2*xResolution, and the text were correct.

Unfortunately the returned stride cannot be affected in any way through the setup, so a new dgVoodoo build needed even if you fix the mentioned problems. Maybe I will assign the returned stride to the selected card type.

By the way, thanks for developing glide support into DOSBox! I can't imagine otherwise how I would have played the first 3 episode of Blood (yes, I want it only in 3Dfx)! I love it!

The setup program detects my NV GTX590 fine, but all I see is a black screen and a mouse pointer when entering the 3D world of F22 TAW.

It is an untested game. I will have a look at this.
(Oh, man, it's beginning... This is what I wanted to avoid. All my plan was quickly finish the new version, iteratedly fix obvious bugs, and abandon it, when it just works... )

1. The simultaneous locks have been added in my internal build (I'll have to test it a bit more, but seems working for now...I try to release the code ASAP )

2. I checked the code and as far as I could see, the stride that was received from the wrapper was passed on to the application without change. info->strideInBytes was set as 2*width as a default before the call (in case LFB locks were disabled and not passed on to the wrapper). I have reworked this and it is now only set if locks are disabled. The other problem was that LFB was limited to 1024x768x2. This limit has also been increased. Perhaps you could post (or send me) a build which sets stride as intended and I'll see what happens now?

Dege wrote:(Oh, man, it's beginning... This is what I wanted to avoid. All my plan was quickly finish the new version, iteratedly fix obvious bugs, and abandon it, when it just works... )