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:)

[Widge-5]

🤔 Is the Raspberry Pi2 or 3 even remotely capable of running Carnevil at any framerate? I'm not sure anyone using a Pi2 would imagine that they could play Carnevil, so nothing lost. And the video linked states it's running on a Retroid not Pi.
Anyway, the point was made that lower performing hardware might suffer after a framerate correction. In that case I'd agree with @KMFDManic that the most universally ideal solution would be to make the framerate customisable with a core option. That sounds like a lot more work than just swapping digits in the driver though.

[KMFDManic]

🤔 Is the Raspberry Pi2 or 3 even remotely capable of running Carnevil at any framerate? I'm not sure anyone using a Pi2 would imagine that they could play Carnevil, so nothing lost. And the video linked states it's running on a Retroid not Pi.
Anyway, the point was made that lower performing hardware might suffer after a framerate correction. In that case I'd agree with @KMFDManic that the most universally ideal solution would be to make the framerate customisable with a core option. That sounds like a lot more work than just swapping digits in the driver though.

Actually, it was just an example retroid wise. But, yes, with the right combination of core settings and such, Carnevil does work on a pi2/3. I actually played around quite a bit with that game in particular. And, that Jester bit always made retests sooooo much more fun, haha.

I can pretty much confirm, at least from my personal tests on nearly a dozen test platforms that I've done custom cores of 2003 on, Carnevil definitely varies quite a bit when going on the teeter totter spectrum of low-mid to high spec.

That is actually one specific reason you will now notice the "fairly new" core option that I suggested we add into 2003 plus awhile back, cpu clock control:) Carnevil was actually, along with Killer Instinct, 2 of the primary reasons I most wanted that as a core option.

[mahoneyt944]

@KMFDManic interesting point, I wonder if changing the current core option "CPU Clock Scale" has any effect on this. Maybe try changing it from default to 105% or something to see if it's possible to frame boost past 54 fps.

[KMFDManic]

@KMFDManic interesting point, I wonder if changing the current core option "CPU Clock Scale" has any effect on this. Maybe try changing it from default to 105% or something to see if it's possible to frame boost past 54 fps. Really unsure.

It actually does. Same scenario, higher specs can overclock, lower specs can underclock. I've tried many factors in my various tests. That was a tremendous reason I wanted the cpu control. Hell, if you linked up the other cpu controls, including the audio ones, at some point, you'd have even more advantage as far as overall malleability. But, we're in a very nice spot for the time being.

Aside from the jester portions, once in game, action stage wise, I have been able to run Carnevil decently enough to be enjoyable.

They really need to rerelease the game at some point on next gen. Yer another classic lost in time.

[StormedBubbles]

I can vouch for the secondary / audio CPU controls positively affecting performance on weak hardware. That's one way to make the arcade version of Point Blank 3 playable in current MAME on a Raspberry Pi 4, for example. I don't think that any of the mainstream Libretro MAME ports expose those secondary options as core options and instead rely on activating cheats and going into the sliders menu instead. Those options don't save unless you make a save state.

I will have to experiment with those secondary options if they exist in this core. I didn't think of that.

[KMFDManic]

@StormedBubbles the secondary and on cpu controls, do not exist in the core options and are otherwise not easily accessible. They'd need tethered in, which @grant2258 initially helped implement.

But, yeah, games like deathsmiles, before fbneo had fix ups, I'd for sure be manipulating the cpu controls, all 3-4 of them, heh. They also work amazingly well with sprucing up Philip's cd-i games on mess and current mame on my lower specs.

[StormedBubbles]

@KMFDManic How do you get to those additional CPU controls in this core? I took a quick glance but didn't find them in the tab menu.

Quick aside on this seattle driver: I tried out the NFL Blitz games just to compare CarnEvil with something else from the same driver. The sound pitch is way too high for blitz99 and blitz2k. Looks like that was fixed in MAME 0.81. The Blitz games also appear to be A LOT more resource intensive than CarnEvil :/

[KMFDManic]

@KMFDManic How do you get to those additional CPU controls in this core? I took a quick glance but didn't find them in the tab menu.

Quick aside on this seattle driver: I tried out the NFL Blitz games just to compare CarnEvil with something else from the same driver. The sound pitch is way too high for blitz99 and blitz2k. Looks like that was fixed in MAME 0.81. The Blitz games also appear to be A LOT more resource intensive than CarnEvil :/

That was what I referred to in my last response, that they weren't available without tethering as a core option. It would need exposed so we could access it via core option like the cpu clock scale was.

