search

JesseTG / melonds-ds

A remake of the libretro melonDS core that prioritizes standalone parity, reliability, and usability.
GNU General Public License v3.0
106 stars 14 forks source link

OpenGL ES is not supported #23

Open JesseTG opened 12 months ago

JesseTG commented 12 months ago

Upstream melonDS does not support OpenGL ES, which means that neither does melonDS DS. The software renderer is faster, more accurate, and more compatible than the OpenGL renderer; the only disadvantage is the lack of resolution upscaling. Given that, I do not consider OpenGL ES support a priority -- however, I will accept PRs that contribute it (although most of the work will have to be done upstream).

JesseTG commented 12 months ago

I'm told that melonDS DS runs very well on iOS, even without the OpenGL renderer or the JIT. The OpenGL renderer isn't really faster than the software renderer, but it does allow upscaling 3D graphics; that appears to be the only feature that iOS users are missing out on.

Still, I'm keeping this issue open. Any fixes to OpenGL ES support should be contributed upstream.

bidinou commented 4 months ago

Hi Jesse ! I was about to open a bug report but... Maybe it explains why RetroArch pixel shaders do not seem to be applied when using libretro-melonds-ds on my Android device ?

Cheers ! And thanks for your work :)

JesseTG commented 4 months ago

Hi Jesse ! I was about to open a bug report but... Maybe it explains why RetroArch pixel shaders do not seem to be applied when using libretro-melonds-ds on my Android device ?

No idea. Pixel shaders should still work for the software renderer, the core is totally oblivious to whatever post-processing the frontend does.

Cheers ! And thanks for your work :)

Glad you're having fun!

bidinou commented 4 months ago

Hmm, so maybe this is because the picture is upscaled by the core and thus the shaders, which were supposed to improve SD content, cannot do their job properly ? (there is no option to set the internal resolution though, right ?)

JesseTG commented 4 months ago

Hmm, so maybe this is because the picture is upscaled by the core and thus the shaders, which were supposed to improve SD content, cannot do their job properly ?

I guess so. When using shaders with upscaled graphics in melonDS DS, are the results broken or just ugly?

(there is no option to set the internal resolution though, right ?)

For melonDS DS there is, but only with the OpenGL renderer (which isn't available on all platforms).

bidinou commented 4 months ago

Hi !

OK. So, the problem only happens in Hybrid mode. In the other modes, shaders are applied properly. Oopsie, I feel I kinda wasted your time !!

The result is the same as the one obtained with libretro-DeSmuME when the "Hybrid Layout : scale so small screen is 1:1 px" is enabled.

Which is actually 100% understandable. In Hybrid mode, in DeSmuMe, you have the choice between : a low-res picture (compatible with crt shaders) with a secondary small screen which will get downscaled by the shader OR an upscaled picture (incompatible with crt shaders) with a secondary small screen which will retain its 1:1 resolution.

So I guess, what is actually missing in the same option in the libretro-melonds-ds core ? (which obviously has a con : the small screen looks downscaled with shaders...)

Anyway, the best compromise is to use the left/right or right/left layout instead of the hybrid mode ! :)

BTW, is it possible for the core to detect when the phone screen is put in landscape or portrait ? (to alternate between left/right and top/bottom for instance ?)

Cheers & sorry for the bug report which is not a bug ! :)

JesseTG commented 4 months ago

Hi !

OK. So, the problem only happens in Hybrid mode. In the other modes, shaders are applied properly. Oopsie, I feel I kinda wasted your time !!

The result is the same as the one obtained with libretro-DeSmuME when the "Hybrid Layout : scale so small screen is 1:1 px" is enabled.

Which is actually 100% understandable. In Hybrid mode, in DeSmuMe, you have the choice between : a low-res picture (compatible with crt shaders) with a secondary small screen which will get downscaled by the shader OR an upscaled picture (incompatible with crt shaders) with a secondary small screen which will retain its 1:1 resolution.

So I guess, what is actually missing in the same option in the libretro-melonds-ds core ? (which obviously has a con : the small screen looks downscaled with shaders...)

Anyway, the best compromise is to use the left/right or right/left layout instead of the hybrid mode ! :)

Could you please open a bug report with this information, along with some screenshots showcasing the issue?

BTW, is it possible for the core to detect when the phone screen is put in landscape or portrait ? (to alternate between left/right and top/bottom for instance ?)

Not at this time. This would need the frontend to support telling the core what the screen resolution is. I can see why you'd like this, though. Could you open a feature request for this in case the right opportunity arises later?

Cheers & sorry for the bug report which is not a bug ! :)

JesseTG commented 3 months ago

Ah! It seems that @rafaelvcaetano has ported the renderer to OpenGL ES in his Android port! https://github.com/rafaelvcaetano/melonDS-android-lib/commit/f1080b5160142f4b2a3720c02cc14cd808cbc225#diff-41c8f9a6f4a5046e2074959e151f55fab289538b6e5f673f6b4c2fe89d36cbf2

JesseTG commented 3 months ago

It also turns out that you can swap out #include paths at compile-time using #define directives. Who knew? https://en.cppreference.com/w/cpp/preprocessor/include I might even be able to replace this PR upstream with something better.