VOGONS


dgVoodoo 2 for DirectX 11

Topic actions

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

First post, by robertmo

User metadata
Rank l33t++
Rank
l33t++

dgVoodoo 2 for DirectX 11
http://dege.freeweb.hu/

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.

Attachments

  • dgvoodoosetup.png
    Filename
    dgvoodoosetup.png
    File size
    28.64 KiB
    Views
    85684 views
    File license
    Fair use/fair dealing exception

Reply 5 of 3949, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

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

Attachments

  • carma.png
    Filename
    carma.png
    File size
    333.77 KiB
    Views
    85581 views
    File license
    Fair use/fair dealing exception

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

Reply 10 of 3949, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

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

Attachments

  • EA.png
    Filename
    EA.png
    File size
    227.11 KiB
    Views
    85461 views
    File license
    Fair use/fair dealing exception

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

Reply 12 of 3949, by robertmo

User metadata
Rank l33t++
Rank
l33t++

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 😉

Reply 13 of 3949, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

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

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

Reply 17 of 3949, by Dege

User metadata
Rank l33t
Rank
l33t

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

Reply 18 of 3949, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

😉

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...? 😉 😁

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