[grant2258]

Well it would be nice to add the underclock/overclock for all cpus. I dont touch retroarch/libretro code only actually emulation code now. I Can look at your core @KMFDManic if more work needs done on this let me know. @mahoneyt944 can always backport it he sees it as something useful. I think he is the only person I know atm that willing to do anything on the libretro api end on this core.

[mahoneyt944]

Surely willing to help but with a new baby I've been pre occupied. Lol.

[grant2258]

I hear you there on the new baby the other halfs youngest daughter just had baby on december. Sleepless nights ahead for you!bud. There really is no rush anyway if any work needs done itll be on @KMFDManics repo.

[arcadez2003]

Surely willing to help but with a new baby I've been pre occupied. Lol.

Bang goes your nights out for the next 5 years or so LOL

[KMFDManic]

@mahoneyt944 @arcadez2003 @StormedBubbles @grant2258 Due to previous testing, as mentioned, with the various CPU controls...I did some testing with 2003 Plus, particularly with Carnevil, Virtua Racing, Taito F3 games. I had success in "more reasonably" running all of the above on the pesky low spec Mini Classics.

I am very intrigued by the implementation, at all, of Virtua Racing...Once I manipulated things a bit, it became quite fun and playable. You CAN get 1st place, but have a very very small window to do so! Gotta love those spin-outs the AI throws at you, haha. I will drop a video showcase of me running Virtua Racing considerably better than it "accurately" is supposed to run, emulation wise:)

Carnevil, once I manipulated the alternate cpu controls hard code wise, I was able to boot the game 5 minutes faster (used to take nearly 10 minutes to even get in game!), and run it at around 18-24 FPS, on a 1.008 Ghz platform. Seattle Hardware games have never been very feasible for lower spec. But, I tend to be a masochist in attempting to at least get them to run, regardless..!

In any case, I will drop a video on Virtua Racing.

The primary thing and reason other "Cores" seem to avoid the cpu manipulation controls is simply due to the fact that it creates a much more unstable environment, as well as mucks about with pitch of sound, as well as overall authenticity of the game/s' emulations. But, this is one reason I love Xtreme/Plus, more open minded, stance wise, on the more questionable entries, within reason!

@mahoneyt944 congrats on the baby. Just think, in a few years, they will be able to enjoy "stopping on a dime", precision controls with Food Fight, amongst other fun stuff. Not to mention, you can introduce them to some good music, tv shows, movies, etc! With what I already know, in my dealings with you, they will turn out more than just alright:)

[StormedBubbles]

@KMFDManic Can you point me to the spots in the code where you manipulated those alternate CPU options for CarnEvil? I am curious about the effects and could also probably help on the Libretro side because I have some familiarity with how the core options work.

[KMFDManic]

@arcadez2003 @StormedBubbles @grant2258 @mahoneyt944

This is with manipulated cpu control changes, as this particular game was quite sluggish, otherwise, on the Mini Classics.

https://www.youtube.com/watch?v=VUAUXonGTxM

@StormedBubbles You still happen to use Discord? We can go over a few things and try to fix things up together, if you wish, and get some tests in. We did great, last time we chatted there! All in all, however, you will for sure want the additional CPU tied in! Doing so via drivers is quite tedious! Whereas, you can get near instant test results with "slider" values. Let me know if you still use Discord:)

[StormedBubbles]

Yes, feel free to drop me a line on Discord.

[KMFDManic]

@StormedBubbles You can see info about the original implementation for Clock Scale, based on my suggestion to help Killer Instinct. You can also message me under same name on Discord, kmfdmanic, anytime you wanna go over anything.

#1100

@grant2258 If you are able to tie in CPU1 and such, be sure to let me know. The Xtreme 2003 MAME Repo is good game for guinea pig testing, hehe. My Virtua Racing Video was altering CPU1, not CPU0. So, you can see that it absolutely works. Same held true for Carnevil, aside from the pesky Jester portions, haha. Typically, when I would manipulate CPU0 (Video) and CPU1 (Audio), for games like Deathsmiles, you could only go so far with Video, before you get frame break foolery, in any direction. But, CPU1, and so on, would allow me additional room for performance/speed gain, due to mucking about with the accuracy.

