http://www.exodusemulator.com/
From what I can glean from the site, looks like a Genesis/Mega Drive emulator with the same design philosophy as bsnes was for Super Nintendo - accuracy over everything. I'd say this will be worth investigating to use for TASing purposes in the future. And it's about time too :-)
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Released doesn't mean it can be edited. Nemesis has some completely mad licensing ideas. Then, it is absurdly slow, and x64 only. That's an unfair cost for being only slightly better than Genesis+GX.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
For starters, there is evidence that Nemesis has come around as far as licensing goes. As for the performance, Nemesis has posted this two days ago:
Nemesis wrote:
What consisted this internal change?
Complete restructure of how debug windows are implemented and managed, expansion of the abilities of extension plugins, and better separation between the emulation platform itself and the GUI. This model gives better separation between components and make everything more extensible.
Will the next release be improved in term of speed?
Yes, in a major way! I've heavily profiled and aggressively optimized the major bottlenecks in the emulator, as well as restructuring some critical areas of the bus system to reduce overhead. I've also made some critical improvements to the threading model which give a significant performance boost, the effects of which are magnified on dual-core systems. Here are some comparisons I just took between the 1.0 release version of Exodus and the current Exodus 1.1 development build:
That's an average 40% memory usage decrease, with a 90% performance increase for the Core 2 E7400, a 40% performance increase for the i7 920, and a 30% performance increase for the i7 3840QM. These ratings were taken on Sonic 2 using the first level for comparison. Note that this makes what is a 6 year old processor be able to run Sonic 2 (one of the more demanding Mega Drive games) at 85FPS. It might also be possible for a dual-core system to achieve a full framerate too. The E7400 gets 83% of full framerate. The Core 2 Duo E8600 might be up to the task. At the very least, it's now usable on a dual-core system for development and debugging.
These numbers may change before release. I've got another critical change to the bus system that could introduce more overhead, but it's important in order to be able to make it flexible enough to apply to all systems.
As for "slightly better" emulation, I can't comment much; Exodus will be much more accurate (Nemesis is using several detailed documents which he obtained and hasn't released yet), but for how long remains to be seen (as it is likely that many emulation improvements can simply be ported over to Gens+GX).
It can't, otherwise you'll get same slow speed.
Exodus 1.0 for all MD hardware part create its own thread = ~12 threads
Each now and then sync them, that's why it's very slow.
In Exodus 1.1 only Nemesis knows what was changed.
but still 50fps on Core 2 E7400 (2.8GHz dual core)
it's slow.
Also, 28fps ->50fps it's only 2 times faster, seems like nothing changed (only optimized)
Nemesis has stated in the past that 1.1 has a micro-opcode accurate 68k core and correctly emulates bus access timings; I would think that these results already account for that, but it isn't explicit.
Let me ccorrect myself here: Nemesis was working on a microcode-accurate 68k core, but due to issues with available free time, decided to leave it for after Exodus is open sourced, and is working on getting 1.1 out of the door first. So those numbers are for the old 68k core.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Now all it needs is a Linux version (so we don't have to deal with Wine*) and a rerecording fork.
* = It runs on Wine, but it hangs on a critical section after some time.
Edit: Oh, and here is the license.
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Having understood nothing from that text, can it be forked?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Found it: it is the MS-RL, a license approved by the OSI. It is a copyleft license, but a weak copyleft license; it is not compatible with GPL or other strong copyleft licenses, but it is compatible with more weak copyleft and permissive licenses, which can even co-exist in the same code base.
In particular, yes, it can be forked: Nemesis can only control his own version of the code, which he is doing by making contributors submit pull requests instead of giving write permissions to the repository. The existing files cannot be re-licensed unless all authors agree on it (at this point, Nemesis), but new files can be in any compatible license.
