Setup works for me, even with a low ATi 4850. Haven't tried running anything yet 😀

I got nvidia 285 gtx
(latest directx and nvidia drivers installed)
does it work for anyone on nvidia?

According to Wikipedia, 285 does not support Direct3D 10.1:

Direct3D 10.0:
Shader Model 4.0
(GTS250, GTX 260-295)

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.

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 😜)

and where is the mirror? 😀

and don't forget you broke Tie Break Tennis 98 😀

What's Tie Break Tennis 98? 😜

Coincidentally it only shows something with dgVoodoo2 😉

This looks too good not to be posted here...yes running with dgVoodoo2 😎

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

How the hell are you running unreal (a windows game) in dosbox ?

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?)

your running either win7 or 8 (because earlier versions dont support dx11) in dosbox in win 7 or win 8
thats doesnt make sense

Unreal requires Glide, so win95/98 is sufficient (and that's what's running in dosbox). dgVoodoo needs dx11, so dosbox runs in w7 😀

Davros where have you been for last 6 years?

Hi All!

It's been a long time I posted here... 😊

(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... 😁 😁 )

Release the code...? 😉 😁

Ok, great!

Tomorrow I will make a new build and send it to you.

Release the code...?

Hmm.... But then I would have to release all my libs dgVoodo relies on. 😁 I will deliberate on this.

Edit: set -> send[/u]