Experimental OpenGL rendering in libretro core

Libretro Cores
#1

I’ve implemented an experimental interface for libretro cores in gl-render branch on Github. Note the experimental part. It is not part of the public API (yet).

They allow a core to render their output to an FBO of desired size instead of a CPU backed framebuffer. The FBO approach allows full user-defined shaders and all that jazz :slight_smile:

Since libretro core and RetroArch share the GL context, the core will have to be very careful to avoid leaving too much changed global state in between calls to retro_video_refresh_t. Things like buffer objects should be set to 0, vertex attribs/client state should be reset properly. RetroArch will try to avoid messing up state too much as well.

Also, you have to make sure the projection matrix is flipped vertically. RetroArch expects top-left in the frame to map to [0, 0] coordinate like regular libretro cores.

I’ve created a small example which uses it, a spinning square. Tested it on Linux w/ MESA. I recommend that implementations focus on using modern GL which is compatible with GLES2+ and GL2.x+. Then an implementation could be quite portable. https://github.com/Themaister/RetroArch/tree/gl-render/libretro-test-gl

#2

Would extensive modification still be required for a core to allow a shader to, for example, apply an effect only on 3D? I’m interested in some form of anti-aliasing or similar to get nicer edges and overall smoother 3D models in PS1 games (note, I’m not looking to increase the rendering resolution), but since shaders so far are applied to the entire picture, it’s hard to get a nice result with the 3D without going overboard on the 2D and making text unreadable.

#3

A core could do whatever processing it wants with its own shaders this way, but you can’t make shaders which only apply to 3D (and not 2D parts) generic in any way unless the emulator is designed fully with this in mind.

#4

1040×806

http://mudlord.info/temp/gltest.zip (x86)

Use 1.0 windows scale.

#5

awww :stuck_out_tongue: Nice. You had any weird issues popping up making that?

#6

Apart from depth problems which are solved by rendering to a FBO I had control over, and the usual flipping issues to do with FBOs, yes.

#7

Other than Mupen64Plus, are there any plans for other cores to take advantage of this new development? I know some (or maybe many) are not very fond of rendering the PS1 at higher resolutions because of glitches with polygon jitter, texture warping, etc., but I personally do not mind those things, and so I would actually love to see a port of, say, PCSX-R to the libretro API. Now, correct me if I am wrong, but using OpenGL rendering, would such a core not be less resource intensive than Mednafen-PSX? If so, it could be a lucrative alternative for lower end systems, not to mention it would work for people who do like rendering the PS1 at higher resolution.

#8

Note that libretro isn’t just about emulators, but about retro-style gaming in general. Not anything wrong with games targeting libretro/RetroArch as their platform like we’ve done with Cave Story, prboom, quake, etc.

#9

At the moment the API is still in alpha/beta stages and it bound to change. Once we get something more stable you could ask the PCSX-R devs if they’re interested in a port. We’ll be happy to help if they’re interested, but just doing a port ourselves is not high on our list since we already have two PS1 emulators.

#10

Assuming this was directed at my comment, I don’t really see how rendering at a higher resolution is really any different from using shaders as far as deviating from retro-style gaming. As far as I’m concerned, they’re both ways to display and enhance old games, though of course what looks enhanced to some looks like crap to others. But having a wealth of options to enjoy retro games the way you personally like on one consolidated “platform” is where the beauty of RetroArch comes from, in my opinion.

So it is possible, then. It’s just a matter of seeing if they are interested. Keep in mind, though, PC users do not currently have easy access to the PCSX-ReARMed core, and as usual, correct me if I’m wrong, but given that it’s optimized for handheld devices, would it really be much of a low-spec option over Mednafen? I understand porting PCSX-R being fairly low priority, though.

#11

lovelord, nice work. :stuck_out_tongue:

GPDP: I think a lot of people associate “PCSX-R” with PCSX-Reloaded, at least I did. I don’t know whether PCSX-Reloaded requires less power than mednafen PSX, they run the same on my PC, but it probably does since it’s less accurate. Anyway, the PCSX-ReARMed core already works on x86, so if any PCSX-R developer decides to port it, they could probably use that as a base and just add some PCSX-R bits and perhaps add another GPU plugin.

#12

Same here, but I’m on an i7, so that’s unsurprising to say the least. Only turning up internal resolution on the gpuBladeSoft plugin brings my computer to its knees, and why would you do that anyway? :stuck_out_tongue:

But yeah, I’m thinking the regular OpenGL plugin would be an alright fit, although it does have some compatibility problems that require special game fixes and such. Not sure how that would even be handled.

#13

I really like gpuBladeSoft. Accuracy and kind-of-crazy enhancements at the same time. The author is taking steps to get perspective correction working, and has even said that he wants to implement a Z-buffer. :open_mouth: The problem is of course that it’s very demanding as you’ve noticed, and it’s also not open-source.

I think using that plugin would be going a bit too far. The graphical issues are just too big IMO. I always wondered why nobody has picked up GSDX. It seems pretty fast (although it probably requires more power than Pete’s OpenGL), is pretty alright concerning graphical glitches, and it even supports raising the rendering resolution, which should make it a good middle-ground plugin. I don’t know how hard it would be to adapt it to libretro’s OpenGL rendering though.

#14

I wrote some docs on how to implement GL cores here: https://github.com/libretro/libretro.github.com/wiki/Documentation-devs

#15

Hi, Sorry for asking about this post, but i have some problem to display something in the FBO. I will succeed to change the background color with glClear function. but i don’t have succeed to display something (Texture, draw a simple triangle) in the FBO, someone have a copy of the code post in this thread ? the github project was delete, i will look into this code to learn and find why i not display an image with the libretro API. thank’s Alexis

#16

the libretro-test-gl core (and the other test cores) is in RetroArch’s source: