BizHawk
BizHawk copied to clipboard
TASEmulators
Adobe Flash core
Latest gnash seems to work fine with flash 9 games. Other flash players I've seen are either closed source or too bad.
It can be TASed in libTAS. Here are the links to what @greysondn has modified to make the sdl version work with libTAS.
And here's what was forked: https://github.com/strk/gnash
edit: For future humans, there has been some success with Ruffle in libTAS, see this forum thread.
~~Adobe has announced they're killing Flash on Jan 1st. Hoo-ray. I could have sworn they made a similar promise not too long ago...~~ My cynicism was misplaced. RIP Flash.
Anyway here's another emu to keep an eye on: Ruffle (repo). Rust is a plus, and it looks like the architecture is segregated enough for our purposes. It's currently able to run some flashes that only use the simplest features. Newgrounds is paying them so I expect the project to grow quickly (edit: they also have the support of the Internet Archive).
~~see also clementgallet/libTAS#365~~ resolved
~~I've added Ruffle (and Lightspark, which its wiki made me aware of) to the Future core candidates snippet on GitLab. I've left Gnash there because it's the de facto standard of Free Software, even though it's apparently dead with no maintainers. I guess the GNOME guys grew bored of it?~~ Removed that, but for posterity: Gnash, Lightspark
Here are the links to what @greysondn has modified to make the sdl version work with libTAS.
I feel like I should make this a bit clearer.
I modified exactly nothing in Gnash-SDL itself.
What happened was this: Ubuntu's package repos were functionally lying about what was shipped. The SDL version of Gnash wasn't being shipped at all, but documentation and provides tags were set for it. Why they'd do this is beyond me.
The package I provided literally just builds SDL Gnash, plus a single compat setting so that documentation is registered with manpages. Nothing was necessary to change in the code of SDL Gnash itself.
tl;dr - I provided a package and the recipe for it because the Ubuntu package maintainers did a dumb; I did not change anything in SDL Gnash itself.
gnash seems to just be abadononed at this point, so that can probably be considered off the table. Ruffle and Lightspark are still getting updates. Lightspark seems to be OpenGL reliant (and likes to have a lot of threads), Ruffle is similarly reliant on GPU usage (able to use multiple backends but doesn't have a true pure software renderer, Canvas API not counting here). Ruffle seems to rarely use threads anyways (mostly only for audio?)
Ruffle doesn't have savestates anyways, and Lightspark doesn't seem to have states either. And of course the reliance on GPUs means these can't be waterboxed, so having a Flash core is probably blocked until either implements a software renderer (Ruffle does mention on its roadmap that a pure software renderer might be implemented), or maybe one of them puts together savestates.
Also Ruffle is Rust and Rust code can't be waterboxed with the current waterboxing setup. I imagine it wouldn't be so hard though to get a waterboxing Rust setup? Moot until Ruffle implements a software renderer anyways.
gnash seems to just be abandoned at this point, so that can probably be considered off the table.
Worth pointing out that Gnash grinding to a halt doesn't magically mean Gnash is bad. It's still often used as a fallback Flash interpreter and may be the only option for certain types of legacy content (an actual expert would have to weigh in).
Accuracy would have to be checked. So would outstanding (known) issues in the codebase.
If gnash had a pure software renderer it would be considerable, but looking at the code it doesn't appear to have such, and being abandoned means it will never have such.
Is there a reason the SDL renderer doesn't work here?
Clarification: SDL supports software rendering. I'm not sure if the code has to be written specifically to use it, it's just a compile flag, or "whatever other way".
It could work. However, in a waterboxing setup there is no dynamic linking (for the guest), and of course obvious ABI differences with native libraries and waterbox ones. SDL itself would have to be compiled with the waterbox setup and then statically linked together. Which then becomes the question of can you waterbox SDL itself (who knows how easy that is).