carnevil: wrong framerate?

[StormedBubbles]

Hello,

I was playing CarnEvil and noticed a steady framerate of 54 reported by RetroArch during normal gameplay. My hardware appears to struggle with the parts where the jester taunts you and drops into the 40s there, but normal gameplay is smooth and the jester portions only struggle briefly. The arcade database and current MAME have the framerate as 57 for this game, but this repo has it as 54 in the seattle driver:

MACHINE_DRIVER_START( carnevil )
	MDRV_IMPORT_FROM(seattle150)
	MDRV_FRAMES_PER_SECOND(54)
	MDRV_VIDEO_UPDATE(carnevil)
MACHINE_DRIVER_END

Changing the 54 to 57 does indeed increase the framerate, but now RetroArch is reporting ~60FPS during gameplay, which also isn't right. Would anything else need to be changed?

Current MAME also has this in the seattle driver:

void seattle_state::init_carnevil()
{
	init_common(SEATTLE_CONFIG);

	// speedups
	m_maincpu->mips3drc_add_hotspot(0x8015176C, 0x3C03801A, 250); // confirmed
	m_maincpu->mips3drc_add_hotspot(0x80011FBC, 0x8E020018, 250); // confirmed
}

I don't know how this translates to 0.78 syntax and am not sure what it does as a result, and I also don't see a corresponding version of this here.

[mahoneyt944]

Drops are normal for most hardware as this game is very taxing to emulate. So I'm not surprised about that. As far as the fps, that I'm not sure of....though, I wouldn't imagine 54 vs 57 offering much of a difference in terms of actual game play.

[Widge-5]

Wow. a 5% difference sounds pretty significant to me. Certainly different enough for it to be corrected in current MAME where accuracy is king. Unfortunately it's performance in current MAME is terrible for me so I would need to use 2k3+ too.
Assuming that RetroArch's reported framerate is reliable, would changing the value to somewhere between 54 and 57 strike the right balance and get the correct speed during gameplay?

[mahoneyt944]

@Widge-5 you have to realize that this 5% difference is likely to add slowdowns on what's already the most taxing game in the entire core. I'm not sure I see this as a "gain" to see 57 on a frame counter if that means more slowdowns and frame drops. Certainly people can experiment with speeds though to see where that gets them.

On a side bar, I'm not entirely convinced that this game should be 54 or 57. These quote "verified" numbers are being polled from typically one or two random boards, a lot of which were being repaired when these numbers were taken or flat out broken......idk the actual number of cabinets made, but if there were say 2500 cabinets made and a person verified only 1 or 2, that's a small fraction of a percent quote "verified". Unless Midway specifically documented that this game should only ever be at exactly 57, in a time when frame rates weren't all that standardized, it likely varies from cabinet to cabinet a little anyways.

That said, I'm open to update this if someone wants to put in the work, I don't have a platform to test this on that holds 54 fps, let alone 57. So I can't offer much for testing.

[grant2258]

@StormedBubbles changing it to 57 is enough for the fix. The problem is RA itself is pushing 57 to 60 with its default settings. You'll need to to settings->audio->synchronization set maximum timing skew to 0.03. Then restart retroarch you should get the frame rate you set.

There used to be a core option that done this automatically but makes more sense to fix it system wide for other cores. It really should be documented this little thing catches a lot of people out. All the best to you all when new year comes.

@Widge-5 speed wise graphically its livable but the music just sounds too fast and the tone pitch changes that annoys me.

[StormedBubbles]

Thanks for the responses, all.

You've got me on verifying the CarnEvil monitor specs. Discussion in repair forums is among those already somewhat familiar with the specs. The service manual refers to the monitor as a Standard Resolution RGB 25" (63.5cm) CRT (model # 5675-15215-02). If the exact specs needed to determine the intended framerate are there in the manual, then I missed them or just don't understand how to interpret them.

It's been so long since I saw this game in an arcade that I can offer no insight on how things should sound or feel. However, on the performance front, I can offer some results (RetroArch FPS readout given in parentheses).

