Mazan: Flash of the Blade (Naomi)

ChaosEffect

@pjft I don't think that that older version of lr-flycast is maintained anymore. The code base was moved to the upstream GitHub repository I linked earlier, and the older version was left unchanged (I think because some lower-powered platforms like Raspberry Pi benefit from it). However, Mazan behaves the same way in upstream lr-flycast, so any changes could probably be submitted there.

I calibrated in both the vanilla old lr-flycast and your branch, and I think the experience was better after using the calibration from the vanilla version.

Is it possible to separate the "Start" function from the "chop/stab" action? Currently, in your branch, they are both mapped to "Gun Aux A." If it's possible to separate the two, I think the Start function should be mapped to "Gun Start," while the chop should remain at "Gun Aux A."

Ninja Assault behaves the same way in your branch as it does in the current version of the old lr-flycast. The mappings are:

P1 Trigger = Gun Aux A
P1 Start = Gun Aux B

Upstream lr-flycast moves those functions to "Gun Trigger" and "Gun Start" for both players. The P1 Coin function is mapped to "Gun Select" in all versions, and there appears to be no P2 Coin function in any version of the emulator.

There is no P2 Start button at all in vanilla old lr-flycast or your branch.

pjft

@chaoseffect I see.

I don't really know much about the button mapping - the changes I made were based on the button mapping that the game had in the emulator, I did not change anything there. Thanks for the feedback on the calibration not yielding the same results - that's too bad.

As I said, I really stopped looking into this back in late 2020, so I don't really envision going back to this anytime soon - especially with the codebase being different. I could consider submitting the current code for approval - adapting it to the new codebase, of course - but if it would still benefit from some changes I'd probably hold off on that until I get some time and focus on this again and make some of those adjustments.

Still, I hope this at least helps you and others enjoy the game a bit better for now!

ChaosEffect

@pjft Your branch definitely makes the experience better. Thanks so much! Sinden users can block attacks in your branch 😃

Among "old" lr-flycast, your branch, and "new/upstream" lr-flycast, it seems that all lightgun and lightgun-like games are supported now, one way or another. Extreme Hunting 2 fails to load due to a network-board issue, but that can be circumvented by using the conversion to Dreamcast that someone recently made. That Virtua Cop 2 issue seems to be the only thing hindering the playability of any true lightgun game.

pjft

@chaoseffect Sounds good. I may have a look at the Virtua Cop 2 issue, just out of curiosity at some point. I wouldn't consider myself more knowledgeable about this than flyinghead or any of the RetroArch folks, though, so... :)

To confirm:

It happens on lr-flycast with a lightgun (actual device, or even when using a mouse and selecting "Lightgun" as RetroArch input?);
it doesn't happen on vanilla flycast (can we install it on the Pi? Is it installable via RetroPie-Setup?)

Just so I can hone in on the specifics when I look into it.

Thanks!

mitu

@pjft said in Mazan: Flash of the Blade (Naomi):

it doesn't happen on vanilla flycast (can we install it on the Pi? Is it installable via RetroPie-Setup?)

It can be installed, but it's not part of RetroPie-Setup yet.

ChaosEffect

@pjft First, you will need to install lr-flycast (upstream) separately from the old lr-flycast by using this script.

On my system, I changed all references of "lr-flycast" to "lr-flycast-new" in the linked script so that the two versions can co-exist.

Here are the things I have confirmed with Virtua Cop 2 in "lr-flycast-new" on a Raspberry Pi 4B:

The game will freeze briefly on any trigger pull by a player whose control type is set to "Lightgun."
The freeze occurs regardless of whether it's a Sinden gun or a regular mouse, so it does not appear to be a hardware problem
When the control type is set to "Controller," the freeze does not occur for that player's trigger pulls. I tested with one player using a lightgun and the other using a controller. Only the lightgun player's trigger pulls cause the freeze

And here are some things that I have heard but have not confirmed myself:

The issue does NOT occur in the current version of the standalone (non-libretro) Flycast
The issue DOES occur in "lr-flycast-new" on non-pi platforms

pjft

@chaoseffect ok, so yeah. I can replicate it - as expected. It was not what my original hypothesis was going to suggest. Since the behavior reminded me of a similar stuttering caused by the vibration effects on lr-pcsx-rearmed back in the day, I kind of hoped it could be something simple as that. Alas, disabling vibration in the options, and in the core options, made no difference whatsoever.

Did you try changing some of the weirder core options to see if they're making a difference on this?

I suppose I'll have to spend more time here, but don't hold your hopes. I suppose what makes it even more painful to go through because the codebase is moderately different and, if fixed, won't make it to the lr-flycast we use.

@mitu could you share context on these changes, just for me to try to understand the difference between the two repos?

Thanks all.

mitu

@pjft said in Mazan: Flash of the Blade (Naomi):

@mitu could you share context on these changes, just for me to try to understand the difference between the two repos?

The libretro/flycast repository used to be the original libretro fork of reicast, but at some point development moved to the main contributor's repository at flyinghead/flycast. The libretro repository is not receiving any updates at the moment and any new development has been done at flyinghead/flycast.

pjft

@mitu Thank you.

But it is my understanding that we reverted that change back to libretro?

https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/libretrocores/lr-flycast.sh

Was the upstream one breaking something on our end, I suppose?

mitu

@pjft said in Mazan: Flash of the Blade (Naomi):

But it is my understanding that we reverted that change back to libretro?

Yes, there were a couple of issues with the upstream repo, which have been solved now, and we reverted the repository change.

pjft

@chaoseffect Ok, so as much as I'd want to help here, this clearly seems to be above my knowledge of the code and emulator.

I added some profiling elements to the emulator, and we can observe a slight increase in time for the audio handling and emu.render() calls in the main retro_run() function.

That being said, I don't know how to dig into it.

I think the only difference between playing with a controller and the gun is that the screen will flash white for a single frame (for the old CRT guns to pick up the position). I don't know if that helps in any way.

Would love to see this making some progress indeed, but I'm kind of at a loss - unsure if it's on the libretro code or on RetroArch. :|

ChaosEffect

@pjft No worries. Thanks for taking a look!

Someone else had a sort of similar issue with Ninja Assault due to the Vulkan video driver. The behavior sounds similar, but the cause of the issue seems different. In that particular issue, the game rewinds when the white flash is supposed to hit.

I tried different video drivers, but choosing anything other than "GL" just gives me "GL core," and the issue is still there. I also don't have access to Vulkan on my current setup.

I did try changing a few core options here and there, but I figured that's just taking shots in the dark and stopped. I can take another look.

pjft

@chaoseffect I was asking in case you had - you don't need to. I tried messing with it a bit more, and no core option changed things. The input drivers didn't seem to change it either.

I removed the audio code path from the game, but it still froze, so it's either something in the rendering or the actual <run> functions, both being completely out of my depth.

It's a shame, though, the game does run well other than that.

Thanks for raising it!

ChaosEffect

@pjft If it's not too much trouble, could you reply to that issue on GitHub with a brief summary of your investigation? Maybe it'll help create a "Eureka!" moment. 😃

pjft

@chaoseffect Done. It's possible it'll just lead to a "mute" moment, but it's worth a shot :D I'm happy to follow a lead, but I really just don't know where to go from there.