Libretro GL – SceneWalker

The SceneWalker with the Silent Hill 3 Chapel model loaded in. This entire map mostly works correctly.

The SceneWalker with the Silent Hill 3 Chapel model loaded in. This entire map mostly works correctly.

By Squarepusher

Here is the second tech demo by maister made to showcase what is possible with libretro GL. SceneWalker is a heavily modified version of ModelViewer.

Instead of loading ‘character models’, its main purpose is to load in ‘scene models’. Once loaded in, you can then walk around these environments from a first-person perspective. It’s possible to move through environments using either the D-pad and/or the analog sticks. Pressing RetroPad B button allows you to jump – this comes in handy with some models where certain obstacles are preventing you from fully traversing the environment.

A great deal of environments already work within this SceneWalker app – the initial ‘placement’ of your starting position is currently a problem in some models since it is possible for you to be ‘dropped’ inside a void space. This happens for instance with the ‘Devil May Cry 4’ street model which makes it impossible to walk around that map.

Other maps (such as Silent Hill 3’s chapel) work fine on the other hand.

Basic collision detection and gravity has been implemented – it mostly works the part for most models.

Below you’ll find some screenshots of some models that we have loaded into this SceneWalker.

This is the map 'Amnesia Fields' from the PSP version of Tekken 5: Dark Resurrection. The skybox is missing from this model but everything seems to more or less work correctly. There are some popup issues that might or might not be overcome in the future.

This is the map ‘Amnesia Fields’ from the PSP version of Tekken 5: Dark Resurrection. The skybox is missing from this model but everything seems to more or less work correctly. There are some popup issues that might or might not be overcome in the future.

This is the Twisted Corridor map from Alice In Wonderland. There are plenty of places here where if you don't carefully jump on the platforms you can fall into the void.

This is the Twisted Corridor map from Alice In Wonderland. There are plenty of places here where if you don’t carefully jump on the platforms you can fall into the void.

A pub scene from the MMO game Vindictus rendered inside the SceneWalker.

A pub scene from the MMO game Vindictus rendered inside the SceneWalker.

This is the police station main hall scene from Resident Evil: Umbrella Chronicles. The model uses DDS textures which are currently a stub - hence why there are no textures right now when showing this model.

This is the police station main hall scene from Resident Evil: Umbrella Chronicles. The model uses DDS textures which are currently a stub – hence why there are no textures right now when showing this model.

Platforms

Scene Walker right now runs on:

  • PC (Windows/UNIX/OSX)
  • Android
  • iOS
  • Blackberry QNX (BB10/Playbook)

The maximum supported internal resolution at which you can render the models depends on the platform you’re running Scene Walker on. On the mobile platforms we have consciously decided to set the maximum supported resolution at 1024×768 – this should be the native resolution of the iPad 2/iPad Mini and it is doubtful that even on a powerful tablet you’d have much need for 1080p internal resolution anyway.

On PC 1920×1600 is the maximum internal resolution at which you can render these models.

Like all the non-GL based libretro cores, you can apply any amount of shaders that you want.

Scene Model links

I’m not exactly sure how hard-ball game developers are when it comes to these models – but anyways, there is a lot of source material you can find on the Internet.

Some places that supply them is DeviantArt (search for DeviantArt + XNALara-  that should show up a bunch).