Raspberry Pi 5 with stock settings and stock driver:
Jester part on first level: starts at about 40 FPS and goes up to 48 FPS before smoothing out at the end
Gameplay: 54 FPS

Raspberry Pi 5 with stock settings and modified driver:
Jester part on first level: starts at about 43 FPS and goes up to 45 FPS before smoothing out at the end
Gameplay: "60" FPS

Raspberry Pi 5 with overclock applied + stock driver:
Jester part on first level: jumps around from 48-52 before smoothing out at the end
Gameplay: 54 FPS

Windows PC with i5 processor and 8 GB RAM + stock driver:
Jester part on first level: drops to 50 and then smooths out at the end

If no issue with the driver, then I'm really curious about what specs would be needed for the Jester part to run at full speed without any hiccups. What I have isn't exactly a gaming computer, but I figure it'd be enough for this 😮. @Widge-5 would have to provide some data on the modified driver with an overclocked Pi 5 because mine is not liking any overclocks at the moment.

@grant2258 is what you described an issue with this core, or is it RetroArch-wide? Current lr-mame displays the emulator-intended full-speed framerate for me in RetroArch even when it's weird things like 44, 54, 57, etc.

[mahoneyt944]

I think it just shows 60, but it's actually 57 from how I understand it. I think the idea was to make these "close but not quite" frame rates appear correct, as many people assume if they see 57 they aren't getting the full rate even if it is. I think they just got tired of explaining that not everything runs at 60.

[grant2258]

@StormedBubbles yes its system wide there are two way to fix it in RA the way I showed you and also by using settings->frame throttle-> sync to exact content framerate. This only happens with non vrr screens. The explanation I was given when I inquired is that RA preferred games ran faster for smoother screen scrolling by design at things using this framerate range in the timing skew.

It is system wide and it really depends on how the core handles the sound. If you force the sound timing to content framerate it wont be an issue, the problem is you need to look at the RA code to figure this out as a core maintainer. This core used to do until the option was turned off by default for some reason, at that point its useless and people might as well adjust the timing skew and would need a explanation of what to do either way.

It just one of RA preferences that smoother gfx in the range that has the effect of making the timing faster. The good news is setting the timing skew wont cause any side effects. Its more a personal preference choice. Im sure there are some people that just need to see 60fps in the counter regardless of the side effects. FBNeo also requires the exact frame rate or audio skew adjusted to fix the issue as well.

[arcadez2003]

Hmm broken and then fixed again in later builds.?? or always broken.?? those are the questions :)

0.155: Phil Bennett fixed missing streaming BGM/Sounds during gameplay in CarnEvil.

Ofcourse fixing the above would likely slow the game down more ha ha

BTW we could easily fixup San Francisco Rush but there is some graft needed.....

14th May 2004: Aaron Giles - The ethernet controller was the missing link in San Francisco Rush, which is now playable (if you have a 20 GHz computer, of course). Unfortunately, there still seems to be something wrong with San Francisco Rush: The Rock, but hopefully I'll have it figured out. On the plus side, it turns out that a missing ethernet controller was also the cause of Vapor TRX not working as well, so now that is playable. By the way, a number of people were wondering why the Vapor TRX CHD is so big. Well, it turns out that the entire attract mode is pre-rendered movies, which explains a lot!

11th May 2004: Aaron Giles - Decided to take a breather from core work and got San Francisco Rush: The Rock up and running. It has the same problems as the original San Francisco Rush in that it hangs at the start of the game, but now I finally have a theory for why. The Rush games included an Ethernet controller onboard, and I'm currently suspicious that they want it to work. I've got some rudimentary basics up and running, and they are detecting that there is no cable connected, and then putting the Ethernet controller into loopback mode. Which tends to reinforce my suspicion that their networking model relies on even local data being sent/received in loopback mode. We'll see once I get everything wired up!

We'd also net Vapor TRX by doin the above i guess it depends on how full our diaries are...:)

[StormedBubbles]

