Closed GoogleCodeExporter closed 9 years ago
A savestate before the boss would help there too.
Original comment by ekeeke31@gmail.com
on 5 Jul 2012 at 7:04
okay, but all you really have to do is play for about 2 minutes to get there.
whats wierd about it is the boss that comes after it runs a normal speed just
fine.
Original comment by cheatfreak47
on 7 Jul 2012 at 4:29
Still faster for me to use a savestate, i'm not really familiar with that game
so 2 minutes for you might be longer for me.
Original comment by ekeeke31@gmail.com
on 7 Jul 2012 at 8:37
its basicly tutorial then boss, but since i know you are a busy person, here ya
go.
Original comment by cheatfreak47
on 7 Jul 2012 at 4:52
Attachments:
Definitively not an emulation performance issue as it occurs on win32 port as
well and framerate is kept at 50 fps. I suspect a timing issue, maybe interrupt
or something that the game uses for internal synchronization. Still need
investigation.
Original comment by ekeeke31@gmail.com
on 8 Jul 2012 at 8:12
This one is really weird and I could not figured it yet. Seems like the game is
using Sega CD rotation & scaling coprocessor for the boss so maybe it's related
to the timings of gfx operations.
Original comment by ekeeke31@gmail.com
on 9 Jul 2012 at 9:12
it works fine in both kega and gens, if that helps
Original comment by cheatfreak47
on 10 Jul 2012 at 6:17
What is sure is that won't help figuring what the bug is in this emulator, it
would only confirm something's not normal but it was already kinda obvious it
was never meant to be so slow, even on PAL machines. Did you tested ntsc or
pal version btw ? I tested the pal version and it was a little smoother when
forcing VDP mode to 60hz (ntsc) in system settings.
Original comment by ekeeke31@gmail.com
on 10 Jul 2012 at 7:33
i tested the NTSC version, and all sorts of emmulator settings. nothing made it
any faster.
Original comment by cheatfreak47
on 11 Jul 2012 at 6:01
Finally fixed this one as well, this part now runs at correct speed.
For the record, it was caused by CPU register polling detection, which was not
handling BCLR/BSET instructions correctly (this instruction is actually a read
followed by a write and the read would trigger poll detection when it shouldn't
have and hang CPU until the other side CPU writes it again).
Original comment by ekeeke31@gmail.com
on 12 Jul 2012 at 8:30
Original comment by ekeeke31@gmail.com
on 12 Jul 2012 at 8:32
fixed in r693
Original comment by ekeeke31@gmail.com
on 15 Jul 2012 at 3:44
Original issue reported on code.google.com by
cheatfreak47
on 5 Jul 2012 at 5:24