CoolGamer wrote on 2020-02-02, 19:00:

danoon, […]
Show full quote

danoon,

Thanks for the Boxedwine project. It is amazing to be able to use the wine compatibility layer under Windows operating systems. I ran the Star Wars Racer demo under Boxedwine on my Windows 7 pc and it worked fine. Wine DirectX implementation has known issues with that game (missing fog, etc.), but the game runs.

I have a feature request. Is it possible to implement passthrough from boxedwine to host Windows system for DirectX? This way we can use directx wrappers such as dgVoodoo2 for old directx games (DirectX 1 to 9) running under Boxedwine. You just have to provide passthrough for DDraw.dll, D3D8.dll and D3D9.dll files for dgVoodoo2 wrapper to work. Please let me know if this is possible.

DirectX passthrough can give Boxedwine an edge over wine running under native linux computers.

Thanks.

dgVoodoo2 and other wrappers work under Wine on Linux; for DirectX9, 10, and 11 it is recommended to use dxvk, which translates DirectX to Vulkan allowing for near-native speed - you can just drop dll in Wine on Linux, or it comes preinstalled with Proton (in Steam)

Vulkan is on my radar, I think sometime this year I will see what it will take to do passthrough with it. OpenGL passthrough in Boxedwine was a pretty big effort.

