Dolphin, the GameCube and Wii emulator - Forums

Hi all, here follows now a suggestion for improvement.

Maybe it would make sense to add two additional download links at the first page in the download section regarding the "iconic" build 4.0-154 and the classic 4.0-9507.

While dolphin 4.0-154 is the last version with D3D9 support, build 4.0-9507 was the final one with OpenGL 2.0 (which is true for Windows). MacOS and Linux had 4.0-9508 as the last OGL2 release. In some regard those are all milestone releases and they therefore deserve a special place at the download page.

Some will wonder why this is relevant when all people uses Windows 10 or Windows 11. Well, some are still using older Windows versions and others are using Wine under Linux and those ancient builds are the perfect Wine testing candidates. Yes, there exist also native dolphin builds for MacOS and Linux but those two dolphin releases mentioned here are perfectly well suited to test the Windows application behavior in later Wine releases. Furthermore they can also be used to test the corresponding native Video API quality in Wine.

As a result it can be said that dolphins OpenGL performance is on Linux far better then under Windows simply because of the excellent driver quality of the Mesa drivers. This was tested with Mesa 23.0.0-devel (git-3507cdc 2022-11-29 jammy-oibaf-ppa). So it is not true that D3D is generally better than OpenGL. This depends primary onto the underlying drivers. For most GPU producers the OpenGL situation under Windows had not any high priority and that's the main reason why it is performing often badly, especially for AMD. But as said, this is true only for Windows, on Linux the OpenGL situation is completely different, it is almost perfect.

I can confirm that build 4.0-9507 works superb under Kubuntu 22.04 LTS and Wine devel 7.22. It is just recommended to copy over the original MS msvcp140.dll file (into the folder of dolphin.exe) and override the corresponding dll preference to "native" in winecfg. This will bring away some returning wine "stub" and "semi-stub" warnings at the CLI.

Also dolphin 4.0-154 runs nice under Wine devel 7.22. It is the perfect candidate to test the native Direct3D 9 API in Linux. Yes, there really exist such a thing, its called Gallium Nine. And also here, the performance of the native D3D9 renderer is impressive. I was even able to run Mario Kart - Double Dash!! and Super Mario Sunshine with dual source blending enabled, so I have added "ForceDualSourceBlend = True" in gfx_dx9.ini. If this really activates that function also in the D3D9 renderer (like in OpenGL) then that would mean that this feature works better in the alternative Linux D3D9 API then in the original MS D3D9 implementation. The only smaller issue is that dolphin 4.0-154 outputs at the CLI a massive amount of "0138:fixme:msvcrt:Context_Yield ()" hints which cannot be turned off. But as far I can say they don't affect the operation.

In contrast, all current Qt6 based dolphin builds seems to be fundamentally broken under Wine. The latest working ones are all Qt5 based. For example, the only issue in Dolphin 5.0-16391 is that the graphics card information in Wine is not properly adopted which results in an empty "graphics card" box. This is not a problem because the "backend" can be set to OpenGL. Wine will ignore the missing GPU information and still uses the accelerated GPU OpenGL path. Besides that, dolphin 5.0-16391 runs fine with OpenGL 3.0 although the sound behavior seems not as good as in 4.0-9507. Furthermore there are at the CLI a lot of returning "014c:fixme:bthpropscpl:BluetoothFindFirstRadio (000000000602FAF8 000000000602FB00): stub!" hints which unfortunately cannot be prevented. But also here, this doesn't seems to affect the overall operation.

Finally, the situation of dolphin in conjunction with Wine can be regarded as very good. I really didn't expect that.

Running Dolphin under Wine is very interesting. Like, quite interesting! However as you stated, we have native Linux builds, so outside of experimenting and testing Wine itself, running Dolphin under Wine is impractical and unnecessary. It is not something we want general users doing. Advanced users who want to tinker such as yourself will have no problem finding builds like this. So, IMO, it is better to not promote old builds like that on our Downloads page.

However, your idea for milestone releases would make a great wiki page. If you'd like to list all the notable milestone releases you're aware of I'd love to make a wiki page for that! Especially ones from before the blog, those are hard for even us to find!

(12-01-2022, 01:24 AM)ayImilae Wrote: [ -> ]Running Dolphin under Wine is very interesting. Like, quite interesting! However as you stated, we have native Linux builds, so outside of experimenting and testing Wine itself, running Dolphin under Wine is impractical and unnecessary. It is not something we want general users doing. Advanced users who want to tinker such as yourself will have no problem finding builds like this. So, IMO, it is better to not promote old builds like that on our Downloads page.

However, your idea for milestone releases would make a great wiki page. If you'd like to list all the notable milestone releases you're aware of I'd love to make a wiki page for that! Especially ones from before the blog, those are hard for even us to find!

Yeah, this topic is primarily about testing and it is also meant more for advanced users which know what they are doing.

