Puggsy (segacd) First Boss is really slow.

EmulatorArchive / genplus-gx

Automatically exported from code.google.com/p/genplus-gx

Other

1 stars 0 forks source link

Puggsy (segacd) First Boss is really slow. #235

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago

Its kind of odd because nothing of heavy action seems to be going on. im not 
sure if the emulator is at fault, or just the wii's lack of power.  but im sure 
it doesnt do that in Kega.

Original issue reported on code.google.com by cheatfreak47 on 5 Jul 2012 at 5:24

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago

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:

cd.zip

GoogleCodeExporter commented 9 years ago

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

Changed state: Accepted
Added labels: Type-Defect, Priority-Medium, SCDEmulation

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago

it works fine in both kega and gens, if that helps

Original comment by cheatfreak47 on 10 Jul 2012 at 6:17

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago

Original comment by ekeeke31@gmail.com on 12 Jul 2012 at 8:32

Changed state: Started

GoogleCodeExporter commented 9 years ago

fixed in r693

Original comment by ekeeke31@gmail.com on 15 Jul 2012 at 3:44

Changed state: Verified