Wunk
736189ea77
* config: Add `sample_count` renderer option
Option is only enabled when the renderer is set to Vulkan, for now.
* vk_blit_helper: Add `d24s8_to_rgba8_ms_comp`
Helper host-shader for blitting multi-sampled DS24S8 textures to multi-sampled RGBA8
* vk_instance: Add detection of MSAA features
Full multi-sample support is when renderpass-2 and depth-stencil-resolve extensions are available and when sample-rate-shading and msaa-storage-images are supported.
* rasterizer_cache: Initial support for multi-sample surfaces
* renderer_vulkan: Implement multisample pipeline/renderpass support
Allows multi-sample render passes and graphics pipelines to be created, using sample-rate shading rather than coverage-based MSAA.
* renderer_vulkan: Implement multisample texture runtime
This seems to be enough for simple programs to render with MSAA enabled!
* renderer_vulkan: Fix multisample texture init barrier
Should address the MultiSampled image directly since the multisampled image is just a transient image and not the leading state of the image.
* renderer_vulkan: Fix `Framebuffer::sample_count` move-operator
`sample_count` needs to be move/copied over.
Also reorder the accessor order to match the declaration of variables.
* renderer_vulkan: Fix dangling surface reference during msaa resolve
These individual parameters need to be copied as the reference to the surface-object only lasts within the scope of this function.
* renderer_vulkan: Derive framebuffer sample-count from attachments
Derive the framebuffer sample-count from the input color and depth operands. Similar to how `res_scale` is determined.
* renderer_vulkan: Fix initialization of image handles
Try to optimally create the new image handles when a change in res scale or sample-count has actually occured. MSAA images need to be updated too in the case that the resolution scale has changed
* renderer_vulkan: Fix cleanup and debug-naming for `d24s8_to_rgba8_ms_comp`
* renderer_vulkan: Add `TextureRuntime::ResolveTexture`
Rather than use a big lambda, just rip this out into a proper function for other blit functions to utilize.
* renderer_vulkan: Fix narrowing byte conversion
Fixes a compilation error on Unix platforms.
* renderer_vulkan: Fix MSAA framebuffer target resolve surface
Use the specified type rather than defaulting to the surface's current one(implicit `ImageView` argument).
* renderer_vulkan: Fix `Surface::ScaleUp` scale/sample increase
This should be checking the _new_ value to possibly cull upscaled texture creation rather than the current value of the surface. Fixes broken up render passes when drawing UI in some games.
* renderer_vulkan: Fix `ConvertDS24S8ToRGBA8` image targets
Ensure that the Multi-Sample texture is used for the destination color image as well. Should the dest image be MSAA too? Or should all the values be resolved into a minimum depth and some combination of stencil-values here?
* renderer_vulkan: Fix multisample `ClearTextureWithRenderpass`
Ensure that the multisample framebuffer is used rather than the usual one when using a render pass to clear the textures.
That way, a MSAA-render AND resolve is used to clear the textures at the same time.
* renderer_vulkan: Fix multisample framebuffer creation
MSAA renderpasses require the "current" image as the main resolve target, and the MSAA image as the second attachment.
* renderer_vulkan: Fix MSAA image debug name
* renderer_vulkan: Fix Multisample `ConvertDS24S8ToRGBA8`
Migrate `ResolveTexture` to `BlitHelper`.
If the conversion was multi-sample, do a final resolve at the end of the conversion to ensure the non-multisample textures are updated as well.
Fixes Pokemon!
* config: Refactor `sample_count` to `antialiasing` setting
Intended to allow for other anti-aliasing methods to be introduced
* renderer_gl: Initial MSAA implementation
Basically copied over some of the paradigms over from Vulkan. Covers most rendering uses-cases except for conversions such as `ConvertDS24S8ToRGBA8` and `ConvertRGBA4ToRGB5A1`
* renderer_gl: Fix surface `ScaleUp` implementation
Should assign the new `res_scale` and `sample_count`
* renderer_gl: Implement multisample `Convert{DS24S8ToRGBA8,RGBA4ToRGB5A1}`
* renderer_gl: Resolve framebuffer after each draw
Brute force approach while trying to determine a better heuristic. Framebuffer changes are not enough to determine the end of a "render pass". An 'msaa dirty flag' is likely the better way here.
* renderer_gl: Implement `TextureRuntime::ClearTexture` MSAA clears
When ArbClearTexture is not available, ensure the fallback implementation also clears the MSAA texture as well.
* renderer_gl: Fix MakeHandle string-view hazard
`glObjectLabel` expects a null-terminated string, but an `std::string_view` is not necessarily null-terminated
* renderer_gl: Add layer/level specifier to MSAA resolves
* renderer_vulkan: Conditionally compile `DS24S8->RGBA8` multisample pipeline
This will crash on apple due to the lack of support for MSAA texture storage operations. This gets MacOS running generally now, but will likely require a refactor of some kind into a fragment shader and graphics pipeline rather than a compute shader for MacOS in particular.
* config: Stub support for up to `MSAAx16`
This is primarily to claim the enum value before other anti-aliasing methods get added. Eventually, support for the RHI device's sample-count will have to be detected and used opportunistically. Maybe "MSAA" is the anti-aliasing method and the actual sample-count comes from someplace else?
* config: Disable `MSAAx{8,16}` options by default
These are not guaranteed to be supported and should be disabled by default for now.
We still want the config options to be allocated. They should just not user-facing until these values can be conditionally enabled with fallbacks.
* renderer_vulkan: Remove unneeded sample-count info from `RasterizerVulkan::AccelerateDisplay`
We're always resolving into the best non-msaa image.
This isnt needed here. OpenGL doesn't need it either.
* core: Fix license headers
Also fix some clang-format formatting
* renderer_vulkan: Disable MSAA functionality from MacOS
The features required to support this at the moment are out of the scope of
this PR, thus MSAA is disabled for now and will be re-enabled in a later PR.
All MSAA anti-aliasing settings are removed when running on MacOS.
The main features holding this back are:
* Dynamically detecting the number of samples that the host GPU
supports(up to x4 is required, but x8 and x16 need to be detected when
initializing the backend)
* Blit-helper needs to have non-compute-shader variants of its MSAA
reinterpretation functions, but Metal(MoltenVK) does not support writing to
individual MSAA samples from a compute shader, and instead must be done from
a regular fragment-shader from within a render-pass.
* renderer_vulkan: Fix recycling of MSAA textures
Fixes an issue where reducing the sample count at run-time was causing
crashes due to previous MSAA textures, with a higher sample count, being
re-used. This also re-orders the criteria for recycling sentenced
textures to allow for better short-circuiting. The criteria for a
texture to be recycled must strictly be the "ScaleUp" case, and not the
case where the sample-count is being _reduced_. This recycling could be
a bit smarter to consider cases where a texture can have its
sample-count reduced but not its resolution scale. But that's an
optimization that is out of the scope of this PR, I feel.
* renderer_vulkan: Fix enabled extension array size
There are 16 total calls to `add_extension` that indicates that the `enabled_extensions` array should be 16 rather than 13.
* renderer_vulkan: Disable MSAA functionality from UI
This reverts commit 26939156c0.
MSAA requires some advanced configuration features that are not quite
ready yet. Currently, `shaderStorageImageMultisample` support needs to
be detected at config-time to allow MSAA to be used. Otherwise, the
reinterpret-passes need to have a non-compute alternative implemented.
Both are pretty larege features that should not increase the scale of
this PR for now.
To mitigate people from interfacing with this feature for
now, anti-aliasing options that involve MSAA will be disabled from the
UI and only operable from editing the ini configurations. This is to
allow for other anti-aliasing methods to be allowed in the team time.
Azahar is a free and open-source high level Nintendo 3DS emulator for PC and mobile devices. Our goal is to give 3DS owners a place to enjoy their library of titles with improvements to the original hardware, such as higher resolutions, modern controllers or save states. The emulator also serves as a debugging hub for homebrew developers and as a research and preservation platform for the 3DS ecosystem.
The project continues the legacy of Citra and is actively developed by a community of contributors.
Azahar is not affiliated with or endorsed by Nintendo.
Installation
Windows
Azahar is available as both an installer and a zip archive.
Download the latest release in your preferred format from the Releases page.
If you are unsure of whether you want to use MSVC or MXE, use MXE.
MacOS
To download a build that will work on all Macs, you can download the macos-universal build on the Releases page.
Alternatively, if you wish to download a build specifically for your Mac, you can choose either:
macos-arm64for Apple Silicon Macsmacos-x86_64for Intel Macs
Android
There are two variants of Azahar available on Android, those being the Vanilla and Google Play builds.
The Vanilla build is technically superior, as it uses an alternative method of file management which is faster, but isn't permitted on the Google Play store.
For most users, we currently recommended downloading Azahar on Android via the Google Play Store for ease of accessibility:
Alternatively, you can install the app using Obtainium, allowing you to use the Vanilla variant:
- Download and install Obtainium from here (use the file named
app-release.apk) - Open Obtainium and click 'Add App'
- Type
https://github.com/azahar-emu/azaharinto the 'App Source URL' section - Click 'Add'
- Click 'Install', and select the preferred variant
If you wish, you can also simply install the latest APK from the Releases page.
Keep in mind that you will not recieve automatic updates when installing via the APK.
Linux
The recommended format for using Azahar on Linux is the Flatpak available on Flathub:
Azahar is also available as an AppImage on the Releases page.
There are two variants of the AppImage available, those being azahar.AppImage and azahar-wayland.AppImage.
If you are unsure of which variant to use, we recommend using the default azahar.AppImage. This is because of upstream issues in the Wayland ecosystem which may cause problems when running the emulator (e.g. #1162).
Unless you explicitly require native Wayland support (e.g. you are running a system with no Xwayland), the non-Wayland variant is recommended.
The Flatpak build of Azahar also has native Wayland support disabled by default. If you require native Wayland support, it can be enabled using Flatseal.
Build instructions
Please refer this repository's wiki for build instructions
How can I contribute?
Pull requests
If you want to implement a change and have the technical capability to do so, we would be happy to accept your contributions.
If you are contributing a new feature, it is highly suggested that you first make a Feature Request issue to discuss the addition before writing any code. This is to ensure that your time isn't wasted working on a feature which isn't deemed appropriate for the project.
After creating a pull request, please don't repeatedly merge master into your branch. A maintainer will update the branch for you if/ when it is appropriate to do so.
Language translations
Additionally, we are accepting language translations on Transifex. If you know a non-english language listed on our Transifex page, please feel free to contribute.
Note
We are not currently accepting new languages for translation. Please do not request for new languages or language variants to be added.
Compatibility reports
Even if you don't wish to contribute code or translations, you can help the project by reporting game compatibility data to our compatibility list.
To do so, simply read https://github.com/azahar-emu/compatibility-list/blob/master/CONTRIBUTING.md and follow the instructions.
Contributing compatibility data helps more accurately reflect the current capabilities of the emulator, so it would be highly appreciated if you could go through the reporting process after completing a game.
Minimum requirements
Below are the minimum requirements to run Azahar:
Desktop
Operating System: Windows 10 (64-bit), MacOS 13.4 (Ventura), or modern 64-bit Linux
CPU: x86-64/ARM64 CPU (Windows for ARM not supported).
Single core performance higher than 1,800 on Passmark.
SSE4.2 required on x86_64.
GPU: OpenGL 4.3 or Vulkan 1.1 support
Memory: 2GB of RAM. 4GB is recommended
Android
Operating System: Android 10.0+ (64-bit)
CPU: Snapdragon 835 SoC or better
GPU: OpenGL ES 3.2 or Vulkan 1.1 support
Memory: 2GB of RAM. 4GB is recommended
What's next?
We share public roadmaps for upcoming releases in the form of GitHub milestones.
You can find these at https://github.com/azahar-emu/azahar/milestones.
Join the conversation
We have a community Discord server where you can chat about the project, keep up to date with the latest announcements, or coordinate emulator development.
Join at https://discord.gg/4ZjMpAp3M6