You can't really do much with the dashboards though, and most of the menus are crippled due to XAM URI functions being unimplemented. Though this is quite great for Xenia, since we have the entire history of Xbox 360 dashboards that can run on PC!
I'm here to present "Gecko" a new, cross-platform and modern GameCube and Wii emulator written in Rust! It's been a work-in-progress project for a while now and I'm extremely happy to finally share it publicly :)
In case you don't care about my ramblings, here's a link to the GitHub repository!
Many games already work extremely well, but it's very far from being on Dolphin's level! GameCube games tend to work better than Wii games currently, but I know of at least one game that is perfectly playable even on the Wii. More to this a bit later!
Here are some highlighted features:
Gecko aims to offer a playable and accurate experience for the average user. However, Gecko is also tailored to reverse engineers and homebrew developers. It's packed with tons of goodies that aren't mentioned in the above list! To name a few more (if you're not interested skip ahead!):
The emulator runs on all major platforms, it has been tested on: Windows, Linux, macOS and the browser (incl. the debugger). Here's also an old YouTube video of it (poorly) running on an iPad: https://www.youtube.com/watch?v=ACW36TXlUhM, because why not?
I also automated screenshot gathering over a selection of games, these are hosted here (mainly used to catch regressions/improvements, but also useful to gauge compatibility):
I'd be more than happy to see people try it out, share their experience and perhaps even contribute!!
To finish up the post I'd like to also share the "Why?". Why does this emulator even exist? I've always been very interested in low level stuff and figured I could do something to make 12yo me proud: Create an emulator that can play my childhood favorite game (Final Fantasy Crystal Chronicles: The Crystal Bearers on the Wii). I ended up going on a multi-year journey learning about emulator development, with the goal to improve my skills and ultimately do Wii.
I mentioned earlier that a game is already perfectly playable on the Wii... That is my childhood game, so to me, this project is already a huge success despite it not being anywhere as mature as Dolphin! :)
Some final words on our EmuDevz JavaScript emulator, which is finally finished, and then on to the next challenge...writing an NES emulator in Haskell!
If you want to skip the introductory remarks about the JavaScript code and get straight to the Haskell, skip to around 3:45.
Thumbnail painting: "Napoleon Crossing the Alps", by Jaques Louis-David (1801).
This works in Chromium-based browsers, and emulates the subset of 16-bit x86 typically used in programs compiled using gcc-ia16 (e.g. it doesn't emulate the carry and overflow flags):
https://github.com/rebane2001/x86CSS
It's a few months old now, and I apologise if this was already posted here. This is a working x86 emulator written entirely in CSS. It just has a small HTML wrapper to allow browsers to load it. By default, it uses a small piece of JavaScript to provide the clock which gives a performance improvement, but you can disable JavaScript and it will fall back to a pure CSS implementation.
This isn't practical, but it's a pretty unique emulator, and I hope some of the people here find it interesting.
Goosestation is a project that allows you to transform standalone Duckstation® source code into a libretro core source code, and compile it into your own personal binary.
https://codeberg.org/hueponik/goosestation-builder/src/tag/v0.3
There's more to it, but I'm bad with changelogs.
No videoguides still, sorry. No dolphin style reports either.
Install docker, get the source (git or download from codeberg)
On windows - run:
docker build -f Dockerfile.windows -t goosestation-builder-windows .
docker run --rm -v "$PWD/dist:/work/dist:Z" goosestation-builder-windows windows
On linux:
make docker-linux
Or, if you're using the best distros:
https://codeberg.org/hueponik/goosestation-overlay
https://aur.archlinux.org/packages/goosestation-libretro
On mac:
make macos
And look for core files in dist folder.
Android users can build right on their phones with termux. Run these commands:
termux-setup-storage
pkg install -y git
git clone https://codeberg.org/hueponik/goosestation-builder.git
cd goosestation-builder
git checkout v0.3
./build-in-android.sh
The core will be in your Download folder.
Okay, hopefully I didn't break anything. Let me know how it goes on your machine. Have fun!
Oh and don't distribute compiled binaries, please!
Edit: bump to v0.3
While I initially looked into moving rom save files onto external storage devices like SD cards (so I may easily access my saves from either my Bazzite PC, Steam Deck, and hopefully eventual Steam Machine), I recently found out about using cloud syncing. I've heard of two examples: EmuSync and Syncthing. (Here's the link to the farmer's github https://github.com/emu-sync/EmuSync)
I'm inclined to try out the former since, well, it seems more in line with emudeck. But I need more insight. What are your thoughts on EmuSync? How does it compare to Syncthing?
The VDP1 core has been completely rewritten with compute shaders, greatly improving sprite rendering accuracy and compatibility for Sega Saturn games.
Blog: https://www.yabasanshiro.com/blog/2026-05-09_vdp1_emulation_with_compute_shader
Mesen is now a community-driven project under the name MesenCE. The original Mesen developer Sour is still actively involved, and future development will continue there exclusively. In other words: Mesen itself is no longer being developed separately, MesenCE is now the continuation of the project.
Hello everyone, this is the third and biggest release of ShadPS4 (PS4 emulator) GR2fork since launch. It aims to fix the remaining issues with the game while adding more features. Thank you for your patience and if you can please support me by buying me a kofi.
@ 720p 30fps(locked) @ 1080p 30fps(locked) @ 4k 60fps(locked) @ 8k 60fps(locked)
ryzen 5 3600-------------ryzen 5 3600-------------ryzen 5 7600---------ryzen 5 7600
GTX 960 4GB ------------- gtx 1060 6gb----------- rtx 3060 8gb------ rtx 5080 16gb
12 gb ram------------------12 gb ram--------------12 gb ram------------12 gb ram
SSD-------------------------SSD----------------------SSD-------------------SSD
Download my fork here -> https://github.com/junminlee2004/GR2fork
Watch my fork in action here -> https://www.youtube.com/watch?v=8aHVM7qea6g&t=5s&pp=0gcJCdQKAYcqIYzv
Buy me a kofi here -> https://ko-fi.com/junminlee2004
join the GR2fork discord server (new) here for extended support. Anyone who wants to lurk for general game discussion surrounding gravity rush 1 and 2 are also welcome -> https://discord.gg/hnHRpzxGzG
If you downloaded Cemu 2.6 in its x64 AppImage for Linux of Ubuntu zipfile between May 6 2026 and May 12 2026, you might have downloaded a compromised package.
More details here : https://rentry.org/cemu-security-psa
If you use a tool such as EmuDeck and updated its emulators in that time period, your copy of Cemu is also possibly compromised (as EmuDeck uses the Cemu AppImage).
To make sure your copy of Cemu is legit, verify the SHA256 signatures :
Cemu-2.6-x86_64.AppImage 0c20c4aeb800bb13d9bab9474ef45a6f8fcde6402cad9b32ac2a1bbd03186313 (sha256)
cemu-2.6-ubuntu-22.04-x64.zip 5e4592d0dae394fa0614cb8c875eff3f81b23170b349511de318d9caf7215e1b (sha256)
Mostly-bugfix release for v0.12.0
This release fixes a regression in v0.12.0 that caused turbo input mappings to not work properly; in v0.12.0 they behaved the same as non-turbo mappings.
This release also includes changes to where the emulator stores its settings files on Windows. They are now generally stored in a user profile-level directory by default rather than in the emulator directory, so settings will be automatically shared between different copies of the emulator in different directories (it already worked this way on other platforms). It is possible to restore the old Windows behavior if desired, see the full changelog below.
Save states are not compatible with previous versions.
Full changelog:
C:\Users\$NAME\AppData\Local\jgenesis\); other platforms already behaved this way (e.g. generally $HOME/.config/jgenesis/ on Linux)portable.txt file in the emulator directory (contents don't matter, the file just has to exist); this works on all platforms--config command line arg still exists and overrides all of this behavior if it is usedHola gordos jueguito, por temas de la vida en el laburo me dieron un Mac, y estan buenisimas, pero me gusta la emulación y los emuladores que hay para mac son todos horribles, excepto por OpenEmu que crashea cuando le pongo un joystick, solo soporta tres sistemas y encima no se que se supone que tenes que hacer para jugar un juego de play, me embola.
Cuestion, me canse, la IA es grati' y tengo tiempo, asi que hice mi propio front-end, tecnicamente soporta todos los sistemas de libretro (todavia estoy estabilizando algunos), y tiene muchos QoL que ningun otro frontend tiene (hasta donde vi).
- Meter un joystick anda de una
- Te baja las imagenes de una (y con un click podes elegir una de googlea/duckduckgo)
- Cheats automaticos
- Achievements (estoy con eso, no funciona todavia)
- Generos, categorías, busqueda facil
Me diverti muchisimo creando de cero TODOS LOS SHADERS (creo que me quedaron MUY ZARPADOS, el de Game Boy por ejemplo no es una imagen sino que esta di-bu-ja-do en C alrededor de la pantalla.
Cuestion, es open source, gratis, etc, lo hice principalmente para mi, pero me gustaria compartirlo por si a alguno le sirve: https://github.com/JuanchoGithub/truchiemu
This was transcribe from discord encase anyone interested.
Luke Usher
Hi everyone, As the original initiator of Cxbx-Reloaded, I’ll be stepping back into an active ownership role and guiding its development going forward. The project has explored multiple technical directions, and trying to pursue all of them in one codebase is now holding things back.
The mainline project will return to a primarily HLE-driven approach rather than the current hybrid/LLE-heavy direction. This is a deliberate shift.
A snapshot of the current project has been published as: cxbx-reloaded-legacy
https://github.com/Cxbx-Reloaded/cxbx-reloaded-legacy This represents the project as it exists today. It’s open for anyone to maintain, accept PRs, or fork. I won’t be actively maintaining it.
Cxbx-Reloaded will focus on HLE. If you’re interested in LLE or closer-to-hardware behaviour, xemu is already aligned with that direction: https://github.com/xemu-project/xemu
Supporting fundamentally different approaches in one repo has slowed development and lead to us being in a weird place where we are not doing a good job of either path. This split allows us move forward with a clear direction and focus.
If you’re contributing to mainline, please align with this direction. Otherwise, the legacy branch is there. Thanks to everyone who’s contributed so far.