VOGONS


Boxedwine (Wine on multiple platforms)

Topic actions

Reply 80 of 88, by dreamer_

User metadata
Rank Member
Rank
Member
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)

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 81 of 88, by danoon

User metadata
Rank Member
Rank
Member

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.

Attachments

  • motorhead.jpg
    Filename
    motorhead.jpg
    File size
    155.97 KiB
    Views
    138 views
    File license
    Public domain

http://www.boxedwine.org/

Reply 82 of 88, by CoolGamer

User metadata
Rank Member
Rank
Member
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.

Reply 83 of 88, by danoon

User metadata
Rank Member
Rank
Member
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.

http://www.boxedwine.org/

Reply 84 of 88, by CoolGamer

User metadata
Rank Member
Rank
Member

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

Reply 85 of 88, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

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.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 88 of 88, by danoon

User metadata
Rank Member
Rank
Member

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.

http://www.boxedwine.org/