First ever revolutionary N64 Vulkan emulator coming soon – only for libretro (paraLLEl)

140228_38849_ultra

For years, Nintendo 64 emulation has been pretty bad and lagging significantly behind Nintendo Gamecube/Wii emulation. At least 90 to 95% of the remaining problems are at the RDP level, the N64’s video subcomponent chip. By moving away from High-Level Emulation of the RDP, we could solve most of the remaining problems. The problem has been that for a long time, it seemed impossible to do this at playable speeds. Software rendering is too slow for a GPU from this timeframe, and older versions of OpenGL have too many crippling limitations in order to allow for a 1:1 reprogramming and port of Angrylion to GL.

At last, this dire situation will change in the upcoming days and we can finally release to the public something that will revolutionize N64 emulation forever so that we can move away from all of the hacky HLE video plugins that have been released in recent years.

The world’s first-ever low-level N64 video plugin implemented using the Vulkan API!

And not just any video plugin either. This is a reimplementation/port of Angrylion to Vulkan. This will be the first time most will be able to get anywhere close to playable speeds with an accuracy-based N64 video renderer.

This hardware renderer is unique for the following reasons:

  • This is the first N64 emulator project ever so far to receive Vulkan support.
  • This is the first time ever that an emulator takes advantage of asynchronous compute (exclusive only to DirectD12/Vulkan) for hardware rasterization of an emulated GPU.
  • This is the first time ever that the Angrylion renderer has been ported to a graphics API. It is the first time an RDP LLE video renderer for N64 has been capable of running at fullspeed. It marks a shift away from decades of inaccurate high-level emulation of the N64’s RDP which made for buggy N64 emulation in general.

Continue reading “First ever revolutionary N64 Vulkan emulator coming soon – only for libretro (paraLLEl)”

Components of a Source Engine Libretro Frontend

When combined with a 3D game engine, such as the Source engine, the libretro framework is able to run on any surface in the game.

Replacing the simple game texture shown on an in-game TV screen with a fully functional libretro instance can do anything ranging from playing a full-length video with the ffmpeg core, to running interactive homebrew software, all on the in-game screen.

Adding libretro support to a 3D frontend allows a wide range of media to be loaded using libretro’s ever growing collection of cores. Only a few key components need to be in place to get started. This article outlines what was required to add libretro support to the Source engine for the 3D-frontend Anarchy Arcade (www.anarchyarcade.com).  The process for other popular game engines is also very similar.

The Source engine has three notable road bumps when implementing libretro.

First is that the Source engine is DirectX, while libretro requires OpenGL for 3D acceleration.  Without OpenGL, only the cores that support software mode will be able to function.  Generally, this means only 2D cores will work properly, but technically it will depend on what the core supports.

The second road bump is audio.  Anarchy Arcade uses PortAudio (www.portaudio.com) to play the audio streams that libretro provides.  However, the Source engine itself may be capable of playing such audio streams more optimally.  What ever the sound solution, it is still simple enough to get the audio streams from libretro and send them where ever they need to go.

The third road bump is frame scaling.  The resolution of the frame that libretro generates will not match the resolution of your texture.  The frame data must be re-scaled in real time before it can be written to the texture.

After libretro is initialized, a core module must be loaded and its interface built so that it can communicate with your frontend.  The libretro core will be asking your frontend for different variables and options that your frontend must provide answers to.  The core will also be delivering the video buffer and the audio streams to your frontend.

All that your frontend needs to do is display what libretro gives it.  Your frontend can also forward keyboard & gamepad input to the libretro core so the user can interact with it.  This communication all takes place during the main loop.

Source Engine Main Loop

After libretro is initialized, its retro_run method needs be able to be called as often as possible, without interfering with normal engine operations.  A good place to plug your code into the Source engine for this is in CAutoGameSystemPerFrame::Update.

With a core loaded and retro_run being called from your main loop, libretro is fully functioning.  Now the frontend just needs to display what it is given, and forward user input to the libretro core.

Source Engine Texture Access

Cores that have software rendering (such as most 2D cores) will basically require a memcopy of the frame that libretro gives your frontend.  The Source engine has a special kind of texture called a procedural texture that allows you to write directly to its pixels, or do memcopies onto it.  It works by plugging into the logic of the ITextureRegenerator::RegenerateTextureBits method to do a memcopy of the libretro frame buffer.  This effectively draws what ever libretro is rendering onto the in-game texture.

Source Engine Input Capture

Finally, your frontend needs to send button state info to the libretro core so that the user can interact with it.  In the Source engine, button states can be determined whenever needed by using the vgui::input()->IsKeyDown method.

Libretro Frontend on Source Engine w/ VR Mode

After all of these components are implemented into your frontend, you can use your interactive texture on how ever many surfaces you want.  There is no additional performance impact for using it on more than 1 surface.  You can also optimize your implementation so that memcopies only occur when they need to by assigning a CEntityMaterialProxy to the material that references your procedural texture.  With these 3 simple components, you are able to run many of the libretro cores available at www.libretro.com, or your own homebrew software on the in-game screens of your Source engine 3D frontend.

Mednafen/Beetle PSX HW – Alpha test version

Parasite Eve with the experimental GL renderer. Note the screen residue glitches at the bottom.
Parasite Eve with the experimental GL renderer. Note the screen residue glitches at the bottom.

Here is the first release of Mednafen/Beetle PSX HW. You can download this core right now for Windows, Linux, and OSX.

NOTE: THIS IS AN ALPHA VERSION AND IT IS NOT REPRESENTATIVE OF THE UPCOMING BETA VERSION. PERFORMANCE RIGHT NOW IS A LOT LOWER THAN WHAT IT WILL BE FOR THE BETA VERSION. EXPECT BUGS TOO.

See a complete screenshot gallery here.

Where to get it?

Rage Racer using experimental GL renderer
Rage Racer using experimental GL renderer
Final Fantasy VII using experimental GL renderer
Final Fantasy VII using experimental GL renderer

Go to RetroArch, go to Online Updater, go to ‘Update Cores’, and download ‘PlayStation (Mednafen PSX HW)’. You might need to update your core info files first before this will show up properly. To do this, go to ‘Online Updater’, and select Update Core Info Files’.

Continue reading “Mednafen/Beetle PSX HW – Alpha test version”

RetroArch 1.3.4 released

Version 1.3.4 has just been released.

Builds can be found here.

Old MacOS X builds (PowerPC and 32bit Intel) will be retroactively added soon, since these builds can’t be automated.

Graphics improvements

 

This is the simplified ribbon animation shown here. The more advanced one should be fullspeed on any GPU from 2008 and later.

Continue reading “RetroArch 1.3.4 released”

RetroArch 1.3.2 released

From now on, there will be more frequent rolling updates.

We are close to automating releases on the buildbot so that we can have weekly releases for the most prominent platforms.

Version 1.3.2 is available here:

http://buildbot.libretro.com/stable/1.3.2/

I will add OSX 32bit and PowerPC releases to this later on. PS3 will be back at some later undisclosed time, same with original Xbox and 360.

Regarding the releases from this point on: give us as much feedback as possible, and with each week we can try to address some of this feedback and make RetroArch better. A ‘Release early, release often’ approach instead of the drought of stable releases that was the norm before will hopefully result in more sustained progress.