search

libretro / Genesis-Plus-GX

An enhanced port of Genesis Plus - accurate & portable Sega 8/16 bit emulator
Other
76 stars 72 forks source link

Slowdown in Sega CD games #192

Open OldsXCool opened 5 years ago

OldsXCool commented 5 years ago

I have 4 computers all with very different hardware configurations and all but one of them run Windows 7 with the one running 8.1. On all of them I've noticed that Sega CD emulation has slowdown in games that is not present in real hardware. A good example is the first stage in Battle Corps. The slowdown is crippling and renders the game almost unplayable. I've tried to overclock the emulator in the menu and it has absolutely no effect on the issue. I currently use Kega Fusion or Pico Drive if I'm using Retroarch for Sega CD and these two emulators play the games at the correct speed with slowdowns that are expected and present in real hardware. It's weird that I have not seen this mentioned anywhere as Sonic CD also suffers from the same issue. I know that Sonic CD does have alot of slowdown but it is excessive in Genesis Plus. I'd love to use Genesis Plus exclusively as it does an amazing job with cartridge based games and not have to rely on Kega Fusion as it's kind of a small pain to deal with on Windows 8.1 and Pico drive is not as accurate.

ToniBC commented 4 years ago

Nobody comments anything because I think it is not a mistake, I tried the game Battle Corps in GenesisGX and Kega and both are the same, I do not notice that it is unplayable.

When errors are reported, it is best to document the error well, with a video for example.

I guess that's what I told you, nobody says anything because we don't see anything weird. Always remember to update Retroarch and cores. Another thing is to delete the configuration or unzip it in another folder to see if you touched any option that affects the game.

Sanaki commented 4 years ago

I'd say Sewer Shark is a good example. The whole game is video. I played revision 1 recently (didn't try unrevised) and without 125% CPU overclock it chugs hard. At 125% you still get some seemingly speed-related rubberbanding after the first recharge station as well, and sporadically otherwise, but it's at least playable.

Granted, this may be more fitting for #186, but the two issues may be the same as well.

FeRcHuLeS commented 4 years ago

It is maybe related to Latency--> Run-ahead is on just turn it off.

ekeeke commented 4 years ago

The issue with Sewer Shark is likely caused by the CD image file you are using. There are indeed two NTSC-U versions of this game:

It appears that the original version has stuttering issue in Sega CD emulators but also on real hardware so it seems that version is simply bugged or badly programmed (not sure if this applies to both Sega CD models or only Sega CD 2 but using 1.00 or 1.10 BIOS in emulators does not fix it).

The bundle version works fine in Genesis Plus GX (and other emulators) and appears to be a fixed version.

More infos on this: https://github.com/MiSTer-devel/MegaCD_MiSTer/issues/33 https://mobile.twitter.com/krikzz/status/1276105204996493312

Sanaki commented 4 years ago

Huh... thanks for the info. Was not aware.

krikzz commented 4 years ago

Seems like Sewer Shark glitches related to cdd cmd 0xA ("track jump" or whatever it called) From what i know only CDX bios uses this command and only with CDX bios older version of Sewer Shark may work without problems. Still not sure if all cdd controllers has the same firmware and if they all can handle this command properly.

ekeeke commented 4 years ago

@krikzz : Interesting, thanks for the notice. So you mean the initial version of this game is bypassing the BIOS and is directly sending 0xA commands to CDD hardware ? I have already seen this command sent in a few games before sending PLAY commands but I thought it was some undocumented BIOS command that was there in all BIOS. This command is used to jump 'tracks' (physical ones that are running in spiral accross the disc, not digital tracks) to reduce seek time but is currently not emulated so I guess the stuttering issues in emulator or FPGA implementation with this game first version is caused by calculated seek time being too large (disabling seek time emulation or adjusting it when 0xA command is set would probably fix that issue). It's possible that this command is not supported or is broken in Sega CD 2 CDD controller firmware or maybe is less effective with Sega CD 2 drive, which would explain the similar issues on Sega CD 2 hardware and why they released a fixed version. Also, maybe this was fixed later in CDX hardware if you say that command is used by CDX BIOS

krikzz commented 4 years ago

I do not think that game send 0xA directly, but CDX bios uses this command constantly. CD2 seems not used 0xA at all, at least i didn't seen it in logs. With CDX bios game works fine on MCD2 and CDX itself, but with MCD2 bios game glitched on both. So my assumption that it can be related to 0xA cmd I did not checked yet how it works with MCD1 bios. It should work somehow on early hardware, right? Or it would be too weird if they released so buggy game before than cdx come to the market.