Thanks for the explanations!

Just a curiosity at this point now to see what effect this might have: anyone know of a way to plop this into the mame2003-plus version of the seattle driver? This comes from latest MAME.

void seattle_state::init_carnevil()
{
	init_common(SEATTLE_CONFIG);

	// speedups
	m_maincpu->mips3drc_add_hotspot(0x8015176C, 0x3C03801A, 250); // confirmed
	m_maincpu->mips3drc_add_hotspot(0x80011FBC, 0x8E020018, 250); // confirmed
}

A funny tidbit I found when looking things up for this game: if you choose the haunted house and then pump the shotgun 5 times while the Jester is talking, all of the zombies in the level will either be wearing wigs or hats! That works in this core too. The first few I got when I tried had either Goldilocks pigtail wigs or colonial-type military hats on!

[arcadez2003]

Thanks for the explanations!

Just a curiosity at this point now to see what effect this might have: anyone know of a way to plop this into the mame2003-plus version of the seattle driver? This comes from latest MAME.

void seattle_state::init_carnevil()
{
	init_common(SEATTLE_CONFIG);

	// speedups
	m_maincpu->mips3drc_add_hotspot(0x8015176C, 0x3C03801A, 250); // confirmed
	m_maincpu->mips3drc_add_hotspot(0x80011FBC, 0x8E020018, 250); // confirmed
}

A funny tidbit I found when looking things up for this game: if you choose the haunted house and then pump the shotgun 5 times while the Jester is talking, all of the zombies in the level will either be wearing wigs or hats! That works in this core too. The first few I got when I tried had either Goldilocks pigtail wigs or colonial-type military hats on!

Those speedups are for the later driver they will not just drop in however it seems we have some already...

/* speedups */
install_mem_write32_handler(0, 0x801a2bac, 0x801a2baf, generic_speedup_w);
generic_speedup = &rambase[0x1a2bac/4];

[mahoneyt944]

So what's the consensus here leave at 54 or push to 57?

[arcadez2003]

So what's the consensus here leave at 54 or push to 57?

Well if 57 boosts up the game performance a little and causes no ill effects then why not.

[mahoneyt944]

Well if 57 boosts up the game performance a little and causes no ill effects then why not

I don't have the ability to test this to confirm or deny the change.

[arcadez2003]

Well if 57 boosts up the game performance a little and causes no ill effects then why not

I don't have the ability to test this to confirm or deny the change.

Same here :)

[KMFDManic]

54 to 57 would have greater impact on retropie 4 and up, similarly hardwares. But, changing it to 57 would do the reverse, and make performance worse for retropie 2 relative hardwares. In my personal testing with 2003 xtreme and plus on pi2/3 spec hardware, lower fps equals better performance. Additionally, overclocking works on pi4 and above, whereas you would generally need to underclock to compensate on pi2/3.

So, with that being said, to improve the jester part, which I am well aware of, youd want an appropriate clock speed, along with your fps that best benefits your hardware. And, lastly, turn off audio synch or activate fast forward in retroarch settings, input, hotkey binds, to smooth out the nasty slog that are the jester parts.

This is me running with perimeters I refer to above.

https://youtu.be/18mKscPI0IU?si=ULA8fjd-1XiQ_G93

Ultimately, the best way to handle this is to have whichever options available via core options and or retroarch options (to be handled by the end user for their particular setup). Being that this is a very case scenario, hardware specific contingent, a coding change needs to be very carefully considered, as while you may help pi4, you will most certainly damage integrity for those on abysmal pi2/3s.

Also keep in mind, the way retroarch reports fps can greatly vary compared to true fps. An example of this is turn on retroarch fps as well as pcsx rearmed neon core option fps. They won't normally match. This seems to be fairly common with the discrepancy between reported retroarch and in game via core options. Also, fps will nearly always automatically be inaccurate anytime you use overclock or underclock, especially in conjunction with frameskip.

Hope all is well all of you! It's been a hot minute since we last chatted. Been quite a busy year 2023 with work work work:)