My main contribution to upstream is going to be the backporting of the GL3/GL4 renderers you see right now in flyinghead's fork and the libretro fork to reicast upstream.
I have currently decided on the following course of action:
For the GL 4.3 renderer, I will probably for now need to introduce a HAVE_OIT ifdef. It will require changes to the TA PVR code - it handles two mode volumes unlike the non-OIT renderer so we will need ifdefs for that.
The only thing I am a bit less happy about is that there is going to be a bit of code duplication, the gltex code for instance will probably be very similar for all three renderers, but I also don't think a lot of refactoring right now is a good idea when these renderers are still in flux. I will make each renderer a separate renderer, like rend_GLES2, rend_GL3, rend_GL4.
Since libretro GL requires no context creation, this is one of the parts I will probably need to wing a bit. I will probably just include the windowing/context creation parts for the platforms that @flyinghead already covers, which is likely going to be GLX, and I might be able to wing WGL as well for Windows.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Awesome news! What about a gles3 update?
https://github.com/reicast/reicast-emulator/issues/1162
@flyinghead @twinaphex do you want to start by bringing in these branches in this repo? We can prefix them like libretro/<whatever>
@twinaphex and @skmp one thing I noticed using Reicast on android 5.1.1 on the MX3-G with Mali 450 GLES2, is that it seems like it has a certain delay in loading HD tests, it would not be interesting a version where it could change the quality of the textures, for: low, medium and high, I think so because of the PPSSPP in this same box android, when I put more than 1x (number of ps proporcinal the quality) in some games is with the graph with bugs.
Not sure what you are talking about here, are you talking about texture upscaling?
in the same upscaling texture, leave the image quality, type what occurs in the retroarch core pararell64, 320x240, 640x480 .... so it can in weaker devices, load the faster graphics.
Just a quick update on this, it looks like @flyinghead got the changes in the repo as fh/mymaster.
Not sure if this includes all of the libretro changes?
@twinaphex Will go over this ticket again when I'm home and give you feedback. Got blocked with some IRL stuff this week.
@spielvan yes, having a "native resolution" mode would help a lot. We had this in nullDC too. edit see #638
@twinaphex the overall plan sounds good. I also agree it would be nice to re-use gltex and such, but betting all of the code in is higher priority.
GL context init is a major issue in the current code structure. Having a few hacky extra #ifdefs there would be fine by me. That code should be refactored, but it's so convoluted atm a bit more complication won't make much of a difference...
@flyinghead sounds good to you?
Sounds good to me
As of PRs #1448 and #1449, the GL renderer now detects the GL version at runtime and uses log2 depth if supported (GL 3+, GLES 3+).
Also the fog is implemented using a lookup texture for accurate results.
Most of flyinghead's work has been merged to master via #1523!
Most helpful comment
I can certainly help!
I just pushed my two branches here: non-OIT and OIT and intend to keep them updated.
They are closer to master than the libretro cores so this might help.