jamieduk / mupen64plus

Automatically exported from code.google.com/p/mupen64plus
1 stars 0 forks source link

Save states usually corrupted #83

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Describe your system:
 - Linux distribution: Ubuntu Hardy Heron
 - Machine type: (32-bit or 64-bit): 32bit
 - Mupen64Plus version: 1.3
 - Plugins used: Any and all

Describe the problem:
I've encountered this problem with multiple ROMs. A majority of the time
the save state generated by mupenplus will be broken - it will load, and
sound will play, but the video will not, and the sound seems to indicate
that the controls are doing nothing.

I have a mupenplus build from revision 183 of the repository. If I attempt
to use r183 binary to load up the save state from the 1.3 version of
mupen64plus, the exact same symptoms occur. 

The r183 version save states with identical ROMs with no trouble.

The r183 save states load fine in 1.3 as well.

Original issue reported on code.google.com by erikharr...@gmail.com on 27 Apr 2008 at 6:47

GoogleCodeExporter commented 9 years ago
Have you tried the latest svn?

Original comment by sgorman07@gmail.com on 27 Apr 2008 at 9:17

GoogleCodeExporter commented 9 years ago
Please give us a detailed description of how to reproduce the problem, include 
the
video plugin and emulator core being used, the rom name and MD5 value, and the 
steps
taken (ie, go to this point, save the game, shutdown and restart emulator, 
reload the
save point).

Original comment by richard...@gmail.com on 27 Apr 2008 at 10:20

GoogleCodeExporter commented 9 years ago
I have not tried latest svn, no.

Emulator core: dynamic recompiler
Video plugins: any of Rice, Glide64, glN64
audio plugins: either mupen64 audio plugin or dummy audio plugin
input plugin: blight's sdl
RSP plugin: the hactarux hle plugin
ROM: I've tested with 

Legend of Zelda Majora's Mask: 2a0a8acb61538235bc1094d297fb6556

Paper Mario: a722f8161ff489943191330bf8416496

Perfect Dark: e03b088b6ac9e0080440efed07c1e40f

Nothing other than saving the state is necessary to cause this bug, but it is
intermittent. I can cause this bug on the intro screen for all three of these 
games,
but it often takes repeatedly saving the state to trip it up.

Original comment by erikharr...@gmail.com on 27 Apr 2008 at 11:43

GoogleCodeExporter commented 9 years ago
Can you please try the latest SVN, maybe the bug was fixed.

Original comment by sgorman07@gmail.com on 28 Apr 2008 at 1:35

GoogleCodeExporter commented 9 years ago
This may or may not be related.

"trunk/memory/tlc.h" defines like so:
unsigned int tlb_LUT_r[0x100000];
unsigned int tlb_LUT_w[0x100000];

Creating two int arrays of 0x100000 elements or 0x400000 bytes, but when the
savestate is written to the disk, only the first 0x100000 bytes are written of 
each
variable:

savestate.c ln 159:
gzwrite(f, tlb_LUT_r, 0x100000);
gzwrite(f, tlb_LUT_w, 0x100000);

Perhaps this could be contributing?  Or perhaps they should be defined 
0x100000/4 ?

Original comment by orbitald...@gmail.com on 4 Jun 2008 at 3:51

GoogleCodeExporter commented 9 years ago
Marking this as invalid; it's over 2 months old and the original reporter has 
not
responded.  It appears that the problem is present in v1.3 but not in later 
versions
(rev 183).

Thanks for the tip orbitaldecay, I have changed the savestate to include the 
full TLB
array and will soon commit this change.  It breaks backwards compatibility with
savestate files.

Original comment by richard...@gmail.com on 6 Jul 2008 at 4:51

GoogleCodeExporter commented 9 years ago
I do hope that you'll include some migration code so that old-format save 
states can
still be loaded but not saved. Some of the games I play don't let you save in 
sane
places.

Original comment by stephan....@gmail.com on 6 Jul 2008 at 5:29

GoogleCodeExporter commented 9 years ago
I wasn't going to include anything in the emulator itself, but I can write a 
small
utility for converting the older savestate files to the new format.

Original comment by richard...@gmail.com on 6 Jul 2008 at 2:32

GoogleCodeExporter commented 9 years ago
Thanks. It's little things like that which add up to make Mupen64Plus my 
favorite 
emulator regardless of OS.

I've tried various others inside Wine and the only thing it doesn't win 
hands-down 
at is overcoming whatever weird tricks Rare uses to make ROMs difficult to run. 
(I 
still have to use Project64 to play Blast Corps and Donkey Kong 64)

Original comment by stephan....@gmail.com on 7 Jul 2008 at 12:30

GoogleCodeExporter commented 9 years ago
I should have commented as soon as asked, but I wasn't in a position to upgrade 
Mupen
at the time of this report.

I no longer have this problem.

Original comment by erikharr...@gmail.com on 7 Jul 2008 at 12:41

GoogleCodeExporter commented 9 years ago
Okay, the savestate bugfix for the problem that orbitaldecay found was 
committed in
rev 758.  It broke backward compatibility, so I have also added a savestate file
conversion tool and instructions on how to use it, in rev 765.

Original comment by richard...@gmail.com on 12 Jul 2008 at 1:55