there is a setting to take screenshots preshader IIRC but i have no idea if that leaves out the bezel
4AMās early Macintosh Moof-a-day project is amazing
I would really like these to become supported outside of MAME - still the only emulator that supports them. iād like to update my MacPlus image but faffing with computers in MAME sounds like a major headache lol
GBE+ Dev Shonumi: For those that donāt know (or didnāt click the link lol) the Glucoboy is an extremely rare Australian-only GBA cartridge with a built-in blood glucose meter. It was a very, very late GBA release, coming out on November 14, 2007. The goal was to encourage kids with juvenile diabetes to regularly test themselves, as the Glucoboy rewarded them with points every time they kept their glucose levels in check. The Video Game History Foundation has gotten one and have finally made a full dump!
Itās very different from other forms of video-game related health stuff as it doesnāt really rely on exercise, weight management, calorie counting, etc. More importantly, it was one of the few (only?) times Nintendo gave their approval for a medical-grade device on their system more extensive than a heart rate monitor. There are 2 main games and 3 minigames. Kelsey Lewin did a video about them years ago, so check it out if youāre interested in what it looks like.
In terms of emulation and video game preservation, this is huge. For years, people doubted the Glucoboy was ever commercially released (Bayer swooped in, bought the company behind the Glucoboy, destroyed its unsold stock, and revamped it into a similar product for the DS). Itās one of the last officially licensed GBA cartridges with special hardware that currently remains unemulated. This device, along with the Play-Yan and Campho Advance, are all thatās left before every single piece of (officially licensed and verified to have been released) GBA related hardware is emulated in some form. Hopefully weāll see all of them working in some capacity by the end of the year!
Flycast
Notes to myself I cobbled together yesterday on optimizations or supposed optimizations (I havenāt done comparison testing for all of these) particularly for input lag in the Dreamcast emulator FlycastāIām using the Windows version:
(Have to remember to hit the āDoneā button at the top left of the Settings window to save settings changes!)
-
Video - Delay Frame Swapping
I unchecked it; apparently Flycast Delay Frame Swapping - Cores - Libretro Forums having it on may cause stuttering and āyou only need it enabled when threaded rendering is onā -
Advanced - Other - Multi-threaded emulation
I unchecked it; apparently āthreaded renderingā Threaded rendering adds a frame of input lag Ā· Issue #738 Ā· libretro/flycast Ā· GitHub adds a frame of input delay when enabled, and this was the only setting that seemed like it might be that -
Video - Texture Upscaling - Max Threads
Iām not using texture upscaling anyway (Texture Upscaling set to ā1ā), but this was the only other option seeming to refer to threads, so I changed it from 3 to 1 just in case -
Video - Graphics API - Vulkan
Several sources ( Input lag with Flycast? - Development - Libretro Forums , Help:Flycast GGPO - Mizuumi Wiki for instance ) mention Vulkan as the low-latency option here (the other options are OpenGL, DX9, and DX11, which I think was the default) -
Video - VSync
I unchecked it; was mentioned in documentation http://flycast.dojo.ooo/faq.html#input-latency as the thing to do for minimizing input delay -
limit fps to 59.94
Limiting the emulatorās framerate without using VSync is not a function Flycast has, although the doc was hopeful on adding it some day; recommended doing it via video card settingsāmy Nvidia Control Panel only allows forcing integer frame rates thoughāor Riva Tuner Statistics Server Guru3D RTSS Rivatuner Statistics Server Download 7.3.5 Beta 5 ā I installed it, seems okay
After doing that stuff (didnāt try before), rough comparison testing gave me 5 frames of input delay in Soul Calibur on an actual Dreamcast, vs 3 frames in Flycast.
Two other supposed optimizations I made:
-
In Nvidia Control, 3D Settings - Program Settings, I set flycast.com to
Low Latency Mode = Ultra
Power Management Mode = Prefer Maximum Performance -
In Windows Explorer, I right-clicked flycast.exe, selected Properties, and in the Compatibility tab of the Properties window, checked āDisable fullscreen optimizationsā
Anbernic is having a sale on a bunch of their handhelds til the 18th. Some even ship from the US, I think?
$50 for the RG35XX of is great, as long as youāre willing to put up with a mushy (but easily fixed!) D-Pad. And also knowing theyāre gonna put out a new one (wifi, better shoulder buttons, some other stuff)ā¦probably 6/19, knowing them.
405M sounds fantastic, but I dunno how much Iād be playing Dreamcast/N64/PSP for it to be worth $150. Even the Switch Lite looking one for $120 (same chipset, just a 16:9 screen) feels like too much. Start getting into ājust save for a Steamdeckā territory with those.
This package of DreamShell boot disc (not the DreamShell program, have to download that and put on SD card) plus DC SD Adapter V2
https://www.amazon.com/dp/B09DPFCM9B
shipped for āfreeā from China in 10 days and enabled me to dump the nine Japanese GD-ROMs I wanted to dump.
Used some utilities
And settings mentioned a few posts up with an aim to minimizing input delay.
Ran rough comparison tests. The games had about 2.5 frames less input delay in Flycast than on the actual dreamcast, 1-2 frames less than NEOGEO MVS (KOF 2000), and about 1 frame less delay than MAME 0.255 (arcade versions of SFIII 2nd & 3rd, and KOF 2000):
~ Frames of light punch input lag on my set-up:
Capcom vs. SNK Pro
Dreamcast: 3-4
Flycast: 1
Capcom vs SNK 2
Dreamcast: 3-4
Flycast: 1
Guilty Gear X
Dreamcast: 3
Flycast: 1
JoJoās Bizarre Adventure - Heritage for the Future
Dreamcast: 4
PS3 demo: 3
Flycast: 1-2
Marvel vs. Capcom 2
Dreamcast: 3
PS3: 2-3
Flycast: 1
SoulCalibur
Dreamcast: 4
Flycast widescreen & internal 8K: 2
Flycast: 2
Street Fighter III: 2nd Impact - Giant Attack
Dreamcast: 4
Flycast: 2
MAME: 3
Street Fighter III: 3rd Strike
Dreamcast: 4
Flycast: 1
MAME: 2
The King of Fighters 2000
Dreamcast: 7
NEOGEO: 5
Flycast: 3-4
MAME: 5-6
Easy access to GameFAQs saves has let me get past a few sticking points I had: finally getting the 5 locked character colors in GGX (couldnāt beat Survival : P), and most of the locked cast of JJBA (couldnāt beat Survival except with Alessiās gun spam ; ). : )
Thereās a little emulator jank in CvS Proāmissing character portraits at the end, and some frame dropsābut Iām seeing a whole lot of details Iād never spotted before in those backgrounds. : )
Had to get the DC out again to dump its BIOS with DreamShellāturns out Flycast needs it for playing GGXās music tracks during battles, for some reason. (Redream doesnāt seem to.)
i mean,
for e.g. SNES/Genesis, yeah. point taken
but to be fair if you want better than āgood-enoughā N64 emulation in 2023 you have to do utterly idiotic shit. i spent a few hours trying to set up a up-to-date mupen64plus build (i need to create a proper setup to provide to potential emulator runners in a speedrun game i moderate) with the best plugins and appropriate audio buffering and itās justā¦ an absolute mess. truly disgusting.
the last stable release is from 2019. the nightly builds seem to be almost completely undocumented while also having apparently broken compatibility with various plugins. my friend who was working on this with me in parallel ended up compiling some shit from sourceā¦ i donāt know if that was necessary but i also was not getting shit to work with any consistency whatsoever, sooooo. dunno
AngryLion Plus still randomly crashes on some games - every other graphics plugin largely looks like shit. (Ares looks great, butā¦)
you could use Aresā¦ but only if you have a beef-ass CPU (my i7-8700K chokes on Wave Race 64)
thereās Simple64, but that similarly requires heavy beef. I canāt get a solid 60 VI/s on Excitebike 64 in Simple64, for example.
CEN64 is promising but not ready for prime time. also requires even more beef than Ares.
ParaLLEl N64 and Mupen64Plus-Next have various issues and their exclusivity to RA sinks them for speedrunning as well as anyone who doesnāt want to do the RA maintenance dance
I havenāt wanted to emulate an N64 game since project64 was considered good and most emulation requirements of pre-2000 consoles that require more than an Athlon XP cause me to instinctively cluck and dismiss them
Do you have anything to read on what these might be? I pretty much exclusively use mupen64plus next with the parallel plugins
more off-topic n64 emu ranting
tl;dr, you should be fine, i suspect thatās pretty much the best casual setup for most people. however, if you can run Ares and the game you want to play runs well, iād use that instead. i prefer Ares over basically everything now, just with a caveat that performance can be rough if you arenāt on a high-end CPU.
important: admittedly i could only spend so much time with RA configuration because it ultimately is unsuitable for our purposes. i mainly wanted to check in and see how the state of things were there after banging my head against all the other available options. except for project64, i donāt touch that dumpster fire. leave that one in the dustbin of history, please.
Retroarch is really bad for speedrunning, pretty much directly inverse to how nice it can be for casual play. innumerable inaccurate options that allow for various enhancements and advantages - just to verify everything is configured ācorrectlyā is a nightmare both for the runners and the moderators. trying to effectively verify and moderate speedruns in RA is an absolute no from me and iāll never actively allow it in games i moderate because itās far too much hassle and a constantly-moving target with new enhancements coming often. again - great casually - not great for speedrunning.
this is disgustingly under-documented but far as i have ever been able to tell, RA still defaults to a audio_rate_control_delta value of 0.005. to my understanding, this measures the difference between the vertical refresh and core-supplied timing, and automatically adjusts the core timing to more closely match the vertical refresh (within 0.5% either direction). if you fall within this range and you arenāt a retroarch configuration master, your game will be running up to 0.5% faster or slower - and the audio will played back at a(n admittedly largely imperceptibly) different pitch than intended
as mentioned before, angrylion still crashes some games (i didnāt do extensive repro work, but nothing else in my config changed between GLideN64 (works) and AngryLion (crashes)). not specific to the RA cores, but a major nuisance for every plugin based N64 emulator. WR64 1.0 works, but Shindou (the relevant version for speedrunning) crashes on the N64 logo.
mupen64plus-next has some bizarre perceptible input latency by default (tested on a fresh Retroarch 1.15.0 (hotfixed) install a few days ago). no idea whatās going on there as usually RA is pretty good for input latency, but itās notably worse than simple64 and ares out of the box. runahead is unacceptable for speedrunning, so i need to find the setting thatās fucking this up, if it is indeed a setting.
i also didnāt locate the audio buffer controls for either of the RA N64 cores. iām sure they are exposed somewhere, but retroarch config hell aināt worth it if youāve already categorically ruled it out. default audio buffer is way too large and results in perceptible audio delay. not great for a game with a frame-perfect-at-20-FPS audio-related timing challenge before every race (max power start in WR64)
i didnāt spend much time with parallel as i didnāt seem to be getting full-speed in the intro sequence for WR64 as well as it being a dead-end for speedrunning, so iām sure thereās some more nuance to be uncovered there
if i use any other plugin than angrylion, there are (minor) graphical issues.
Ares is the only emulator with non-angrylion graphics (it doesnāt use plugins at all, afaik) that seems to be pixel-perfectā¦
emulation talk
not that Iām concerned with speedruns and its totally fine to outright disallow it, but retroarch has had an (underdocumented) feature to disable all emulation convenience features like runahead, save states, rewinding, etc.
Turn on āachievementsā in the settings menu, and turn on āhardcore modeā and it automatically disables every problematic setting
as can be seen here
the parallel-rdp is part of mupen64plus-next so thereās absolutely zero reason to ever use the separate parallel-n64 core
imo, of the plugins for n64 emulation, parallel-rdp is straight up an improvement over angrylion
I think there is a lot of misinformation about this, because as far as I can discern from reading the pdf linked in their documentation, dynamic audio rate control has no effect on the timing of the core. It only changes the resampling rate to match the emulation framerate (typically only when using vsync, which I assume you would not want to use in speedruns anyway), so it will possibly cause a ~3 cent difference in pitch but it wonāt change anything about the timing of the emulation. Its purpose is to prevent the audio buffer from underrunning or being full.
Ares itself has this exact feature implemented in the exact same way. Those old reddit guides about getting āperfectly timed video and audioā are not to be trusted.
Anyway, this is all just blather. You might consider giving simple64 a shot, as its a standalone emulator based on m64pn with parallel rdp and rsp plugins built in as the only option, timing altered to bring it in line with ares/cen64 accuracy. Should be less demanding than ares while maintaining the same level of precision.
more n64 emu talk
simple64 is referenced in my posts fleetingly, but my general experience with it is that itās very good out of the box and the main issue is my computer simply isnāt good enough to run it well
re: the audio rate thing - i think youāre right, many thanks for the insight. BUTā¦ even reading that paper iām just utterly baffled. i truly donāt grok why v-sync or monitor refresh are even relevant if all that is being affected is audio sampling. these are just rhetorical questions. all of this is confusing to me on a fundamental level
i havenāt looked into this, but now i wonder if parallel-n64-rdp is usable on non-RA mupen64plus or Simple64? that might be something to look at
ah, upon looking it up, it appears that the ares n64 core is indeed just using an rdp plugin derived from parallel-n64-rdp, so that at least confirms my impression that itās the most accurate of the plugins
parallel-rdp/rsp are included with RMG which is just mupen64-plus with a simple64-esque UI. not as heavy a fork as simple64, so it maintains rough parity with the latest mupen64p updates
simple64 uses parallel-rdp/rsp already
that makes sense - nothing that uses parallel seems to run without hitching or slowing down on my machine - parallel, simple64, and ares were all unable to maintain full-speed for me in the games i was testing
which means iām pretty much back to square one for my purposes ;_;
will try RMG maybe
yeah, Iām not sure any of the standalone emulators have dynarec built in yet, which was a real game changer for me. I think theyāre all using cached interpreter for emulation, which is significantly more hardware-demanding. Iāll test them out and see what I can get working
RMG seems promising
looks like it has GLideN64 as the default video plugin
switched that to parallel and the RSP plugin to parallel RSP
and i seem to be able to get solid performance so far! no hitches in the WR64 intro
i gotta stop messing with this for now because iāve spent far too much time on N64 emulation in the past week and i need to retain some of my sanity, but hopefully this will be a viable option for folks who canāt run Ares or Simple64 at full gait - which iām pretty sure is the majority of people whoād be interested in running on emu
Iām kinda with you on this one. I was able to have a grand time playing Sin annd Punishment on an OG xbox, and feel like itās bad that itās only gotten harder as time has gone by.
Oof, I think I got lucky, all I wanted to play N64-wise was Revenge and No Mercy, and those both ran pretty darn well in Mupen, thankfully.
I did end up trying about a billion alternate sound modules after getting into a discussion about ways to reduce sound popping and lag on a GitHub bug report thread, but none of them really made much difference. So the sound isnāt ideal (I say this not really knowing what itās like on an actual N64) but ah well, it isnāt too bad.