Another site that I’ve found includes a lot of useful models is this one (http://thefree3dmodels.com/). Make sure that when downloading a model form there, that it says ‘OBJ’ or something similar. Models that are not in this format can’t be expected to run right now.

Libretro GL – Modelviewer

By Squarepusher

As a showcase for libretro GL, maister made two quite nice libretro cores that should appeal to demo coders and traditional game developers alike.

Model Viewer

I encouraged Maister to do a libretro GL port of an old project he made a year ago (Model Viewer) as a showcase for libretro GL.

The Model Viewer takes ‘Wavefront’ object models as the ‘ROM’. it then displays these models inside a bare 3D environment.

It is possible to adjust the camera and rotate the model, zoom it in/out, etc.

Right now it is still in a basic phase but you’ll find a great amount of models that you can find on sites like Deviant Art and Free 3D Models (http://thefree3dmodels.com/) should already run unedited.

NOTE: Models that depend on DDS textures (DirectDraw Surface) will appear in the Model Viewer as ‘flat shaded’ for the moment since DDS support is currently a stub.

Below I’ll showcase some models being rendered inside the Model Viewer. Search around for some of these models yourself (some key terms being ‘XNA Lara’ and/or ‘3D Studio Max’). If the model comes with an OBJ/MTL file and a couple of PNG/JPG/TGA images it should more or less work barring some exceptions. (.mesh based models are not supported right now)

The Final Fantasy XIII Vanille model mostly appears correctly in the Model viewer except for a few minor details

The Final Fantasy XIII Vanille model mostly appears correctly in the Model viewer except for a few minor details

Here you see Lightning displayed in the Modelviewer with lots of shader passes applied. Most apparent shader here is the Waterpaint mudlord shader which gives the model a painterly look.

Here you see Lightning displayed in the Modelviewer with lots of shader passes applied. Most apparent shader here is the Waterpaint mudlord shader which gives the model a painterly look.

Modelviewer showin the Final Fantasy X-II Rikku model.

Modelviewer showing the Final Fantasy X-II Rikku model.

Bryan Fury from Tekken Tag Tournament 1 - looks more or less like Bryan - some hue issues here and there.

Bryan Fury from Tekken Tag Tournament 1 – looks more or less like Bryan – some hue issues here and there.

Marshall Law model from Tekken 6

Marshall Law model from Tekken 6

Platforms

Model Viewer right now runs on:

  • PC (Windows/UNIX/OSX)
  • Android
  • iOS
  • Blackberry QNX (BB10/Playbook)

The maximum supported internal resolution at which you can render the models depends on the platform you’re running Model Viewer on. On the mobile platforms we have consciously decided to set the maximum supported resolution at 1024×768 – this should be the native resolution of the iPad 2/iPad Mini and it is doubtful that even on a powerful tablet you’d have much need for 1080p internal resolution anyway.

On PC 1920×1600 is the maximum internal resolution at which you can render these models.

Like all the non-GL based libretro cores, you can apply any amount of shaders that you want.

Model links

I’m not exactly sure how hard-ball game developers are when it comes to these models – but anyways, there is a lot of source material you can find on the Internet.

Some places that supply them is DeviantArt (search for DeviantArt + XNALara-  that should show up a bunch).

Another site that I’ve found includes a lot of useful models is this one (http://thefree3dmodels.com/). Make sure that when downloading a model form there, that it says ‘OBJ’ or something similar. Models that are not in this format can’t be expected to run right now.

Libretro GL starting from RetroArch 0.9.9

By Squarepusher

RetroArch 0.9.9 (to be released later this week) will introduce an important new feature to the libretro API that I’m sure a lot of developers will be interested in.

To date, all libretro cores have used software rendered video. Sure, the frontend (RetroArch in this case) has hardware accelerated drivers (such as an OpenGL driver or a Direct3D driver), but all that really guarantees is that blitting is going through a few API functions that might (or might not ) be hardware accelerated depending on the driver supplied by the vendor. But generally speaking, libretro cores for emulators/games that depend on hardware-accelerated 3D (such as Dolphin, PCSX2, and even N64 emus) were previously impossible on RetroArch.

This is no longer the case with libretro GL. Libretro GL is not a new API – it is merely an extension to the libretro API (that doesn’t break ABI) which allows you to write OpenGL 2.0/ES 2.0 compliant code inside your libretro core.

The way this works is that at the final end of the chain inside the libretro core, everything gets rendered to an FBO (Frame Buffer Object), and this in turn will be passed back to the frontend for final processing.

Which platforms does libretro GL support right now?
The OpenGL subset we are targeting for libretro GL is either OpenGL 2.0 (on desktop) and/or OpenGL ES 2.0 (mobile and/or desktop PC in case you’re using bleeding-edge MESA drivers). This means that any platform that has at least support for either OpenGL 2.0 or OpenGL ES 2.0 should be capable of running libretro cores that depend on GL features.

The following platforms right now are supported:

  • Android
  • iOS
  • Blackberry QNX (BB10/Playbook)
  • Pandora (not tested yet)
  • PC (Windows/UNIX/OSX)

Fixed function or programmable pipeline?

With RetroArch 0.9.9, we will finally support all of the major mobile phone/tablet operating systems (except for Windows RT). This means that your libretro port can now reach a much bigger audience than just PC and/or game consoles.

All of the mobile phones/tablets out on the market today support at least OpenGL ES 2.0 (and in most cases with added extensions support). OpenGL ES 2.0 requires that you move away from deprecated fixed function GL programming. This might be an initial learning curve but the added platform support should eventually be worth it.

Note that nothing is stopping you from writing fixed function GL code – it should theoretically run on RetroArch for PC. However, this would be a bad design decision from a portability perspective since it will automatically cut off all the mobile platforms from being able to run your libretro core.

What about Direct3D / other unsupported platforms right now?

Looking at all the devices out there, it seems pretty clear that the industry as a whole has decided to throw its collective weight behind OpenGL. We therefore (for now) have made the conscious decision not to provide a similar context for Direct3D.

The downsides of this is that it automatically cuts off Xbox 360 support since Direct3D 9 is used for the XDK. I am not sure if it would make sense to eventually provide something similar for D3D or if it would be possible to somehow make a wrapper (from GL ES 2.0/GL 2.0 to D3D9) – but for now Direct3D support is out.

For the time being – PS3 support is out as well. Sony’s implementation of OpenGL (PSGL) was never made OpenGL ES 2.0-compliant – what it is currently is a mishmash of OpenGL ES 1.x and a lot of proprietary performance-related extensions. I found some undocumented functions inside that hinted at some kind of preliminary GL ES 2.0 support, but for now I’m not really confident we can make PSGL work as a GL ES 2.0 backend.

Obviously it is unfortunate that PS3 and Xbox 360 are cut off right now – the two being the only programmable pipeline consoles out there. But OpenGL ES 1.x would just be too limiting (which is what we have on PS3), and Direct3D really is only available on Xbox consoles and Windows/RT at this point – for now it doesn’t really make much sense to us to make a totally different backend just for D3D since on a Windows PC you still have the option of using OpenGL.

How do I make a libretro GL core?

Maister wrote a simple tutorial that should walk you through the steps to get started with making your own libretro GL core.

Link: Implementing a Hardware Accelerated Libretro Core

Maister also made two test cores (ModelViewer and SceneWalker) that shows off what you can do in libretro GL. These two will be the subject of a subsequent article, so stay tuned…

RetroArch v0.9.9 Coming Soon

It’s almost time for a new release of RetroArch, and there a number of big changes coming up. First of all, RetroArch 0.9.9 will mark the release of RetroArch on iOS and Blackberry 10/Playbook Tablet OS. These ports were made possible with the help of CatalystG and meancoot, respectively – for which many thanks. The iOS port will be released on Cydia and on our forum. It is possible to run it on a non-jailbroken device – but it will require that you are able to code-sign yourself (ie. if you are a registered Apple developer with the ability to code sign).

PCSX ReARMed on iOS

For iOS, perhaps the single biggest hurdle was getting PCSX-ReARMed working, which required notaz to rewrite much of the assembly code to work with Apple’s ancient GAS assembler version (big thanks to him for that!). With that completed, this should be the first time PCSX ReARMed will appear on iOS – through RetroArch.

RGUI

Elsewhere, Themaister and Squarepusher have been toiling away at a million other features, including the promotion of RGUI to a robust and feature-filled in-game menu system for the platforms that otherwise lacked such a thing, particularly the PC platform (i.e., Windows, Mac OS X and Linux). From its humble beginnings with the Gamecube/Wii port, RGUI now provides a way to change emulation cores, swap out ROMs, configure shaders and more, all without leaving the fullscreen gaming interface:

rgui

Cave Story (NXEngine)

ToadKing and Squarepusher have also done some work on ‘uncrippling’ Cave Story (ie. NXEngine). Previously, the file I/O would make it unbearably slow on consoles. This has mostly been fixed now that everything is pre-cached into RAM at initial startup. There are still some incidental dips to 59.50fps and 59.2fps, though, which causes some sound stuttering. The cause of these dips is still unknown but we feel that–compared to before–NXEngine can be safely released on consoles now without being an utter embarrassment. “Xbox 1/360 will require some further patching up of the codebase because NX Engine did some global symbol table trickery and the MSVC linkers have the (oh so ‘smart’) tendency to ‘strip away’ unreferenced symbols as an ‘optimization feature’ with no way to stop it from doing that (even /ref:noopt doesn’t help there),” Squarepusher noted.

TyrQuake

The port of TyrQuake will also be bundled with RetroArch 0.9.9. A lot of work went into making it work on Xbox 1 and Xbox 360 – including making the C99 codebase cross-compilable as C++98 and (for Xbox 1) resorting to a hacked-up template ‘typeof’ implementation (ye, don’t ask) for MSVC 2003. “I also threw in some additional ‘hackish’ features like ‘dither filtering’ (borrowed it from some guy that implemented it earlier) – this more or less looks like the Unreal 1 software renderer’s ‘bilinear filtering’ implementation,” Squarepusher said. “There is also a third-person chase cam view and a way to ‘lerp’ the animations (ie. add key-frame interpolation in order to make the animation of enemy models look smoother and have more frames of animation than they originally did).”

“I plan to eventually rebase the TyrQuake port and push it upstream to the original authors (ie. the maintainers of TyrQuake) – I did a lot of careless code rewriting that I’ll be sure to avoid for the rebase,” he added.

Shaders

There has been a major overhaul of the way shaders are handled, which has paved the way for advanced, multipass shaders that can be easily setup by end users without needing to tinker with any code. As part of these changes, the old XML/GLSL shaders with fixed-pipeline functions have been deprecated, but will still work just fine. In the future, we ask that interested shader authors try to stick to the multiplatform Cg format when possible. The GLSL/GLES formats will still be supported for compatibility with platforms that don’t support Nvidia’s Cg Toolkit, such as Android and iOS, and Cg shaders can be converted to these legacy formats programmatically using Themaister’s cg2glsl python script.

A couple of examples of newly written shaders that utilize some of the recently added features are Themaister’s NTSC Composite shader, which should work well on any libretro core, and Harlequin’s Gameboy shader:

There is no firm release date for v0.9.9, but if you would like to try any of these features out or get involved in the development, you can grab the code from git and compile it yourself for your platform of choice. If you have any questions about these features or RetroArch/libretro in general, stop by the libretro forums or drop by #retroarch on Freenode IRC.

Discuss this post

RetroArch Android 0.9.8.1 released

In many ways this is the release that the original should have been. We have been working non-stop for the past week to iron out most of the major complaints and we believe this is a much more well-rounded package now.

New key features (0.9.8.1)

  • Higher-resolution overlays (old ones are still available for older devices)
  • Now compatible with Android 2.3+
  • Fixed Wonderswan core (Mednafen Wonderswan)
  • Numerous PCSX ReARMed improvements (PAL games should be fixed and emulator should now work on devices that didn’t work before)
  • Custom input mapping
  • Numerous pads added to autodetection list (see below).

Downloads

Google Playhttps://play.google.com/store/apps/details?id=org.retroarch

APK Link (r8)https://anonfiles.com/file/0afb3a1b35c4280139a6fcb24742ecc1

Screenshots

device-2013-01-28-193937 device-2013-01-29-021513 device-2013-01-29-021623 device-2013-01-29-054121 device-2013-01-29-054733 device-2013-01-29-081922 device-2013-01-29-082139 mgs-psx

Videos

Changelog

r8 (Jan 30, 2013) – VERSION 0.9.8.1
———————————————————–
* Is now compatible with Android version 2.3 and up.
* Back button issues with certain gamepads should now be fixed.
* Wonderswan core was broken (Mednafen Wonderswan) – is now fixed.
* ‘Detect’ button for manual input binding for touchless devices.
* Old overlays are back and put into a directory called ‘Low-resolution’ for devices with slower CPUs –
the higher-resolution ones are somewhat more demanding than the original 256×256 ones.
* Input autodetection expanded –
– DragonRise USB Gamepad

r7

Test that was released on certain forums – never pushed to Play Store.

r6 (Jan 29, 2013)
————————–
* PlayStation1 [PCSX ReARMed] core fixes (from notaz)
– Fixes 50Hz PAL games (were running with sound being too fast and other irregularities before)
– Should fix emu crashing on some devices due to memory mapping issues.
* New system-specific overlays added – on new installs only these new ones will be there and the old bad ones will no longer be there. On pre-existing installs – just use the new ones – they should be much better. If you’re still unsatisfied, nothing is stopping you from editing these files yourself with a text editor and an image editor – it’s really simple to do.
* New ‘custom binding’ when you turn off ‘Configuration Autodetect Enable’ – allows you to manually put in button mapping in case we don’t support your pad. Note – it’s probably more reliable right now to select the ‘keycode’ from the dropdown list instead of pressing the button on the pad.
– Input autodetection expanded –
– Trust Raptor
– Should fix Logitech F710/Elecom/RetroUSB NES/etc

r5 (Jan 28, 2013)
————————–
* Input autodetection expanded
– Archos gamepad
– Xperia Play
– Xbox 1 (Titanium X-JoyConverter)
– Xbox 360 (wired)
– Red Samurai Bluetooth
– Another variant of Mayflash Wii Classic
– RetroUSB SNES RetroPort
– RetroUSB NES RetroPad
– Buffalo SNES Pad
– Logicool F710 (Japanese Logitech F710)
– Elecom PS1/PS2 to USB

r4 (Jan 27, 2013)
————————–
* Input autodetection expanded
– Nyko Playpad Pro
* Fixed bug where device name would not be onscreen for long enough –
useful for reporting input name

r3 (Jan 26, 2013)
————————–
* More user-friendly core selection names
* Input autodetection expanded
– Added Mayflash Super Joy Box 3 Pro
– Added JXD S5110
– Added Logitech Dual Action
– Added Snakebyte idroid

RetroArch/libretro status – new DOSbox / MAME 0.78 ports

By Squarepusher – Over the course of this week, two new ports have appeared courtesy of meancoot.

DOSbox libretro

Released on October 21 2012.

Next to maxe-libretro, this is probably the first time a libretro port is reliant on the keyboard and mouse as an input device. It seems to have MIDI and Soundfont support as of a few days ago, it supports CD images (no real physical CD support, but then again this is pretty much an undesirable feature anyway what with storage being cheap and CD access being slow – Genesis Plus GX libretro core doesn’t bother with physical CD support either, neither does Mednafen PCE/PSX).
I might consider looking into this as a candidate for the consoles – the problem is that (like DOSbox on PS3 before, port by Robo Hobo) the speed will be very slow without a dynarec. Even Duke Nukem 2 had to fall back on severe frameskipping (1/2/3) to run tolerably on PS3 before.
Repository: https://github.com/libretro/dosbox-libretro

MAME 0.78 libretro

Released on October 31, 2012.

MAME has seen several performance regressions over the years, some of them quite severe to the point of sacrificing +100fps in some games over the course of a few revisions. Unfortunately, what this means for us these days (in 2012) with so many low-performance systems out there on the market (Android, iOS, game consoles, Raspberry, etc) is that we have to resort to very old versions of MAME in order to get decent performance on anything beyond early/mid ’90s arcade games.

A year ago, Lantus ported a MAME 0.72 version to Xbox 360 (it was basically a re-port of MAMEox, released back in 2003/2004 for the Xbox 1). This managed to run Midway/Williams games like Mortal Kombat 1/2/3 and NBA Jam at fullspeed on the 360 – not something that can be taken for granted if you’ve ever tried to port a modern-day MAME version to the current-gen consoles.

Meancoot’s recently released MAME 0.78 port right now can be expected to run on OSX, Linux and Android libretro frontends.  I have requested for the repository to be transferred over to the libretro organization – when that has happened I’ll spend some time on including Wii, PS3, 360 and Xbox 1 support to it – which shouldn’t be too hard.

For people running 64-bit OSes, expect to run into quite a lot of problems with this MAME version – even though the source shows an indication of some effort having been made to ensure 64-bit compatibility, there are still many 64-bit errors lurking around in the code. I could never get any of the ROMs on XMAME 0.72 to run on x86_64 Linux – even with this being the case, this makes for a good port for the consoles and ARM-based devices, which all have 32-bit ABIs (including PS3/360).

Repository: https://github.com/libretro/mame078-libretro

Libretro – Recap of progress last week

By Squarepusher – Besides the Desmume and TGB Dual ports that appeared out of the blue, a lot of other work has been done. Here is a brief recap.

Genesis Plus GX

Ekeeke (the author of Genesis Plus GX – still not sure about the pronunciation) added CD audio support to Genesis Plus GX. The libretro port has been pushed to the official Genesis Plus GX repository some time ago so it’s very easy for either me or ekeeke himself to update it to reflect changes made to the emulator.

Link to official repository (ekeeke): https://github.com/ekeeke/Genesis-Plus-GX

Link to libretro experimental fork:  https://github.com/libretro/Genesis-Plus-GX

Mednafen libretro

I’m currently working on making the Mednafen libretro ports more sustainable in the future. Right now we have a lot of standalone Mednafen repositories with a lot of duplicate code.

I’m aiming at bringing them all together. Right now, the mednafen-psx repository allows building three separate cores – Mednafen PSX, Mednafen PC Engine Fast, and Mednafen Wonderswan. More will be added.

The backend right now is a modified Mednafen backend with lots if ifdefs strewn around such as NEED_CD, NEED_THREADING, and so on so that – for instance – the libretro port of Mednafen Wonderswan won’t be bloated by including lots of threading and CD-ROM code that the Wonderswan emu will never ever use.

At the moment a lot of work still remains to be done – to begin with, all the Visual Studio solutions need to be updated (for Xbox 1/360/PC), and the console ports have to be all tested.

RGB565 support

Previously, a libretro port would have either the option of using a 32bit color format (XRGB8888) or a 15/16bpp color format (ORGB1555 – picked implicitly if you did not specify anything). Now that the OpenGL driver has been completely overhauled to better accomodate OpenGL ES devices, we’ve found that ORGB1555 is an unlucky fit on most of these devices and isn’t natively supported.

Hence the introduction of a new pixel format to libretro if 15/16-bit color is desired (RGB565). The PS3, Raspberry Pi, Wii and PC ports have currently been updated to properly display libretro cores using RGB565. If pixel format is not explicitly defined, then it will assume ORGB1555 and the libretro frontend (ie. RetroArch) will perform automatic color format conversion to RGB565 behind the scenes. This will undoubtedly be slower, so it’s imperative that a libretro port picks a color format.

An example from – say – Gambatte, where 32bit color is used:

<code>
enum retro_pixel_format fmt = RETRO_PIXEL_FORMAT_XRGB8888;
if (environ_cb(RETRO_ENVIRONMENT_SET_PIXEL_FORMAT, &fmt))
g_has_rgb32 = true;
</code>

You can select a different color format on a per-game basis (in this case, you would want to put this into your retro_load_game implementation) or you can choose to just have it apply for all games (in Genesis Plus GX/VBA Next/SNES9x Next/FCEUmm, a snippet similar to this has been put into retro_init for exactly this reason).

At the moment, the following emulators have been updated to support RGB565:

  • SNES9x Next
  • FCEUmm
  • Genesis Plus GX
  • iMAME4All
  • TGB Dual
  • PCSX ReARMed
  • VBA Next
  • Mednafen PC Engine Fast
  • Mednafen Wonderswan

Libretro-prboom will require a port from scratch to support RGB565 since the initial implementation required some sweeping changes that would preclude a merge into prboom mainline. FBA will be looked at later. Gambatte as it is uses ARGB 32bit color instead and so does Mednafen PSX, so these will not be looked at since color format is already ideal for these ports.