I've definitely done enough tests to feasibly say it is a welcome addition for non-purists. And, yes, you can also dial things back a bit, so it is closer to the true experience. While I ran Virtua Racing faster than I needed to, in another test today, I manipulated the CPU1 to be closer to home, and still maintained a nice performance gain. I tested it with cheats, to confirm I could actually beat the levels. Stage 1, you get sucked into the pit first 2 laps, then final 3 laps are normal. You lose nearly 15 seconds for each pit stop! I will do another test to beat stage 2 next, then 3:) But, 1 is fully playable, at least, with cheats, and/or near perfect skill!

[mahoneyt944]

Are we leaving this open? Have we found an alternative direction to go with?

[KMFDManic]

Might be worth seeing if we can pinpoint the mips drc speedup hotfix outlined in the initial post, that is in later mame and see if it is even compatible with 2003 code. This may possibly help with the jester parts, for all we know.

As far as fps, that may be a little trickier to establish as an absolute, being the coding has changed between 2003 and newer source. The hotfix may have an impact, however. Guess, try to rule it out before closing this.

[mahoneyt944]

As arcadez pointed out we have some speedups already, curious if these are different or just another modified from the new code.

[KMFDManic]

Seems that you can create carnevil.ini in later mame, with the following perimeters:

syncrefresh 0
waitvsync 1

To apparently fix frame rate instabilities. Interesting. I know Seattle hardware games have always been a thorn in my side:)

[mahoneyt944]

We'd probably just hardcode in the values or make it a core option if applicable

[KMFDManic]

We'd probably just hardcode in the values or make it a core option if applicable

Some of the .ini values are quite useful for stuff like MESS/MAME, Phillips cd-I games and more intensive games and such. That might not be a bad idea to expose or implement these as core options or hard code good results if viable to. It can sometimes be night and day difference on the most troublesome games.

Taito F3 would likely benefit from this sort of addition on lower spec.

[mahoneyt944]

Yeah or perhaps as a fake dip switch. Might be more appropriate if they are very game specific

[KMFDManic]

Yeah or perhaps as a fake dip switch. Might be more appropriate if they are very game specific

That's a novel idea, too. Anything that can enhance or improve some of these games is a worthy addition.

[arcadez2003]

As arcadez pointed out we have some speedups already, curious if these are different or just another modified from the new code.

I noticed two speedup addresses as shown above whereas we only have one for CarnEvil that might either be due
to a dev pinning down another address range for the game or just how the code for these is handled in later MAME.

// CarnEvil speedups

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

This core

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

sfrush double speedups

/* speedups */
install_mem_read32_handler(0, 0x8012498c, 0x8012498f, generic_speedup_r);
generic_speedup = &rambase[0x12498c/4];
install_mem_read32_handler(0, 0x80120000, 0x80120003, generic_speedup2_r);
generic_speedup2 = &rambase[0x120000/4];

Certainly some other games in our driver have two speedup addresses so maybe CarnEvil would benefit from using
the other one.??

[StormedBubbles]

Seems that you can create carnevil.ini in later mame, with the following perimeters:

syncrefresh 0
waitvsync 1

To apparently fix frame rate instabilities. Interesting. I know Seattle hardware games have always been a thorn in my side:)

These exact terms don't appear when searching in the code here. Do you happen to know if there is an equivalent in this version of MAME? I can give some testing feedback after manually tweaking those in the code if there is a spot to do so. Are ini files even a thing with this version of MAME?

[KMFDManic]

@StormedBubbles These were implemented, as well as the .ini format, into later MAME. It would possibly take some work here, which was why @mahoneyt944 and I were chatting about the possibility of Core Option/Fake Dip Switches. For the OSD, CPU Clock control, for example. I really wanted that, because the MAME Menu makes it much more difficult to access and manipulate that factor in 2003 code set.

As far as the syncrefresh, what you can try..for now. In RetroArch Settings, Video, Output, toggle off Vsync. While this will introduce potential screen tearing, you should fly right by the Jester Parts. Also, note if the FPS changes with Vsync off. This is one duct tape workaround for some games that have wildly fluctuating FPS. Let me know how that test turns out.

Also, off topic a little...again, for you StormedBubbles, The FCEUMM Repo for me, take a quick peek at the commit I added for Power Pad w/controller games. I found it much more convenient, and can now run a majority of Power Pad games with just a controller.

Be sure to let me know how Carnevil test turns out!

@arcadez2003 good find on Carnevil. I'd love to see if the "other" speedup helps:) Damn the slowdown Jester!

Otherwise, for now..I say we keep this one open. This exact issue can be a gateway to fixing similar problem games on other drivers. I feel fixing Carnevil up will be a key factor in opening up more avenues to play around with in this particular MAME code set:) I am currently fixing up Hard Drivin', and was able to boost performance and speed in that particular game, using some of what we were chatting about. So, this is pretty nice:)

