Reicast-emulator: New GLES2/GL3/GL4 renderers

Created on 19 Jul 2018  路  12Comments  路  Source: reicast/reicast-emulator

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:

  • The existing GLES2 renderer will remain. What little can be backported from the GL3 renderer that won't cause performance issues will probably be done.
  • For desktop, there will be a GL3 renderer. This is the current default non-OIT renderer for libretro Reicast. It uses gl_FragDepth which requires GL 3.x, and it has full fogging support, clipping support, volume modifier shadows support, trilinear filtering support, mipmapping support, multipass support, flat shading support, etc. For most games it will probably render accurately enough.
  • For desktop, there will be a GL 4.3 renderer. This is the OIT (Order Independent Transparency) renderer. GPU requirements are much higher than either the GLES2 and/or GL3 renderer, but the accuracy is also much higher. It will have all the features of the GL3 renderer by default.

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.

Improvement Tracking To Review

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.

All 12 comments

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.

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!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

spielvan picture spielvan  路  7Comments

shinshura17 picture shinshura17  路  6Comments

spielvan picture spielvan  路  3Comments

Gamemulatorer picture Gamemulatorer  路  8Comments

skmp picture skmp  路  4Comments