OpenGL progress

So this is where we are today. Our GL renderer is a lot more capable, even though it's still unfinished.

Here's a little TODO list:

* shadows
* handling DISPCNT
* texture blending modes (decal/toon/highlight)
* edgemarking, fog
* clear bitmap
* higher res rendering
* OpenGL init under Linux/etc
* switch between GL and software renderer

I first want to clean things up so that I can release a beta version, though. The idea would be to see how the renderer fares 'in the real world', so the actual proper 0.8 release doesn't end up being a major disappointment.

The current renderer requires OpenGL 4.3. Which might exclude old hardware and, well, Macs.

At the end of the development process, the requirements will be adjusted. The current renderer will likelly have its requirements lowered as far as it can go without losing accuracy.

Depending on demand, there might be alternate GL renderers, supporting older GL versions but sacrificing some accuracy (they will render certain cases wrong and that will not be fixed).

See ya in a while!
MelonMan says:
May 2nd 2019
Could you include an opengl32.dll Mesa for people with low-spec graphics cards
SeppNel says:
May 3rd 2019
Nice work.
Arisotura says:
May 3rd 2019
MelonMan: we already have the software renderer tho
Beansta says:
May 3rd 2019
Excellent work, MelonDS is my goto emulator outside of DraStic. Just a question - what sort of performance increases would we be expecting over the current software renderer?
A dragon says:
May 4th 2019
Any plans for a Vulkan render option in the future?
Marv says:
May 5th 2019
I'm interested in why you would need OpenGL 4.3 or it's advanced feature set ? By some chance do you need compute shaders, SSBOs or some other feature ?

Honestly, having potentially 2 different GL backends and inevitably working around GL shader compiler bugs on different mobile grahpics hardware vendors doesn't seem like it's worth the upkeep in comparison to just having a single Vulkan backend which is still evolving as a new standard and is bound to also get new features as well to improve accuracy of emulation. 2 different rendering backends, asymmetric feature set access, and lower quality drivers all sound very harsh ...
Branchus says:
May 5th 2019
OpenGL is good, vulkan is even better.

but does Macs support vulkan? I think apple use mental for everything.
Zinx says:
May 5th 2019
On MacOS OpenGL is deprecated and not supported much.
Thelolest says:
May 5th 2019
As they said on reddit, 4.3 is already several years old, so if a computer doesn't support it, it won't probably be fast enough to run melon ds at the right speed.
Also, one graphic backend is more than enough code to maintain for one person, don't make your life harder trying to support hack and workarounds...
SpiffyJUNIOR says:
May 6th 2019
Yeah, for macs the only option would be to code a Vulkan renderer and implement MoltenVK.
Guest says:
May 8th 2019
Thelolest, currently there is an exception, some preGCN AMD GPUs from the HD 5xxx series on Linux.
They are currently stuck on OpenGL 3.3, due to AMD's (back then) horrible support, HD 58xx and up are on 4.2, with 4.5 coming in sometime later (theoretically, they could be compliant with 4.4, and mostly compliant with 4.5, though the features are disabled as of yet).
guest says:
May 8th 2019
So, how do I build this to test it out? When I tried recently I installed codeblocks and mingw-w64. It built, but crashes before displaying anything when calling some direct2d function, getdpi. What setup do you use for compiling?
Post a comment