Some significant improvements have been made to the Dreamcast emulator core Flycast by flyinghead that serve to increase the graphics accuracy.
For one, the OpenGL renderer has mip-mapping support now for the first time. Second, all texture mipmap levels are now uploaded to the GPU. The Vulkan renderer no longer auto-generates mip-maps and instead uses the proper mipmap levels. What happened before is that these auto-generated mipmaps would ‘bleed’, whereas the ones provided by the game do not.
This caused issues with games like Railroad Tycoon 2 where the beach texture was not properly displayed.
Before the fix, you’d have weird magenta colors on the beaches with the Vulkan renderer. This has now been resolved.
To learn more about texture bleeding, you can read this StackExchange article here.
Another example of what texture bleeding looks like can be seen down below (and note that this is now also fixed) – previously texture bleeding would regularly occur at upscaled resolutions –
Many of these issues have now been fixed. See the picture down below how the title screen above for instance looks like now –
How mip-mapping looks like on Dreamcast
To best illustrate the effect mip-mapping has on the video output quality, let us show some comparison pictures at the Dreamcast’s native 640×480 resolution.
The picture down below shows Soul Calibur running with mip-mapping disabled:
The picture down below shows Soul Calibur running with mip-mapping enabled:
At higher resolutions you will notice the blurriness starting to gradually disappear.
Combining mip-mapping with anisotropic filtering
The Vulkan renderer allows you to apply Anisotropic filtering (AF) to the textures (to learn more about it, read the Wikipedia page here).
While you can still make out some of the far textures in the distance being slightly blurry as a result of the mip-mapping, overall the blurriness factor is significantly reduced as a result of the agressive 16x AF filtering being applied here, even at a very low resolution of 640×480.
Even further tweaking possible with PowerVR postprocessing filter
You don’t have to stop at mipmapping and AF filtering of course. You can also take advantage of leilei’s PowerVR post processing filters on top to further enhance the authenticity of the picture.
NOTE: For now, the PowerVR postprocessing filters only work with OpenGL. Vulkan support will arrive later.
Here we have mip-mapping enabled and PowerVR 2 Postprocessing filter enabled. NOTE: Because this is the OpenGL renderer, anisotropic filtering right now is not available, so we cannot show you a picture of how the PVR2 postprocessing looks like in conjunction with 16x AF. Neither can we show a similar picture on Vulkan right now because the aforementioned PVR2 postprocessing filters are not available there. Hopefully both renderers can be at feature parity soon in these departments.
How to get it
There are two ways to update your Flycast core. Start up RetroArch first –
a – If you have already installed the core before, you can go to Online Updater and select ‘Update Installed Cores’.
b – If you haven’t installed the core yet, go to Online Updater, ‘Core Updater’, and select ‘Flycast’ from the list. It will then download and install this core.
The first Dreamcast emulator ever to get a Vulkan renderer. Completely open-source, written from scratch, and available later today on RetroArch. Update your core later today to get the latest version with the Vulkan renderer! Available for Android, Windows, and Linux.
For more information, read down below…
Wait … a new what?
The renderer is the emulator component that emulates the Dreamcast/Naomi GPU chip, namely the PowerVR Series2. It was one of the first generations of 3D chips, with only a fixed pipeline. The PowerVR2 supported DirectX 6.0, which was the graphics API used by Windows CE games on the Dreamcast. Successors of the PowerVR2 would later be found in the original iPhone and iPod Touch (PowerVR4), iPhone 4 and iPad (PowerVR5) and many many other mobile devices. Now the Dreamcast GPU is more than 20 years old. You might think it should be easy to emulate such an ancient chip on modern hardware, right? Well … yes for the most part. But there’s one thing that the PVR2 does really well, and it’s order-independent transparency. And even today this is still not trivial to implement even on modern hardware. You won’t find this feature in Open GL or DirectX, and you need a pretty recent version of these APIs to be able to emulate it, which means manually sorting individual pixels from back to front and blending them together, and doing this for each visible pixel on the screen!
OK, but what about Vulkan?
For those of you who are not familiar with Vulkan, it is a relatively new 3D graphics API, basically a follow-on to Open GL. Open GL is quite permissive and has little declarative constraints. You just throw stuff at the driver when you need to and the driver’s job is to figure it out. The downside of this is that the Open GL driver often needs to guess what you’ll do next and he might not guess right. And when it doesn’t, performance suffers. Vulkan is radically different in that everything must be declared in advance, in great details, and there’s very little room for improvisation on the part of the driver. Vulkan works much closer to the hardware than Open GL does. So you can expect less overhead, more reliability and better performance in many cases.
The downside of Vulkan is the sheer amount of code you have to write to display just a single triangle on the screen, let alone a full-featured Dreamcast renderer. Last time I checked, the Vulkan renderer had 47 source files and around 7800 lines of code. (The Open GL renderer only has around 6000 lines of code.)
So what do we get?
As with Open GL, there are actually two Vulkan renderers: The first one uses a traditional single render pass with per-triangle or per-mesh sorting done by the CPU. The second one is capable of order-independent transparency with per-pixel sorting performed by the GPU. It uses multiple subpasses to compose the final image: the first subpass draws the opaque geometry depth map and the shadows casted on them. The second subpass renders all opaque geometry to a temporary color framebuffer, and transparent geometry into a huge pixel linked list. The last subpass then renders shadow volumes for translucent geometry. And finally all pixels are sorted and blended together using the opaque framebuffer of the previous subpass as background.
The next Flycast nightly build will have support for Vulkan on all major platforms: Windows, Linux and Android. In terms of features, the new renderer should be on par with the Open GL renderer, with the notable exception of lightgun crosshair and VMU screens display, which will be added soon. However, expect to find bugs and crashes here and there as is expected with any new piece of software. Also it may be slower than Open GL depending on many factors such as GPU, driver version, game being played, etc. We’ll do our best to fix any issue encountered and overcome performance issues. When reporting problems, make sure to indicate what GPU you’re using and the Vulkan driver version. It is highly recommended to upgrade your drivers to the latest version available, especially on mobile.
Here is a showcase of the differences between the basic and OIT renderers. By the way, this also applies to Open GL.
Here the hair of these ladies show glitching triangles in basic mode.
In Speed Devils 2, the shadow volumes (called “Modifier Volumes” in Dreamcast literature) are used in a special way to project headlights. This is only possible by using deferred rendering.
In this example, look at Ryo’s cast shadow on his left. There is a fog effect applied to this scene, but the basic single pass renderer cannot apply a fog effect to the cast shadow. In the OIT renderer, the shadow is perfectly fogged.
In Jet Set Radio, the character is composed of translucent polygons, and these polygons can be shadowed as well. Only the OIT renderer can properly render shadows cast on translucent polygons.
To finish, here is another seldom used GPU features: secondary accumulation buffer. It can be used to do tri-linear filtering and other effects. This is Evil Dead – Hail to the King and it is clear that the basic renderer is having a hard time here.
Yes, the per-pixel alpha transparency option which to this date was only available on Windows and Linux now also works on Android with the Vulkan renderer. However, keep in mind that per-pixel alpha sorting is heavily memory bandwidth-limited. It has been tested on a Mali G76 (Samsung Galaxy S10+) – and it runs acceptably at 640×480 or 800×600 resolution. Your mileage may vary depending on the GPU power inside your Android phone. We recommend you to find that sweet spot which works best for you, and if results are too bad with per-pixel alpha enabled, turn back to per-triangle.
Some clear advantages of the Vulkan renderer is that frame pacing is much better than the OpenGL renderer, and performance is far higher when it comes to texture uploads and/or framebuffer manipulation. For example – when you KO an opponent in Dead Or Alive 2 against an explosive wall – the framerate would often tumble a bit on GL, but no such issues with Vulkan. Similar improvements can be noticed in Virtua Tennis 2 – when certain framebuffer effects happen after a replay, performance is much more steady with Vulkan thanks to the high degree of parallelism.
With Vulkan, we have heard reports that virtually all sound crackles and stutters are gone. That’s because with vulkan you choose the sync points where you wait. In GL the driver has to guess and sometimes it fails. These effects are using render to texture, and with OpenGL this creates sync issues.
New version will be available later today on the Buildbot!
Flyinghead has significantly improved HLE BIOS support to the point where 90% of Dreamcast games (both regualr and Windows CE-based games) should now be supported! Previously, compatibility with the HLE BIOS was quite abysmal, to the point where we couldn’t justify enabling it by default. So this marks an important point where users are no longer required to go seek out an external Dreamcast BIOS and can just run a Dreamcast game out of the box without needing to setup a specific BIOS!
A couple of notes:
‘HLE BIOS’ is now enabled by default. If you wish to disable it and rely on a real external BIOS, you go to Quick Menu -> Options, and disable ‘HLE BIOS’ there.
The ‘Fast GD-ROM Loading’ option right now doesn’t work with the HLE BIOS. Disable ‘HLE BIOS’ if you want to make use of this feature.
Previous savestates are no longer compatible with this current version. Later on, compatibility with these older savestates will be restored. We will let you know when that happens. Until then, we recommend making new savestates.
When do I get to use this?
Today! Updated versions of both Flycast cores (regular and Windows CE versions) are being uploaded to the buildbot as we speak, so you’ll be able to play with this later today if all goes well.
Flyinghead intends to merge the regular and Windows CE versions into one version come September. The inclusion of Windows CE/MMU codepaths should no longer slow down regular non-Windows CE games. On the contrary, SSA and lots of optimizations done for Windows CE will benefit the non-Windows CE games as well, so you can expect this universal version later on to be a bit faster.
This closed source emulator recently added support for this – flyinghead has already been able to match this in his branch. Like the other emulator, it should result in Street Fighter III 3rd Strike being rendered correctly, along with in-game screen adjustment being possible. It should be noted though that more regression testing is needed first because changes like these can have an adverse effect on other games that are currently being rendered fine, like Metropolis Street Racer. We rather suspect not enough testing was done to check for regressions in this other emulator since flyinghead was able to see a bunch of regressions as part of this feature being added, so we’d rather not jump the gun.
Open source Dreamcast emulation has seen a tremendous boost ever since flyinghead appeared on the scene. Whereas open source Dreamcast emulators seemed previously hopelessly behind something like Demul from a compatibility and accuracy perspective, right now it seems we are well on track to matching it save for Flycast not being able to emulate certain specialized arcade systems like Naomi 2, which are technically not really Dreamcast/Naomi 1 anyway but its successor.
So, right now, Flycast is in a very good spot:
It allows you to run Sega Naomi games. Only other emulators that support this are DEmul and Makaron (both closed-source).
It allows you to run Windows CE games. Only other emulator that supports this is DEmul (closed-source).
There are no limitations on savestates and internal resolutions, there is no paywall to speak of. Savestate support was added years ago.
Modem support. DEmul only supports Broadband Adapter support, but Flycast supports actual modem support (32K/64K models).
There is built-in zero configuration online multiplayer support, that works cross-platform with real Dreamcasts as well. Flycast is currently the only Dreamcast emulator available so far that supports this.
You can enable VMU support and configure where the VMU screen gets displayed onscreen. Up to 4 VMUs at a time can be displayed onscreen.
It has a work-in-progress HLE BIOS implementation that has about a 90% compatibility rate. It even works with Windows CE games.
It runs on 32bit systems as well as 64bit systems, and is available for x86 and ARM.
It has been available on Android and iOS for years now.
We might even add real CD-ROM support soon to it, so that it can run CD-R based backup discs!