RetroArch has an Emscripten port but it's in a state of disarray for a few months. It should be getting patched up again though.
Anyway, a more immediate priority once the renderer is close to being finished is a Vulkan port. There is also similar work being done right now on the libretro core version of Mupen64plus.
We'll see. It uses OpenGL 3.3, which is roughly equivalent to WebGL 2, which is not really available yet. You can enable WebGL 2 in Firefox or Chrome but it is disabled by default in both browsers.
There is an upscaled PSX emulator that works on ARM - PCSX ReARMed... worth a look for running great looking full speed PSX games on low powered ARM devices.
Sounds like existing renderers for PSX emulators are either closed-source, or based on legacy graphics APIs and therefore hacky.
From about halfway down the page:
> This is probably the first OpenGL renderer for PSX that is not based on outdated fixed-function OpenGL code and which is, actually, well, open-source. Because we can assume shaders will be there, we can get reasonably close to emulating texture windows accurately (with Pete’s OGL1 GPU plugin, there were codepaths for doing it with paletted textures – the hacky approach – and the pixel shader approach). Therefore, the renderer is still kept pretty simple and easy to understand.
There are perfectly fine and compatible CPU-based renderers for Playstation 1 in Mednafen or pSX. People don't want compatibility, though, they want their graphics to be better than the original.
So emulator devs make these GPU-based HLE renderers that are always going to be hacky no matter what.
It did not move from Rust to C++. Simias worked together with us to port it back to a C++-based emulator, and we also managed to improve several things in the process.
We are still keeping the two codebases moderately the same so that it's easy to backport stuff back and forth inbetween the Rust/C++ versions.
Mednafen/Beetle PSX right now is a more fleshed out PlayStation emulator that has seen more years in development and therefore is more mature, while Rustation is still a relatively new emulator with lots of parts (CDROM/SPU/etc) still not implemented. Backporting the renderer as a pseudo plugin to a more mature emulator has the benefit that the GPU part can be nearly finalized so that most of the hard work should be done by the time Rustation gets to the stage where the other elements of the emulation are mostly complete.
In short, it helps out both projects and we work closely together with the author. The port to C++ was mostly a team effort between him, us and several other guys.
What you just described has already been there for months, before the C++ port happened, however, we still needed a C++ port so that we can draw in some experienced devs who were mainly at home in C/C++ land to do the Vulkan part, and also because it is easier to compile for both our buildbot and other users.
Anyway, you can use the external Rust renderer through this C-based API, or the C++ integrated renderer. The main point is to keep both codebases more or less in sync with each other.
Libretro as a project generally favors C/C++ codebases. There is one or two Rust-based cores, though, which happen to be done by the same author, simias (same guy the renderer here comes from).
>We successfully ported simias' Rust renderer from Rustation over to Mednafen/Beetle PSX as C++ code.
May as ask - why? Why didn't you just add a tiny FFI layer to the renderer, set it up to compile as a static library and link that into Mednafen? Surely that would have been less work?
Reply (from dev or OP?):
This has existed for several months already, check the source. It is still possible to just make the Rust renderer statically link against Mednafen PSX, however it's hidden away in some branch of a fork simias made of rustation/frankenbeetle somewhere, so it wasn't really accessible.
Anyway I don't know what you're griping about, and the same goes for the guy below (SCO_1). Simias is in full support of this, and we made this specifically in a way so that we can still easily send code back and forth. Also, there being a C++ port means we can get certain devs to participate who wouldn't want to touch anything Rust-based.
That is not an indictment of Rust or anything, from my limited interactions so far I actually like it. It's just that certain very capable engineers might only know C++/C to a large degree and have no interest to be learning a special language specifically for PSX development. And this one guy in specific could make a very large difference. Nobody, not simias, not anybody, is opposed to that just because of it not being done in Rust. It can still be backported and it won't detract from Rustation, if anything, it helps build it up. This was also explained already in an earlier post.
Later reply from or OP:
1 - Users were finding it unclear and hard to compile the core with the statically linked Rust library.
2 - Some coders are mainly well versed in ASM/C/C++ but they still wanted to contribute to the GL renderer efforts, and we need to draw in as many capable devs as possible to improve the state of this GL renderer.
In any case, it can still use the external Rust static lib.
Then from a different thread:
I believe you might not understand what this post is about - the idea is to take the renderer from simias' rustation and incorporate it into mednafen, which is a C++ project already. Mednafen uses SW rendering and this brings in HW rendering to mednafen (beetle).
#### Summary
The original Rust project has had its code incorporated into a C++ project, which then converted it to C++ because all the contributors knew asm/C/C++ and not Rust. AFAICT. YMMV.
Don't know why the downvotes, seems like a legit question to me. The title says "open source hardware" and it appears to be just a rendering update to some PSX emulator software.
I think it's '[open-source] [hardware rendering]', not '[open-source hardware] [rendering]' - the key tidbit being the distinction between "software rendering" and "hardware rendering" - the former is shorthand for rendering purely on the CPU, while the latter uses the graphics card for faster rendering speed.