[StormedBubbles]

I will take a more detailed look in the next couple of days and give more exact info, but after a quick glance at the jester part with vsync off, there wasn't any clear difference to me than with it on. Is there any other setting within RetroArch I should be checking to go along with that? The video seemed okay too. I didn't notice any obvious tearing.

[StormedBubbles]

More detail (Raspberry Pi 5):

I tested the jester part for the Haunted House (first level) a handful of times. The difference between vsync on and off appears to be minimal, and the speed drop doesn't even seem to be consistent across sessions. It's always somewhere in the 81-89% speed range (judging by RA's FPS counter) when the jester mentions something about losing your head regardless of vsync being on or off for me.

[KMFDManic]

More detail (Raspberry Pi 5):

I tested the jester part for the Haunted House (first level) a handful of times. The difference between vsync on and off appears to be minimal, and the speed drop doesn't even seem to be consistent across sessions. It's always somewhere in the 81-89% speed range (judging by RA's FPS counter) when the jester mentions something about losing your head regardless of vsync being on or off for me.

Have you, for kicks, also tried toggling audio synch off? I did a few tests with fixing up the Jester portions. But, it greatly reduces accuracy and would not really benefit mainline 2003 for stability purposes. To retain accuracy in this case, Carnevil needs quite powerful hardware. My PC runs the game absolutely fine using current 2003 plus. So, it unfortunately is a limitation of other platforms trying to keep up with its steep system requirements.

You can shoot me a message on Discord, again, under kmfdmanic, and I can try to help you with some test builds.

[StormedBubbles]

Sorry, I forgot to post an update about this earlier.

My default settings are vsync and audio sync both on. The jester part causes some slowdowns but then recovers by the end of his spiel.

With vsync off but audio sync on, I don't see an obvious difference.

With vsync on but audio sync off, performance actually seems a little worse with choppy audio.

With vsync and audio sync both off, the game plays in fast forward other than some brief slowdowns at the same jester part.

This was with a Raspberry Pi 5 and a Microsoft Surface computer.

On the other hand, a friend tried CarnEvil with this core with a considerably more powerful computer and experienced zero slowdowns. So that's that I guess with the slowdown issue. I just have to see if a stable overclock can help me out. I don't really want to compromise the gameplay for what is a minor issue.

As for the framerate, I can't make any definitive statements on what it should be.

[mahoneyt944]

I'm not sure if we want to keep this open or not. Seems like we are preserving the 54 frames per second for performance purposes? In this case, maybe an alternative would be a core option to override the frames per second so it could be over or under clocked experimentally for this or any other game.

[KMFDManic]

@mahoneyt944 If we actually "could" do a Core Option for say, "Target FPS", that actually would be pretty nice. Lower Specs could Target FPS to 20-30 FPS, Higher Specs could shoot for straight up 60 FPS, and so on. And, realistically speaking, if you couldn't do it globally, you'd really only need to do it for drivers, like Seattle/Killer Instinct, etc, which are amongst the absolute most difficult to run well on Lower Spec. But, of course, mucking about with FPS thresholds could potentially lead to display issues. Only testing would know for sure. I did actually test a few different FPS hard code wise with Carnevil to try to improve it on the Classics, and had success there with "faster gameplay". But, there are likely going to be variables that won't work properly.

Another thing I've exploited a bit with some Cores is how differently NTSC and PAL games function. 50/60 FPS differentials on PAL games for NES, for example, can work in a negative way, making PAL games difficult to play, unless you use a Core Option for the respective Core to properly handle the PAL game. Whereas, if you run a game that might struggle, N64 wise, with the NTSC version, running the PAL version will generally give you a speed and performance boost.

If we could actually force FPS, as in "Target FPS", or just force PAL or NTSC, as in 50 Hz or 60 Hz, that might be sufficient enough to cover the bases to help on Carnevil. 50 FPS or 60 FPS target. But, if 20-30 worked, that would definitely make a difference on the lower specs, especially with that awful loading sequence. If there was any game I'd ever want to do a rom hack of, it would be Carnevil, to completely remove the load clown portions, which always take a good 2-3 minutes at least, on the Classics. But, once IN GAME, I can actually reasonably play the levels!!!

Carnevil has always been, and still is my favorite on rails shooter game. There has just always been a certain allure to it that has kept its appeal for me over the years. While I love House of the Dead, etc, Carnevil is the gem for me:)