For now I was able to get Motorhead Playable 3DFX Demo to work with the Windows 64-bit build and Wine 4.0 (I didn't try other combinations). I installed nGlide, then set Wine to "Windows 98" with winecfg and installed the demo. It was very smooth to play.

danoon wrote on 2020-02-04, 03:48:

Vulkan is on my radar, I think sometime this year I will see what it will take to do passthrough with it. OpenGL passthrough in Boxedwine was a pretty big effort.

Is it possible to implement the DirectX passthrough that I mentioned in my post after you are done with Vulkan? Why is the passthrough a big effort? As far as I understand, Boxedwine acts like a "virtual machine/sandbox". Can you just do a quick & dirty implementation where you allow the directx game to directly access ddraw.dll of the Windows host, bypassing the supervision of the sandbox?

I want to clarify that the DirectX passthrough that I requested should be optional, in case some people want to use the DirectX to OpenGL/Vulkan conversion offered by the Wine project. Some games might benefit from the DirectX passthrough, while the others might work better with Wine's internal Directx to OpenGL conversion wrapper.

CoolGamer wrote on 2020-02-04, 18:31:

danoon wrote on 2020-02-04, 03:48:

Vulkan is on my radar, I think sometime this year I will see what it will take to do passthrough with it. OpenGL passthrough in Boxedwine was a pretty big effort.

Is it possible to implement the DirectX passthrough that I mentioned in my post after you are done with Vulkan? Why is the passthrough a big effort? As far as I understand, Boxedwine acts like a "virtual machine/sandbox". Can you just do a quick & dirty implementation where you allow the directx game to directly access ddraw.dll of the Windows host, bypassing the supervision of the sandbox?

I want to clarify that the DirectX passthrough that I requested should be optional, in case some people want to use the DirectX to OpenGL/Vulkan conversion offered by the Wine project. Some games might benefit from the DirectX passthrough, while the others might work better with Wine's internal Directx to OpenGL conversion wrapper.

Virtual machines are pretty complicated. And the complicated part isn't even the CPU emulation, its the memory. In a real machine each 32-bit process can control its own 4GB address space. With Windows all older exe's load into the same address at 0x400000. To do this, real machines have MMUs (Memory Management Unit). This will map the address in a process to physical memory. In a VM I have to implement the MMU and map the emulated memory to host memory. To make it more confusing, the MMU operates on chunks of 4096 bytes of memory called pages. So page 1 at 0x400000 could map to one host memory location and page 2 at 0x401000 could map to a completely unrelated part of memory on the host that is not next to page one.

So when a game wants to upload a texture to the video card it will pass a pointer (location to memory) to DirectX/OpenGL. If that texture doesn't fit in a single page (this is most likely), then that means it will span multiple pages, so I can't just give the page 1 memory location the emulator is mapped into to the host DirectX/OpenGL. I have to allocation new memory, copy the texture into it, then give that memory to the host API. This is called marshaling data and I have to do the same thing when the game calls an API that will fill in a pointer (the other direction compared to uploading a texture). Now imagine the API passes a structure and in that structure there are multiple pointers, everything needs to get marshaled.

To do this marshaling, I created my own library, libGL, that runs in my Linux VM, this will forward every possible OpenGL call (I've done about 1400 so far). Then in BoxedWine, I have to write code that libGL can communicate to, which is another 1400 functions. Each one of these functions I have to understand how the data needs to be marshaled. Sometimes in OpenGL it will pass a pointer and I don't know how to calculate the size of memory it uses, sometimes I just guess.

It probably took me 3 months of work to get OpenGL pass through to work. This time was because of the number of APIs and figuring out how to marshal the more complicated APIs. And even now I know some of the APIs are not correct.

Because of DirectX to OpenGL translation that Wine performs and my own marshaling of OpenGL calls, there is some overhead when it comes to performance, but for older games this seems to more than fine. At first I focused on late 90s direct draw games for Boxedwine, but now I'm starting to test more recent Direct3D 9 games and I haven't noticed OpenGL performance problems, I'm limited by my CPU emulation speed.

danoon,

Thanks for the detailed explanation. Passthrough is far more complicated than I thought. OpenGL passthrough that you implemented works great and gives Boxedwine an edge. I don't have a GPU with Vulkan support, but I am sure that Vulkan users are looking forward to Vulkan passthrough. In the distant future, if DirectX passthrough gets implemented, it will be much appreciated on my end 😀. If it is not a priority, don't worry about it. I now understand that you will have to program something at least as complicated as a DirectX 1-11 API wrapper (all on your own from scratch) in order to make passthrough work.

In the mean time, I have a bug report. I could not get dgVoodoo2's Glide and DirectX wrappers to work under Boxedwine. Please note that dgVoodoo2's output is in DirectX11. dreamer stated in his post (above) that dgVoodoo2 works under Wine on Linux. I don't have a real linux system to test, but see if you can make dgVoodoo2 run under your real linux machine first.

I tested dgVoodoo2 Glide wrapper with Motorhead Playable 3DFX Demo under Boxedwine. nGlide works as you stated in your post, but dgVoodoo2 Glide wrapper does not work. I could not even get the control panel (dgVoodooCpl.exe) to work.

I tested dgVoodoo2 DirectX wrapper with Star Wars Episode I Racer Demo and Motorhead Playable DirectX Demo under Boxedwine. dgVoodoo2 did not work with either demo.

You can download the latest Work In Progress version of dgVoodoo2 from the vogons post linked below. I don't know if you are familiar with the dgVoodoo2 wrapper or not, but I can tell you that it has excellent compatibility, speed and features. It supports DirectX 1-9 and Glide. Just place the wrapper DLLs , control panel (dgVoodooCpl.exe) and the configuration file (dgVoodoo.conf) into the game directory and you will be all set. You can play with the wrapper options using the control panel if you want, but the default options are good enough to run the games.
Re: dgVoodoo 2.6.x and related WIP versions

Not a bug.
nglide works because it supports D3D9 output which dgvoodoo2 does not. As he stated above he has to code for that and I doubt he would code DX11 to OGL which would be ridiculous.
Dgvooodoo 1.50 may work but you'd be better off with nglide.

You can probably check out zeck's OpenGL-based GlideWrapper084c in BoxedWine since it has a decent implementation of OpenGL pass-through. Zeck's GlideWrapper is also a fairly compatible Glide wrapper.

Ah this looks good too, will have to check this and winevdm out.

Just a quick status update.

SSE2 is finished for both the normal and x64 cores and will be in the next release.

Currently I'm working on fixing some games that didn't work. So far I fixed

• GOG Diablo Hellfire: The installer was fixed and Diablo now works. Hellfire just shows a black screen, just like Wine under Linux
• GOG Tomb Raider 3 now works, if you add -setup as a command line argument when launching the game
• Half Life Uplink demo now works
• Mech Warrior 3 now works

I'm also experimenting with Wine 5.0. So far out of the 100 or so games I regularly test, 95 of them are working.

Now that I got SSE2 working, I decided to recompile Wine 5 with the march compiler option set to pentium4. So far so good, Quake 2 OpenGL runs 20% faster.

For the x64 dynamic recompiler, the indirect jump have always given me performance trouble. To translate a random EIP to a host location requires a lookup. To conserve memory I use a 2d array for this lookup based on [page][offset in page].

141 BA 0C 00 00 00    mov         r10d,0Ch  
2C4 42 AB F7 C1       shrx        r8,r9,r10                 // get page
341 BA FF 0F 00 00    mov         r10d,0FFFh  
4C4 42 B2 F5 CA       pext        r9,r9,r10                 // get offset
54D 8B 95 98 04 00 00 mov         r10,qword ptr [r13+498h]  // mov eipToHostInstruction to a reg
64F 8B 14 C2          mov         r10,qword ptr [r10+r8*8]  // get the page from eipToHostInstruction
74F 8B 14 CA          mov         r10,qword ptr [r10+r9*8]  // get the host location from page[offset]
866 45 8B 0A          mov         r9w,word ptr [r10]        // just to make sure the host location is not 0
941 FF E2             jmp         r10  

As you can see, it takes a good amount of work to take the eip stored in R9, split it into a page and offset, then do the multiple memory reads to find the host address to jump to.

I'm experimenting with an idea to use just a 1 dimensional array using reserved (uncommitted) virtual memory. For each emulated process this is 4GB * sizeof(void*), thus 32GB. That is a big chunk of address space. I'm not sure about other platforms, but at least on windows, there is an 8TB address space limit, and since each process already reserves 8GB of address space for other things, at 40GB of address space per process, this means Boxedwine would be limited to less than 200 emulated processes. I don't think that would be a problem.

Now the instruction to do an indirect jump is

143 FF 24 CE          jmp         qword ptr[r14 + r9 * 8]

where r14 holds the address of the 32GB uncommited allocation and r9 hold the EIP.

So as you can see, the emulated indirect jump can now be recompiled to a 4 byte single instruction (1 mem read), down from 44 byte, 9 instructions with 4 reads.

Performance Tests:
Video DD improved 14.6%
Quake 2 800x600 GL improved 8.4%
3dMark 2001 SE improved 6.2%

3dMark 2001 SE score on my i7 6700k with Nvidia 1070
Boxedwine with Wine 5: 24445
Host computer: 83461

I tried out the same 3DMark 2001 SE inside VMWare Player 15 with video card acceleration. I even verified in the host task manager that the VMWare was using the GPU. Although I don't think T&L works without acceleration. The score for VMWare was 19894. I wasn't expecting Boxedwine to beat VMWare. I use VMWare a lot and haven't really noticed it being slow, but usually I don't do 3D stuff in it. Perhaps the CPU emulation is much faster than Boxedwine but VMWare is slow when it comes to Direct3D?

Does anyone else have experience running Direct3D or OpenGL in VMWare and notice performance issues?

I put up the first beta for 20R1 for Windows 64-bit.

https://sourceforge.net/projects/boxedwine/fi … it.zip/download (2MB)

The big change for this release is that if you don't pass in any arguments, it will now launch a platform independent UI written in OpenGL with https://github.com/ocornut/imgui

The release is now just a single executable. When launched it will download the Wine file system. By default it will download Wine 5.0, but you can also choose other Wine versions. And to make it easy to test out, I added a few demos to the UI that it can download and install.

The UI works well on Mac and Linux too. I'm still working on the x64 CPU core for those platforms. They run about 1/2 the games that the Windows build can run. I suspect there are just a couple more bugs around exception handling.

Feedback welcome on the UI. I'm looking for things you felt were confusing, missing features and maybe just some helpful suggestions.

danoon,

Not sure if you care about v19 or 32bit anymore but:

Attempted to try Quake 2 but receive the following error. If I use Mesa3D (OGL to GDI) or QindieGL (OGL to D3D) then OGL does work.

The GUI is glitching out on me so I'm using the command line. I'm checking to see if the GUI issue is my configuration or not before I post about it.

Great work on this emulator.

0014:err:service:process_send_command service protocol error - failed to write p
ipe!
Pixel Format: 32 bit (8880) accelerated:single buffered depth=24 stencil=0 accum
=64
Pixel Format: 32 bit (8888) accelerated:single buffered depth=24 stencil=0 accum
=64
Pixel Format: 32 bit (8880) accelerated:single buffered depth=24 stencil=8 accum
=64
Pixel Format: 32 bit (8888) accelerated:single buffered depth=24 stencil=8 accum
=64
Pixel Format: 32 bit (8880) accelerated:single buffered depth=0 stencil=0 accum=
64
Pixel Format: 32 bit (8888) accelerated:single buffered depth=0 stencil=0 accum=
64
Pixel Format: 32 bit (8880) accelerated:single buffered depth=0 stencil=8 accum=
64
Pixel Format: 32 bit (8888) accelerated:single buffered depth=0 stencil=8 accum=
64
Pixel Format: 32 bit (8880) accelerated:double buffered depth=24 stencil=0 accum
=64
Pixel Format: 32 bit (8888) accelerated:double buffered depth=24 stencil=0 accum
=64
Pixel Format: 32 bit (8880) accelerated:double buffered depth=24 stencil=8 accum
=64
Pixel Format: 32 bit (8888) accelerated:double buffered depth=24 stencil=8 accum
=64
Pixel Format: 32 bit (8880) accelerated:double buffered depth=0 stencil=0 accum=
64
Pixel Format: 32 bit (8888) accelerated:double buffered depth=0 stencil=0 accum=
64
Pixel Format: 32 bit (8880) accelerated:double buffered depth=0 stencil=8 accum=
64
Pixel Format: 32 bit (8888) accelerated:double buffered depth=0 stencil=8 accum=
64
Pixel Format: 32 bit (8880) accelerated:double buffered depth=24 stencil=0 accum
=64
Pixel Format: 32 bit (8888) accelerated:double buffered depth=24 stencil=0 accum
=64
Pixel Format: 32 bit (8880) accelerated:double buffered depth=24 stencil=8 accum
=64
Pixel Format: 32 bit (8888) accelerated:double buffered depth=24 stencil=8 accum
=64
Pixel Format: 32 bit (8880) accelerated:double buffered depth=0 stencil=0 accum=
64
Pixel Format: 32 bit (8888) accelerated:double buffered depth=0 stencil=0 accum=
64
Pixel Format: 32 bit (8880) accelerated:double buffered depth=0 stencil=8 accum=
64
Pixel Format: 32 bit (8888) accelerated:double buffered depth=0 stencil=8 accum=
64
wine: Unhandled page fault on read access to 0x6765746e at address 0x6765746e (t
hread 0009), starting debugger...
Can't attach process 0008: error 5

Driver 359.06
Video Card: 980ti
BoxedWine 19R1.1
Quake 2 Demo

I get some SetThreadDescription kernel32.dll error. Win7 x64

20R1 Beta 2 https://sourceforge.net/projects/boxedwine/fi … a2.zip/download

DosFreak

I added a DX9 build in 20R1 Beta 2 if you want to give that a try. It uses DX9 for the UI. If you launch an OpenGL game or DirectX/D3D game it will still use OpenGL for it.

Quake 2 and Unreal both have a problems when glString returns more than a certain amount of data for GL_EXTENSIONS. They have a hard coded buffer to receive the extension string list.

To fix this, you can limit what extensions are returned from OpenGL by adding this to your command line arguments for Boxedwine

-glext "GL_EXT_texture3D"

leileilol

I fixed the SetThreadDescription issue in Beta 2. I didn't realize this was a Windows 10 only API call. The UI seems to work fine in a Windows 7 VM, but 75% of the time a simple app will crash when I try to run it. I will look into this more to see if this is my VM, a Windows 7 specific problem or if there is just a general timing issue.

Okay,

Didn't see the 20R1A1 32bit previously so tested with that. The GUI glitch was with the "Create Shortcut" window, nothing was viewable in that but with 20R1A1 this is fixed.

The machine I am testing on is capable of 64bit but I run multiple operating systems on it for compatibility testing, currently running Windows 2000 with the blackwingcat patch so I don't expect you to support that of course. 😉

For Quake 2 I can confirm that using "-glext "GL_EXT_texture3D" does allow Quake 2 to work in OGL mode.

What's odd is that when testing before with Q2 in software mode boxedwine will crash on loading the game, mabye it still queries OGL? Going to test again with this build with Q2 in software.

/EDIT Quake 2 now works in software mode with that switch added as well but not without it.

Obviously I have no intention of running Q2 in boxedwine, just testing the software. I use KMQuake 2 or Yamagi on 2000 when I want to play Q2.

Going through my compatibility list for hard to run games.

This one is Al Unser Jr Arcade Racing demo.

On windows this game requires 256 colors and it runs way too fast. Currently use pcem running Windows 98 to run this game.

On Boxedwine there seems to be a graphics issue. Unknown how it behaves with Wine using Linux.

DosFreak

I tested on Windows 10 using the x64 build.

1) It complained about 256 color mode, so I set Boxedwine to use 256 color mode
2) I only saw a black screen when it started, so I hit the restore window button in the game (not the boxedwine window)
3) It looked better, but was missing some stuff at the bottom, I hit maximum and restore again
4) It finally looked good and I was able to play. I couldn't judge the speed because I never played before, but it seemed fine

I tried to test on Linux but the 256 color thing stopped me. I know there are ways to work around that, but I haven't tried that yet.

It is possible my code didn't respond to a screen size change, like maximize and restore, correctly. My own custom winex11.drv is a bit primitive in that area.

Starts on Windows 7 now. Unfortunately it seems to require network to start anything at all and that's not agreeing with my firewall rules as it's wanting more than just localhost...

leileilol wrote on 2020-05-25, 01:05:

Starts on Windows 7 now. Unfortunately it seems to require network to start anything at all and that's not agreeing with my firewall rules as it's wanting more than just localhost...

Yeah, that beta I posted requires internet in order to download the Wine files. For the next release I will also create an offline installer that will include the most recent version of Wine.