Sega CD savestates should save and load faster

[GoogleCodeExporter]

Actually all savestates are slower to save and load than they should be. It
might not seem like a big deal, but for SegaCD games the savestates can be
one of the biggest bottlenecks for normal emulation, since depending on the
options that are set and which scripts are running, there can easily be
multiple saves and loads happening every frame.

I've gotten it 1.5 to 2 times faster so far by making sure the fast SSE2
copy method gets used for the copy operations whenever possible, reducing
double-copies, and disabling exporting bytes of SRAM and BRAM that aren't
even enabled. I just have to figure out why I can't seem to keep 32x
savestates backward-compatible...

Original issue reported on code.google.com by nitsuja-@hotmail.com on 10 Mar 2009 at 5:45

[GoogleCodeExporter]

Hmm, apparently the 32x issue is unrelated, since even if I revert ALL of my 
changes
and do a full rebuild of exactly what's in SVN, the resulting executable is 
still
unable to load 32x savestates saved by any featured Gens executables.

Original comment by nitsuja-@hotmail.com on 15 Mar 2009 at 8:50

[GoogleCodeExporter]

Yeah, I believe every change we've ever made to core genesis savestates has 
resulted
in a break in backwards compatibility with loading 32X savestates. And I'd be
surprised of something similar isn't true of SegaCD.

Original comment by Upth...@gmail.com on 15 Mar 2009 at 8:55

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

But I haven't even made any changes at all and it's still not compatible. When I
compile Gens11 it can't load 32x savestates saved by your Gens11. Maybe there 
are
some raw pointers unintentionally stored in 32x savestates.

By the way, SegaCD savestates are fine now for backwards compatibility. We can 
and
have changed the size of the core genesis savestates without breaking that. And 
32x
savestates should be the same way, since they use the same method to adjust for 
the
offsets of previous versions.

Original comment by nitsuja-@hotmail.com on 15 Mar 2009 at 10:55

[GoogleCodeExporter]

Damn it, whatever... Anyway, as the 32x thing seems unrelated, I've checked in 
the
faster savestate code.

Original comment by nitsuja-@hotmail.com on 15 Mar 2009 at 11:00

• Changed state: Fixed