But otherwise, the handling of Windows apps in Wine is for me somehow more convenient than dealing with Linux apps. Maybe I have this perspective because I was in the past predominantly a Windows user which just periodically looked into Linux. That all changed with the end of Windows 7. And then it was really really amazing to see that some Windows apps are performing clearly better under Linux/Wine than under Windows. And additionally it should be also considered that Wine is not an emulator, - at least not on x86 hardware. Wine is a compatibility layer. So when I launch the amazing dolphin build 4.0-9507 I am not running an "emulator in an emulator", I am running an emulator in a compatibility layer.

Regarding the current listing at the main page in the download section I effectively don't understand why we have a 9 year old Dolphin 4.0.2 build available when the latest release of that branch was 4.0-9507 which is 6 years and 5 months old. Isn't version 4.0-9507 much better than 4.0.2? I know, 4.0.2 is "stable" and 4.0-9507 is only a developer release. But for me, even under Wine, dolphin build 4.0-9507 seems to be absolutely stable. It is even better working than the last Qt5 milestone build 5.0-16391.

Well, I don't know what the exact requirements are that a build is regarded as stable. Eventually there exist other aspects which I don't know and which wouldn't be fulfilled by dolphin 4.0-9507.

But yeah, this can be mentioned also at an alternative location like in the wiki. That would be also great. And this don't have to be complicated. I think the following list is self-explanatory:

• final Qt5 milestone build is 5.0-16391
• final OGL2 milestone build is 4.0-9507 on Windows and 4.0-9508 on MacOS and Linux
• final D3D9 milestone build is 4.0-154
  

Here in this context those milestones are all marking the end of an "era". But maybe milestones are more commonly associated with the beginning of an era. In this regard, dolphin build 5.0-9 would also be a milestone because it represents the first release with OpenGL 3.0 support, right? So in the end that all depends on the perspective, and in my case here the final releases are the relevant ones. And yes, this could be somehow expanded. For example, it would be nice to know which dolphin build was the last one with OpenCL support. It looks that later variants uses the OpneGL / Vulkan / Direct3D compute features instead of it.

Finally I think there could be also added the last shader model 2.0 based dolphin variant, - for historical reasons. I have found Dolphin build SVN R 6803 which is starting up under Wine perfectly well but refuses to load a game because it doesn't find some OpenGL stuff. Maybe I should investigate this with a 32bit Wine prefix...

(12-01-2022, 05:14 AM)lorn10 Wrote: [ -> ]Regarding the current listing at the main page in the download section I effectively don't understand why we have a 9 year old Dolphin 4.0.2 build available when the latest release of that branch was 4.0-9507 which is 6 years and 5 months old. Isn't version 4.0-9507 much better than 4.0.2? I know, 4.0.2 is "stable" and 4.0-9507 is only a developer release. But for me, even under Wine, dolphin build 4.0-9507 seems to be absolutely stable. It is even better working than the last Qt5 milestone build 5.0-16391.

Well, I don't know what the exact requirements are that a build is regarded as stable. Eventually there exist other aspects which I don't know and which wouldn't be fulfilled by dolphin 4.0-9507.

The 4.0 era of builds isn't a separate branch from the 5.0 era of builds. 4.0-9508 is identical to the 5.0 release other than the version number, and in turn, 4.0-9508 is identical to 4.0-9507 except for an update of the translated text.

(12-01-2022, 05:14 AM)lorn10 Wrote: [ -> ]In this regard, dolphin build 5.0-9 would also be a milestone because it represents the first release with OpenGL 3.0 support, right?

I have no idea where you would be getting that information from. Dolphin has supported OpenGL versions newer than that for much longer.

(12-01-2022, 06:26 AM)JosJuice Wrote: [ -> ]The 4.0 era of builds isn't a separate branch from the 5.0 era of builds. 4.0-9508 is identical to the 5.0 release other than the version number, and in turn, 4.0-9508 is identical to 4.0-9507 except for an update of the translated text.


I have no idea where you would be getting that information from. Dolphin has supported OpenGL versions newer than that for much longer.

Okay, so I was wrong with my assumption of the initial OpenGL 3.0 support. I probably misunderstood the following information here: Dolpin 5.0 Emulator Released, Now Requires OpenGL 3 & 64-bit

But nevertheless of that, Dolphin 4.0-9507 and 4.0-9508 are the last builds with OpenGL 2.0 (and 32bit) support. So this makes them in some regard the final OGL2 (and 32bit) milestones.

And regarding the compatibility of Linux builds between Linux point releases I must say that the situation is not as easy as on Windows. So when I launch the dolphin-master-4.0-9508_amd64.deb package it fails on Kubuntu 22.04 LTS because off some no longer available dependencies:
[attachment=20244]

