Closed GoogleCodeExporter closed 8 years ago
Have you tried the latest svn?
Original comment by sgorman07@gmail.com
on 27 Apr 2008 at 9:17
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
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
erikharr...@gmail.com
on 27 Apr 2008 at 6:47