RetroArch for Windows 98 SE / Windows ME / Windows 2000 has just been released! Note that this will require cores specially made for it, and as of now there are none, so just consider this a pre-release for now!
Users should note: this is taking no time or resources away from the other stuff we are doing. Supermodel and PPSSPP cores are still being worked on, all our other work is still ongoing, so to repeat – this is not coming at the cost of other development!
Note that for these old operating systems, you might want to consider using the GDI video driver for optimal performance instead. Menu support is still premature though; XMB renders but with no textures and with dithered graphics, so for all practical purposes, the Direct3D driver is still the way to go here (with RGUI).
As always, there have been many updates to various libretro cores from a number of contributors, some of whom are regular contributors and some of whom have never contributed to libretro projects before. Here are some of the highlights, in no particular order:
r5 and Twinaphex did a deep-dive on the Beetle PSX HW OpenGL renderer to resolve a host of issues that would lead to crashes whenever users messed with internal resolution and/or toggled fullscreen. Those context changes should now be handled gracefully and without any major issues.
RobLoach updated MelonDS to match StapleButter’s upstream v0.4 release and added to the ScummVM libretro core the ability to launch *.scummvm files located inside game directories. He also merged a variety of updates from upstream EasyRPG to the libretro core and added FFMMidi for MIDI support.
bparker snatched up the $50 bounty to fix a longstanding issue with 3DO emulator 4DO Libretro, which caused saving to be broken. Prior to this fix, saves were just garbage data and the core would try to load *other* garbage data. Everything should work fine now.
Twinaphex backported a slew of per-game hacks/fixes from upstream Mupen64Plus to ParaLLEl-N64 to fix audio sync in Resident Evil 2 FMVs, fix Indiana Jones, fix missing sound in Episode 1 Pod Racer and to fix Perfect Dark when using the Angrylion or ParaLLEl renderers, among other fixes and cleanups. He also added a toggle for dithering with the Angrylion renderer, which can provide a cleaner image and also squeeze out a few more frames per second for users who were hovering around full speed with that highly accurate plugin. He also added a fix for Mario Kart 64 when using the Rice video plugin. Twinaphex also added very high internal resolution multipliers for cores that support it, including Dolphin Libretro, Beetle PSX HW, OpenLara Libretro, Craft libretro and Mupen64plus Libretro, and he updated OpenLara Libretro to have an inventory screen and a working healthbar.
oxavelar added 4-player controller support to the still-nascent Dolphin Libretro core.
Meepingsnesroms improved rotation functionality in Beetle WonderSwan Libretro and fixed the Amiga emulator core, (P-)UAE Libretro core on Android x86.
frranck tweaked the AI in MrBoom Libretro to make playing against computer opponents a better experience.
danieljg backported to our FBA2012 core a turbo speedhack for Metal Slug 2.
r-type updated MAME Libretro to stay in lockstep with upstream MAME, as well as adding a bunch of new resolutions to the “alt renderer” core option, which should allow for clean, anti-aliased vector graphics, as well as clean use of MAME’s artwork feature. r-type fixed an issue with the MAME Libretro core where some games could launch with incorrect framerates. He also added more target systems to his libretro port of Vice, along with a core option to choose different models of C64 and/or VIC20.
yoshisuga has added iOS-ARM64 build targets for many cores to make them compatible with newer Apple iDevices. He also helped track down and squash a longstanding bug that was causing a handful of cores to display only a black screen on iOS devices.
Tatsuya79 added support for Colecovision/Spectravideo/Sega SG1000 and an option to crop overscan to the blueMSX libretro core, along with fixing a variety of mapper issues in that core. He also added a core option to Beetle PCE Fast to allow users to choose which CD-ROM BIOS to use, as well as adding a bunch of new functionality for Prboom Libretro, including keyboard and mouse support and savegame slots.
Gingerbeardman made significant updates to the fMSX core.
hunterk backported some minor fixes from upstream Higan to our bsnes and bsnes-mercury cores to fix an elusive hanging issue in Magical Drop and audio issues with several games using the performance core. He also added a fix for Nestopia-UE‘s libretro interface that was preventing autoselection of the Japanese 4-player adapter when using the NstDatabase. hunterk also added core options to increase the internal resolution of the Vectrex emulator core, Vecx Libretro, which greatly reduces the ugly jaggies caused by 1x rendering.
barbudreadmon updated FBAlpha Libretro to the upstream v0.2.97.42 and fixed a segfault that could occur with some pgm games.
radius fixed savestates in FBAlpha Libretro and re-applied a fix to Mupen64plus Libretro for stuttering that some users experienced with games that run at 30 fps. He and webgeek also added AArch64 build support for various cores to coincide with the compatibility of RetroArch Android on that architexture.
sergiobenrocha2 and shakalakka provided more intuitive button layouts for the MAME2014-libretro and MAME2016-libretro cores. sergiobenrocha2 also merged in endrift’s upstream changes from mGBA v0.6.0.
kivutar made a lot of improvements to the lutro-platformer core, while RobLoach added Love support to it.
markwkidd did a variety of quality-of-life improvements for MAME2003-libretro, including adding a catver.ini file that helps with categories and fixing the Makefile to compile in the MIPS engine for x86, which should fix Killer Instinct on x86 (that is, KI is still broken on x86_64 and ARM) with this core. He also added DAT and catver.ini for MAME2000-libretro and submitted a fix from RetroPie user poi to MAME2010-libretro to fix Xevious and Bosconian.
TylerLoch (with some cleanup help from radius) added a SuperFX chip 20 MHz overclock option (i.e., instead of starting at 40 Mhz) for snes9x-libretro.
SpiralBrad backported from upstream the ability to automatically set the BIOS time in Beetle Saturn based on the host system’s clock, which is particularly useful for the real-time holiday functionality in Christmas NiGHTS.
j-selby continued improving the already impressively complete Citra Libretro port to include touchscreen emulation using the mouse and optional right analog stick among other improvements.
RetroArch 1.6.3 has just been released! Grab it here.
This latest version has also been uploaded to the Google Play Store.
General changelog
IOS: Fix GL regression – 32bit color format cores were no longer rendering
CHEEVOS: Add support for N64 cheevos and other small fixes.
CHEEVOS: Add ‘Achievements -> Achievements Verbose Mode’. Ability to display cheevos related messages in OSD, useful for RetroAchievements users.
AUDIO: Audio mixer’s volume can now be independently increased/decreased, and muted.
AUDIO: Mute now no longer disables/enables audio but instead properly mutes the audio volume. Mute is also independent from the audio mixer volume.
INPUT: Add mouse index selection; ability now to select between different mice
INPUT: Fix ‘All Users Control Menu’ setting
LINUX: Add a tinyalsa audio driver. Doesn’t require asoundlib, should be self-contained and lower-level.
LOBBIES: Announce the RetroArch version too
LOCALIZATION: Add Traditional Chinese translation
LOCALIZATION: Update French translation
LOCALIZATION: Update Italian translation
LOCALIZATION: Update Japanese translation
LOCALIZATION: Update Russian translation
MENU: Add ‘User Interface -> Views’. Ability to display/hide online updater and core updater options.
NETPLAY: Disconnecting one client shouldn’t cause everyone to disconnect anymore
NETWORK: SSL/TLS support, disabled by default
SCANNER: Fix PS1 game scanning
SCANNER: Move content list builder into scanner task with progress, fixes menu freeze with large playlists
SDL2: Fix ‘SDL2 driver does not see the hat on wired Xbox 360 controller”
SETTINGS: Fix regression ‘Custom Viewport is no longer overridable per-core or per-game’
VITA: Add cheevos support
VITA: Add support for external USB if mounted
WAYLAND: Fix menu mouse input
WII: Add support for single-port ‘PS1/PS2 to USB controller adapter’
Platform highlights
Windows
There are now installers available for the Windows version! We offer installers for both the Windows Vista and up version, and the Windows XP version.
RetroArch will be installed by default to your user roaming profile, however, you can change this to any particular directory you’d prefer instead. The reason why we do not try to install to “Program Files” by default is because RetroArch needs read/write permissions in order to write downloaded core files directly to its folders.
Our installer installs RetroArch in ‘portable’ fashion. What this means is that you can take the directory that RetroArch was installed in, deploy it to another drive, and it will still run, and the default paths will automatically change their paths.
Windows XP
So MinGW has broken backwards compatibility with Windows XP sometime ago. This was a problem for us, since Libretro/RetroArch treats backwards compatibility very seriously.
So, what we have done is make a separate version of RetroArch for Windows primarily targeted at people running Windows XP. Instead of MinGW, we are using Microsoft Visual Studio 2010 / MSVC 2010 as the compiler for this. We have also already ported at least 30+ cores over to MSVC 2010 so that they will run on this new Windows XP version.
We will not simply just stop at a Windows XP version – sometime later on next week, a Visual Studio 2005 version of RetroArch will be launched which will run on Windows 98 / ME / 2000! Where other projects are dropping older OSes and even entire architectures in order to cut down on maintenance and development time, we instead are adding even more platforms, and primarily because we both care about this and see the value in a platform/program that truly extends everywhere, and also because our infrastructure is set up in such a way that we can easily deal with any ‘maintenance’ burden this would otherwise entail for other projects.
Linux – Flatpak
RetroArch/Libretro has from Day One always treated Linux not only as a first-class citizen, but also pretty much as a reference platform. Unlike so many other projects that treat Linux simply as a quick and dirty port where they choose the path of least resistance and just use some middleware like SDL/WINE, RetroArch has custom audio, video and input drivers all written from scratch. It was one of the first programs outside of demo programs to support newfangled technologies like DRM/KMS, was very quick in adopting new rendering servers like Wayland, and unlike other software that simply uses middleware like SDL and/or PortAudio to provide sound, we have custom audio drivers written from scratch for ALSA/PulseAudio/JACK/OSS basically since Day One.
The problem with Linux though is that all of these features are highly distro-dependent, and each and every Linux distribution has enough differences that a traditional binary that runs on every Linux distribution is close to impossible. So, for now, we have simply left the responsibility of maintaining and packaging up RetroArch to individual distributions. Distributions like Arch Linux, Debian, and others have RetroArch and the various cores inside their package management repos, and they maintain it separately from us. Similarly, committers like sergio-br2 maintain Ubuntu repositories for RetroArch and its various cores.
But now, there are finally options for those who would like to try out RetroArch on Linux in a distro-agnostic fashion! Read all about it in our Flatpak article that we launched a few days ago. Within a few days, we will also be offering AppImage support.
iOS
A serious regression in the iOS version which made 32bit color format cores no longer render has been fixed. Also, a user has been helping us prepare for iOS 11 support.
If you’d like to learn how to compile RetroArch for yourself on iOS for your non-jailbroken device, read this article here.
macOS / MacOS X
RetroArch has been updated for both macOS/OSX Intel (for 64bit) and for OSX PowerPC (for PowerMacs/Powerbooks that have OSX 10.5 installed). The version for PowerPC comes bundled with the cores since we don’t host these on our buildbot (yet?).
PS Vita
Not only has Cheevos support been added, but it’s also possible now to use external USB devices if they are mounted! In order to use RetroArch on Vita, you need a jailbroken PS Vita and/or PSTV. Instructions on how to do that can be found elsewhere and falls beyond the scope of this article.
Wii/WiiU/3DS/Gamecube/PSP/Android
RetroArch has been updated for all other platforms that we actively support.
PlayStation3
We have posted a DEX version. We hope that separate community members can convert this to CEX and then offer it to us so we can host it.
Updates on cores
A separate article will be posted later that will detail all the work that has gone into the various cores. Stay tuned for this! As always, you can always install the latest version of every core from RetroArch’s builtin ‘Core Updater’ (accessible from the menu by going to ‘Online Updater’ -> ‘Update Cores’.
What’s up next?
* We are working hard right now on getting the PPSSPP / Supermodel cores that we have promised ready.
* An AppImage version of RetroArch for Linux will be available soon.
* A Visual Studio 2005 version of RetroArch for Windows will be available soon, which will run on Windows 98/ME/2K.
* Lots of core work like we always do each week.
* More yet unannounced stuff? Stay tuned!
View this page if you’d like to explore donating to us. By popular demand, there is now the ability to send one-off donations through Bitcoin, and we have put up links so that you can directly send funds to the Bountysource bucket. You can also pledge to our Patreon.
Installing RetroArch on Linux has just become a whole lot easier with the use of Flatpak. Flatpak provides a common standard in which to install sandboxed applications across many different Linux operating systems and desktop environments. Along with the Flathub repository, installing RetroArch with Flatpak becomes a breeze.
Install Flatpak
The first thing to do when getting up and running with Flatpak is to install it. There are many different ways to install Flatpak, so I’ll let you decide the best for your distribution. Once installed, you should be able to run the following command to see how to use it:
flatpak --help
Add Flathub
Much like your favourite package manager, Flatpak uses repositories to manage available applications. Flathub is a quickly-growing Flatpak repository, which is where RetroArch is available from. To let Flatpak know about Flathub, you’ll have to add the repository to your remotes:
When RetroArch is installed through Flatpak, it will automatically become available through the system menu and you can run it as normal. Alternatively, you can also run it through the terminal:
flatpak run org.libretro.RetroArch
RetroArch running through Flatpak
With Flatpak, you can install applications on Linux very easily, no matter what distribution or desktop environment you use. Flatpak repositories like Flathub provide a central hub in which to keep applications up to date. This revolutionises the way applications can be installed on Linux, and provides just one more easy way to install RetroArch.
Soul Calibur 2 running on the Dolphin core. Internal resolution is 12K, which gets downsampled to a 4K desktop resolution through Nvidia DSR.Here at RetroArch/libretro, we have always insisted on catering to both the low-end as well as the high end. To further this purpose, we always make design considerations from this perspective, that whatever we do shouldn’t be at the cost of worse performance on lower specced hardware that we still support.
Newer generation emulators are increasingly catering to the high end and almost demand it by virtue of them being based on much more recent videogame systems. While testing RetroArch and various libretro cores on our new high-end Windows desktop PC, we noticed that we could really take things up a few notches to see what we could get out of the hardware.
Dolphin
While working on the Dolphin libretro core some more, we stumbled upon the issue that internal resolution increases were still not working properly. So while fixing that in the latest core, we felt that the default scaled resolution choices that Dolphin provides (up to 8x native resolution) weren’t really putting any stress on our Windows development box (a Core i7 7700K equipped with a Titan XP).
So, in the process we added some additional resolution options so you can get up to 12K. The highest possible resolution right now is 19x (12160×10032).
As for performance results, even at the highest 19x resolution, the average framerate was still around 81fps, although there were some frame drops here and there and I found it to be generally more safe to dial the internal resolution down to a more conservative 12x or 15x instead). 12x resolution would be 8680×6336, which is still well over 8K resolution.
Note that the screenshots here are compressed and they are downscaled to 4K resolution, which is my desktop resolution. This desktop resolution in turn is an Nvidia DSR custom resolution, so it effectively is a 4K resolution downsampled to my 1080p monitor. From that, I am running RetroArch with the Dolphin core. With RetroArch, downscaling is pretty much implicit and works on the fly, so through setting the internal resolution of the EFB framebuffer, I can go beyond 4K (unlike most games which just query the available desktop resolutions).
We ran some performance tests on Soul Calibur 2 with an uncapped framerate. Test box is a Core i7 7700k with 16GB of DDR4 3000MHz RAM, and an Nvidia Titan XP video card. We start out with the base 8x (slightly above 4K Ultra HD) resolution which is the highest integer scaled resolution that Dolphin usually supports. If you want to go beyond that on regular Dolphin, you have to input a custom resolution. Instead, we made the native resolution scales go all the way up to 19x.
On the Nvidia Control panel, nearly everything is maxed out – 8x anti-aliasing, MFAA, 16x Anisotropic filtering, FXAA, etc.
Resolution
Performance (with OpenGL)
Performance (with Vulkan)
8x (5120×4224) [for 5K]
166fps
192fps
9x (5760×4752)
165fps
192fps
10x (6400×5280)
164fps
196fps
11x (7040×5808)
163fps
197fps
12x (7680×6336) [for 8K]
161fps
193fps
13x (8320×6864)
155fps
193fps
14x (8960×7392)
152fps
193fps
15x (9600×7920) [for 9K]
139fps
193fps
16x (10240×8448) [for 10K]
126fps
172fps
17x (10880×8976)
115fps
152fps
18x (11520×9504) [for 12K]
102fps
137fps
19x (12160×10032)
93.4fps
123fps
OpenLara
OpenLara running at over 16K
The OpenLara core was previously capped at 1440p (2560×1440). We have added available resolutions now of up to 16K.
Resolution
Performance
2560×1440 [for 1440p/2K]
642fps
3840×2160 [for 4K]
551fps
7680×4320 [for 8K]
407fps
15360×8640 [for 16K]
191fps
16000×9000
176fps
Craft
Craft core running at over 16K
Previously, the Craft core supported only up to 1440p. Now it supports up to 16K and slightly higher.
For the Craft core, we are setting the ‘draw distance’ to 32, which is the highest available draw distance available to this core. With the draw distance set this far back, you can even see some pop-in right now (terrain that is not yet rendered and will only be rendered/shown when the viewer is closer in proximity to it).
Resolution
Performance
2560×1600 [for 1440p/2K]
720fps
3840×2160 [for 4K]
646fps
7680×4320 [for 8K]
441fps
15360×8640 [for 16K]
190fps
16000×9000
168fps
Parallel N64 – Angrylion software renderer
This scene serves as our benchmark test for both the software Angrylion renderer as well as the Vulkan-based Parallel renderer.
So accurate software-based emulation of the N64 has remained an elusive pipe dream for decades. However, it seems things are finally changing now on high-end hardware.
This test was conducted on an Intel i7 7700K running at Boost Mode (4.80GHz). We are using both the OpenGL video driver and the Vulkan video driver for this test, and we are running the game Super Mario 64. The exact spot we are testing at it is at the Princess Peach castle courtyard.
Super Mario 64
Description
Performance (with OpenGL)
Performance (with Vulkan)
Angrylion [no VI filter]
73fps
75fps
Angrylion [with VI filter]
61fps
63fps
Quake 64
Description
Performance (with OpenGL)
Performance (with Vulkan)
Angrylion [no VI filter]
81fps
82.5fps
Angrylion [with VI filter]
68fps
72fps
Killer Instinct Gold
Description
Performance (with OpenGL)
Performance (with Vulkan)
Angrylion [no VI filter]
57.9fps
58.7fps
Angrylion [with VI filter]
54.6fps
55fps
GoldenEye 007
Tested at the Dam level – beginning
Description
Performance (with OpenGL)
Performance (with Vulkan)
Angrylion [no VI filter]
54.9fps
43.8fps
Angrylion [with VI filter]
45.6fps
40.9fps
Note that we are using the cxd4 RSP interpreter which, despite the SSE optimizations, would still be pretty slow compared to any RSP dynarec, so these results are impressive to say the least. There are games which dip more than this – for instance, Killer Instinct Gold can run at 48fps on the logo title screen, but on average, if you turn off VI filtering, most games should run at fullspeed with this configuration.
In case you didn’t notice already, Vulkan doesn’t really benefit us much when we do plain software rendering. We are talking maybe a conservative 3fps increase with VI filtering, and about 2fps or maybe even a bit less with VI turned off. Not much to brag about but it could help in case you barely get 60fps and you need a 2+ fps dip to avoid v-sync stutters.
Oddly enough, the sole exception to this is GoldenEye 007, where the tables are actually turned, and OpenGL actually leaps ahead of Vulkan quite significantly, conservatively by about 5fps with VI filter applied, and even higher with no VI filter. I tested this many times over to see if there was maybe a slight discrepancy going on, but I got the exact same results each and every time.
Parallel N64 – Parallel Vulkan renderer
Quake 64 on Parallel N64 – tested with both Angrylion and Parallel
So we have seen how software-based LLE RDP rendering runs. This puts all the workload on the CPU. So what if we reverse the situation and put it all on the GPU instead? That is essentially the promise of the Parallel Vulkan renderer. So let’s run the same tests on it.
This test was conducted on an Intel i7 7700K running at Boost Mode (4.80GHz). We are using the Vulkan video driver for this test, and we are running the game Super Mario 64. The exact spot we are testing at it is at the Princess Peach castle courtyard.
Super Mario 64
Description
Performance
With synchronous RDP
192fps
Without synchronous RDP
222fps
Quake 64
Description
Performance
With synchronous RDP
180fps
Without synchronous RDP
220fps
Killer Instinct Gold
Description
Performance
With synchronous RDP
174fps
Without synchronous RDP
214fps
GoldenEye 007
Tested at the Dam level – beginning
Description
Performance
With synchronous RDP
88fps
Without synchronous RDP
118fps
As you can see, performance nearly doubles when going from Angrylion to Parallel renderer with synchronous RDP enabled, and beyond with it disabled. Do note that asynchronous RDP is regarded as a hack and it can result in many framebuffer oriented glitches among other things, so it’s best to run with synchronous RDP for best results.
We are certain that by using the LLVM RSP dynarec, the performance difference between Angrylion and Parallel would widen even further. Even though there are still a few glitches and omissions in the Parallel renderer compared to Angrylion, it’s clear that there is a lot of promise to this approach of putting the RDP on the GPU.
Conclusion: It’s quite clear that even on a quad-core 4.8GHz i7 CPU, the CPU ‘nearly’ manages to run most games with Angrylion [software] at fullspeed but it doesn’t leave you with a lot of headroom really. Moving it to the GPU [through Parallel RDP] results in a doubling of performance with the conservative synchronous option enabled and even more if you decide to go with asynchronous mode (buggier but faster).
Beetle PSX
Previously, Beetle PSX would only provide internal resolution increases up to 8 times the original resolution. We have now extended this to 32 x for software and Vulkan, and 16x for OpenGL.
The results are surprising – while the Vulkan renderer is far more mature than the OpenGL renderer and implements the mask bit unlike the GL renderer (along with some other missing bits in the current GL renderer), the GL renderer leaps ahead in terms of performance at nearly every resolution.
Crash Bandicoot
Crash Bandicoot running at over 10K. Note this is being downsampled to 4K.
Crash Bandicoot is a game that ran at a resolution of 512×240.
Resolution
Performance (with OpenGL) [with PGXP]
Performance (with OpenGL) [w/o PGXP]
Performance (with Vulkan) [with PGXP]
Performance (with Vulkan) [w/o PGXP]
Performance (software OpenGL)
Performance (software Vulkan)
8192×3840 [16x] [for 5K]
188.8fps
266fps
217fps
239fps
4.4fps
5.3fps
4096×1920 [8x] [for 2K]
216fps
296fps
218fps
240fps
16fps
17.5fps
2048×960 [4x]
215fps
296fps
216fps
239fps
52fps
57.9fps
1024×480 [2x]
216fps
296fps
216fps
239fps
138fps
145fps
Tekken 3
Tekken 3 running at over 10K, being downsampled to 4K.
Tekken 3 is a game that ran at a resolution of 368×480.
Resolution
Performance (with OpenGL) [with PGXP]
Performance (with OpenGL) [w/o PGXP]
Performance (with Vulkan) [with PGXP]
Performance (with Vulkan) [w/o PGXP]
Performance (software OpenGL)
Performance (software Vulkan)
11776×15360 [32x] [for 12K]
N/A
N/A
127fps
127.4fps
N/A
N/A
5888×7680 [16x] [for 4K]
188.5fps
266fps
184.4fps
211fps
4.4fps
6.6fps
2944×3840 [8x] [for 2K]
186.5fps
208fps
183.5fps
269fps
22fps
25.2fps
1472×1920 [4x]
184.5fps
270fps
230.5fps
210fps
52fps
59.4fps
1024×480 [2x]
232fps
271fps
185.5fps
210fps
129fps
137fps
Reicast
Dead or Alive 2 running at over 12K resolution on Reicast Daytona USA 2001 running at over 12K resolution on Reicast Sonic Adventure running at over 12K resolution on Reicast
Dead or Alive 2
Description
Performance
4480×3360
206fps
5120×3840
206fps
5760×4320
206fps
6400×4800
204fps
7040×5280
206fps
7680×5760
206fps
8320×6240
204fps
8960×6720
204fps
9600×7200
207fps
10240×7680
206fps
10880×8160
207fps
11520×8640
207fps
12160×9120
194fps
12800×9600
193fps
As you can see, it isn’t until we reach 12160×9120 that Reicast’s performance finally lets up from an almost consistent 206/207fps to a somewhat lower value. Do note that this was testing the same environment. When alpha effects and RTT (Render to Texture) effects are being applied onscreen, there may well be dips on the higher than 8K resolutions whereas 8K and below would be able to handle it with relative ease.
Mupen64plus – GlideN64 OpenGL renderer
Super Mario 64 running at 8K resolution with Gliden64.
This core uses Mupen64plus as the core emulator plus the GlideN64 OpenGL renderer.
Super Mario 64
Description
Performance
3840×2880 – no MSAA
617fps
3840×2880 – 2x/4x MSAA
181fps
4160×3120 – no MSAA
568fps
4160×3120 – 2x/4x MSAA
112fps
4480×3360 – no MSAA
538fps
4480×3360 – 2x/4x MSAA
103fps
4800×3600 – no MSAA
524fps
4800×3600 – 2x/4x MSAA
94fps
5120×3840 – no MSAA
486fps
5120×3840 – 2x/4x MSAA
82fps
5440×4080 – no MSAA
199fps
5440×4080 – 2x/4x MSAA
80fps
5760×4320 – no MSAA
194fs
5760×4320 – 2x/4x MSAA
74fps
6080×4560 – no MSAA
190fps
6080×4560 – 2x/4x MSAA
68fps
6400×4800 – no MSAA
186fps
6400×4800 – 2x/4x MSAA
61.3fps
7680×4320 – no MSAA
183fps
7680×4320 – 2x/4x MSAA
39.4fps
GoldenEye 007
Tested at the Dam level – beginning
Description
Performance
3840×2880 – no MSAA
406fps
3840×2880 – 2x/4x MSAA
100fps
4160×3120 – no MSAA
397fps
4160×3120 – 2x/4x MSAA
65fps
4480×3360 – no MSAA
375fps
4480×3360 – 2x/4x MSAA
60fps
4800×3600 – no MSAA
342fps
4800×3600 – 2x/4x MSAA
54fps
5120×3840 – no MSAA
310fps
5120×3840 – 2x/4x MSAA
51fps
5440×4080 – no MSAA
70fps
5440×4080 – 2x/4x MSAA
46fps
5760×4320 – no MSAA
78.9fs
5760×4320 – 2x/4x MSAA
42fps
6080×4560 – no MSAA
86fps
6080×4560 – 2x/4x MSAA
37fps
6400×4800 – no MSAA
79fps
6400×4800 – 2x/4x MSAA
27fps
7680×4320 – no MSAA
79fps
7680×4320 – 2x/4x MSAA
33.2fps
Preface: Immediately after going beyond 3840×2880 (the slightly-higher than 4K resolution), we notice that turning on MSAA results in several black solid colored strips being rendered where there should be textures and geometry. Again, we notice that enabling MSAA takes a huge performance hit. It doesn’t matter either if you apply 2 or 4 samples, it is uniformly slow. We also notice several rendering bottlenecks in throughput – as soon as we move from 5120×3840 to 5440×4080 (a relatively minor bump), we go from 310fps to suddenly 70fps – a huge dropoff point. Suffice to say, while you can play with Reicast (Dreamcast emulator) and Dolphin (Gamecube/Wii) at 8K without effort and even have enough headroom to go all the way to 12K, don’t try this anytime soon with Gliden64.
We suspect there are several huge bottlenecks in this renderer that prevent it from reaching higher performance, especially since people on 1060s have also complained about less than stellar performance. That being said, there are certain advantages to Gliden64 vs. Glide64, it emulates certain FBO effects which GLide64 doesn’t. It also is less accurate than Glide64 in other areas, so you have to pick your poison on a per-game basis.
We still believe that the future of N64 emulation relies more on accurate renderers like Parallel RDP which are not riddled with per-game hacks vs. the traditional HLE RDP approach as seen in Gliden64 and Glide64. Nevertheless, people love their internal resolution upscaling, so there will always exist a builtin audience for these renderers, and it’s always nice to be able to have choices.
This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful. We are using cookies to give you the best experience on our website. We collect users data for personalisation of ads, and also Google will use your personal data when you give consent on our site. Check this link to Google’s Privacy & Terms site.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.
3rd Party Cookies
This website uses Google Analytics to collect anonymous information such as the number of visitors to the site, and the most popular pages.
Keeping this cookie enabled helps us to improve our website.
Please enable Strictly Necessary Cookies first so that we can save your preferences!