But that is not really surprising, the mentioned package was made for Ubuntu 15.04 from 2015. The solution would be most likely to follow the "Linux philosophy" and build it new from the original source. Well, something is telling me that this may be not an easy task. So it is definitely much easier to download Dolphin 4.0-9507 and run it via Wine.

Maybe it would make sense to check the possibility of building distro independent AppImages? I mean in the way like the much smaller emu project from here is doing it.

(12-01-2022, 08:08 PM)lorn10 Wrote: [ -> ]But nevertheless of that, Dolphin 4.0-9507 and 4.0-9508 are the last builds with OpenGL 2.0 (and 32bit) support.

No, they're not. You'll have to go back further in time if you want support for that.

Looking into this a little bit, it doesn't appear that there was a clean cut from OpenGL2 to OpenGL3. tev_fixes_new was an fundamental rework of how we render (using native integers where integers were used on the GC and Wii rather than hacking floating point nonsense) that required OpenGL3, so anything 4.0-1192 and later should require OGL3. However that commit didn't change our OpenGL version, so we switched the requirement sometime before that. I'm not sure exactly when though.

Considering how vague the transition was, the easiest method would honestly be to try Dolphin builds on OGL2 hardware, and bisect to find the last build that works.

Ah ha! Had the brainwave to check GLSL version numbers and not OpenGL version numbers. ...probably should have thought about that before now but I've been busy.

4.0-27 dropped GLSL 1.20 (OpenGL 2.1) support, bringing the official minimum to GLSL 1.30 (OpenGL 3).
3.5-1203 Minimum version explicitly set to GLSL 1.20 (OpenGL 2.1)

Before that, it gets weird. There is no explicit minimum GL version, instead you find this:

Quote: ERROR_LOG(VIDEO, "GPU: OGL ERROR: Number of attributes %d not enough.\n"
"GPU: Does your video card support OpenGL 2.x?",

"2.x". It's vague because Dolphin (before 3.5-1203) was checking the hardware and whether or not it had sufficient vertex attributes, and presenting an error based on that, not the GL version. So to my understanding, there was no exact minimum OpenGL version at that point. Even the GLSL Rewrite (3.5-1025), effectively a ground up redo of our OpenGL backend, didn't change this, it just increased the minimum vertex attributes Dolphin was looking for from 11 to 16. It finally changed with 3.5-1203, when a check for a minimum GLSL version of 1.20 (OpenGL 2.1) was added with an error if that threshold was not meant. And a couple months after that that minimum was raised to OpenGL 3. tev_fixes_new's development was well under way at that point and the minimum OpenGL version with integer support is 3.0, so, of course that was adopted as the minimum pretty quickly. That and it got rid of a looooot of silly OpenGL 2 hacks.

So yea, if you define OpenGL 2 support as "2.1" then the final Dolphin build that supports OpenGL 2 was the version immediately before 4.0-27. But if you are specifically looking for OpenGL 2.0 support, then the answer is "it depends!" Some OpenGL 2.0 devices will work with builds prior to 3.5-1203, but others may not. EDIT: I've been told this hell is because of Intel iGPUs of the era. Expect Iron Lake iGPUs to not work despite supporting "OpenGL 2".

EDIT:

Quote:But nevertheless of that, Dolphin 4.0-9507 and 4.0-9508 are the last builds with OpenGL 2.0 (and 32bit) support.

BTW The last build we distributed with 32-bit x86 support was 4.0-1409. We did the blog post officially dropping support for it, and we dropped the 32-bit x86 JIT soon after.

Okay, I have now tested this matter with the Environment Variables in Mesa. The result is that dolphin build 4.0-26 is the effective final OGL2 milestone in regard to OpenGL 2.1.

This also means that the above mentioned information on phoronix.com is wrong. Dolphin build 4.0-27 is the first one which only runs on GLSL 1.30 aka OpenGL 3.0 (and newer) based hardware.

For all interested Linux users, to test this at a newer system just launch dolphin with MESA_GL_VERSION_OVERRIDE=2.1 MESA_GLSL_VERSION_OVERRIDE=120 like in my case:


However, the lowest possible OpenGL version which is supported by current Mesa (as of 2022) is 2.1, so it is not possible to expose OpenGL 2.0 or lower.

And yes, also dolphin build 4.0-26 runs superb under Wine devel 7.22. Absolutely no tweak needed regarding any dll file. When I get the time I will use that build on real OpenGL 2.1 hardware like my Radeon X1600 based GPU in my old old iMac 5,1 computer. That dolphin build 4.0-26 might be a perfect supplement to my testing experiments with CXBX-R on D3D9 SM 3.0 class hardware.

Yes, it does seem that is the last version. (4.0-27: ogl: drop glsl120 support)

But it isn't really wrong. It's just referring to stable versions. 4.0.2 appears to still support it from what I can tell, but I didn't test it. So 5.0 would be the first stable version to not support it.