Flickering/jumbled sprites in Metal Slug (J)

[Cee123]

Game is unplayable due to flickering and jumping sprites. The main character and enemies etc are glitched.

[Cee123]

This may not be an issue with the emulator itself, I'll try a different dump and see if that makes a difference.

[Cee123]

Nope, seems to happen with every version that I've tried on Yaba Sanshiro 3.6.8.

It could also be that:

• There are no good dumps of this game or
• Proper working versions of this game are difficult to find.

[Cee123]

Can anyone else confirm they have this issue?

[devmiyax]

Fixed in version 2.9
https://youtu.be/MVsiyWXYBjg

[Cee123]

Nice!! Great work man. Keep up the awesome work.

[Cee123]

You sir are a legend. Fantastic work as always.

[Cee123]

@devmiyax Is this fixed in the libretro version as well? Or just the standalone Yaba Sanshiro? Because I've tried updating the libretro version and it's still exactly the same. I could try the standalone though.

[barbudreadmon]

Is this fixed in the libretro version as well

Obviously, the libretro port can't be updated if yabasanshiro's code isn't made public, code was finally published this morning so now you'll have to wait for the libretro buildbot to update the core, except if you build it yourself.

It would be nice if @devmiyax wouldn't forget to release the source code right after publishing his binaries, because it's actually a requirement of the GPL license.

[Cee123]

@barbudreadmon Ohh OK, I was wondering why when I updated the yaba sanshiro core it was exactly the same. You are right - it is important to release the source code. He should've done that. Hopefully the libretro core gets updated with the latest changes soon as well.

[Cwiiis]

While I think not publishing the source with the binary is against the spirit of the GPL, I think the requirement is to provide source on request within a reasonable timeframe, and at the expense of the requester? Maybe I'm misremembering though... I'm not super thrilled about it (especially as a former contributer, if only for a short time), but I don't think the licence is being violated (?)

[barbudreadmon]

@Cwiiis https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic

I don't think there is a notion of timeframe. Whatever, i don't really care if this is actually a license violation or not, it's just super annoying because people keep asking me for an ETA of the libretro port update every time @devmiyax publish new binaries & videos, and sometime the source code is published several weeks later.

[devmiyax]

I'm not intend to violate GPL. I just didn't know there is someone who cares about my code.
At the point of view of free software, you can ignore people who asks ETA, isn't it?

[Cwiiis]

I'm not intend to violate GPL. I just didn't know there is someone who cares about my code.
At the point of view of free software, you can ignore people who asks ETA, isn't it?

Trust me, lots of people are interested in this source code :) I'm sure external projects and contributors would be grateful for simultaneous source releases, and even more grateful if you pushed your intermediary changes too. GPL-wise, you are obligated to provide the source for binary releases, though that needn't necessarily be through GitHub (but that would be the easiest way for everyone, I expect).

[barbudreadmon]

you can ignore people who asks ETA, isn't it?

I think some of them actually support your project through patreon/bountysource so it doesn't seem fair to just ignore them, furthermore i'm not good at ignoring people in the first place.

[corvusd]

I want to share my words to this issue. @devmiyax had made amazing work for a long time before in yabause, a now in own fork. It is true that the ideal situation is free the source with the release. Even legally strictly. But I understand that he have a life and plus develop the emulator. And maybe he feel more comfortable Dev in local and after merge and update the last changes. It is true that can be do some collateral problems like: not exactly code or other projects delay other issue or improvents... Well in this point, only can expect that him can understand the situation and if he can share the code with the release. Or almost release at soon possible. Thanks to all collaborators and Devs. Sega Saturn scene needs you.

[Cwiiis]

I want to share my words to this issue. @devmiyax had made amazing work for a log time before in yabause, a now in own fork. It is true that the ideal situation is free the source with the release. Even legally strictly. But I understand that he have a life and plus develop the emulator. And maybe he feel more comfortable Dev in local and after merge and update the last changes. It is true that can be do some collateral problems like: not exactly code or other projects lapsed time... Well inthis point, only can expect that him can understand the situation and if he can share the code with the release. Or almost release at soon possible. Thanks to all collaborators and Devs. Sega Saturn scene need us.

We're all very greatful for @devmiyax's work, but the fact is it wouldn't exist without the work of several others before him on this project, and he is obligated by law to provide the source for released binaries. It isn't optional. As for the difficulty of doing so, it's as simple as git push --force if it comes down to it. It's a lot harder publishing apks on the Play Store.

As grateful as we may be for his work, others are far more likely to contribute and produce an even better emulator if the work is done in the open, as was the case with Yabause, the project this is forked from. If Yabause had been managed in this way, it seems unlikely that @devmiyax would have done the excellent work that he's done.

[Cee123]

That's also true. There can be even more contributions and more improvements and additions from the community with an open source project vs a closed source project where only one or a few have access to the source code. Yabause was the only working Saturn emulator for a long time but it wasn't that good and was slow as anything.

[barbudreadmon]

Let's not start a license drama here, @devmiyax didn't mean any harm, he was just unaware that the delayed publication of his source code was causing turmoils for sub-projects like the libretro core.

[devmiyax]

@barbudreadmon I am not interested in retroarch. But it is ok that I integrate it to my CI and relaese with windows version and android version at same time, if you let me know how to bulid it. because my purpose of this project is to make sega saturn playable for everyone.

[Cee123]

I am not interested in retroarch.

Wow. I mean, damn that is disappointing.

[barbudreadmon]

But it is ok that I integrate it to my CI and relaese with windows version and android version at same time

Thanks for the thought, but i don't think it'll help for several reasons :

• i build it from a fork (https://github.com/libretro/yabause/tree/yabasanshiro), because sometime i need to be able to push new libretro features & fixes quickly, without waiting for my PR's approval, it also allows me to delay the update when there is some major regression (with original resolution as the default in the libretro core, yabasanshiro 2.8 was basically unusable, so i had to keep 2.7 until a proper fix was available)
• retroarch is multi-platform, the core must be built for all platforms (windows, linux, android, switch, maybe others, for all available cpu archs, meaning 10+ arch-specific version of the core), our custom buildbots handle that, i don't know the details but i think it requires quite a lot of setup & maintainance
• retroarch users expect the cores to be available through the included auto-updater which is picking files directly from http://buildbot.libretro.com/nightly/, not through manual download & install from a website

I am not interested in retroarch

Fair enough, but a lot of your users are, and it's not as if i didn't ask for your approval before doing this port.

[Cee123]

I personally liked that there was a libretro port because I didnt have to use Bluestacks or Anbox just to use it as it is on Android only.

[Cee123]

This is also still an issue on the libretro port, so it has not been updated by the developer. Since he no longer cares about the libretro port.

[devmiyax]

@Cee123 you can use windows version. http://www.uoyabause.org/static_pages/download#windows

[Cee123]

I tried the windows version. The issue is still in the standalone version too.

[barbudreadmon]

@Cee123 currently, libretro version should be in sync with standalone version

[Cee123]

Just a thought, are you using an intel gpu ? I think there are some issues with the glWaitSync call and intel driver on windows, and i think the fix for this issue use this call

I'm thinking maybe it's a problem with the rom itself (just like I had with Daytona USA before) because it happens on the Odroid XU4, Odroid N2 and on my PC under windows. My GPU is a NVIDIA Geforce GTX 1060 6Gb.

I could try another version of the rom and see what happens. I've also converted this one to CHD but it did the same thing when it was an ISO.

[barbudreadmon]

Maybe try your iso with the kronos core on pc, if it has the same issue then your iso is probably corrupted or not supported

[Cee123]

Very interesting. It seems to work fine on the Kronos core.

[Cee123]

@devmiyax The issue is still there, even in the standalone emulator. Version 2.9.0-69dcb5.

[barbudreadmon]

So your iso is ok, maybe try changing the resolution to native ? I don't think the fix was tested with other resolution.

[devmiyax]

Do not use bios

[Cee123]

Do not use bios

It's not using the bios.

I tried with a bios as well and same thing.

[Cee123]

I fixed the graphics glitching issue on the standalone by switching from
SH2 Interpreter to SH2 Dynamic Recompiler

Now I just need to find out how to change that setting on the libretro core.

[barbudreadmon]

Now I just need to find out how to change that setting on the libretro core.

You can't, the x86_32 drc is not enabled in the libretro version (afaik there is no x86_64 drc in yabasanshiro), i didn't bother with it since very few people use 32-bits retroarch on PC anyway, everyone use 64-bits nowaday. I can look into this, but most likely you are using 64-bits retroarch like everyone, so you would need a second retroarch setup for 32-bits.

[fafling]

In Windows, v2.10.0, the display is correct only with emulated bios and dynamic recompiler. Any other combination of those 2 options still has flickering sprites.

[Cee123]

In Windows, v2.10.0, the display is correct only with emulated bios and dynamic recompiler. Any other combination of those 2 options still has flickering sprites.

I know that now. It's the dynamic recompiler. Also, it works for me with bios turned off (just as @devmiyax said). If I turn that on, I just get issues with it.

My trouble is I'm trying to get the libretro core to behave in the same manner now since those settings aren't in retroarch.

[Cee123]

Now I just need to find out how to change that setting on the libretro core.

You can't, the x86_32 drc is not enabled in the libretro version (afaik there is no x86_64 drc in yabasanshiro), i didn't bother with it since very few people use 32-bits retroarch on PC anyway, everyone use 64-bits nowaday. I can look into this, but most likely you are using 64-bits retroarch like everyone, so you would need a second retroarch setup for 32-bits.

Yeah I'm using the 64-bits retroarch. You are right, I don't think many people, except those still with older PCs who haven't upgraded and older versions of Windows (which are few and far between these days) use the 32-bit retroarch. Apart from this game, everything else works fine which I'm pretty happy with.

[fafling]

In Windows, v2.10.0, the display is correct only with emulated bios and dynamic recompiler. Any other combination of those 2 options still has flickering sprites.

I know that now. It's the dynamic recompiler. Also, it works for me with bios turned off (just as @devmiyax said). If I turn that on, I just get issues with it.
My trouble is I'm trying to get the libretro core to behave in the same manner now since those settings aren't in retroarch.

Then why don't you ask for this issue to be reopened ? The minimum is that it should work with the default options, which are real bios and SH2 interpreter. Anything else is a workaround, not a solution.

[barbudreadmon]

@devmiyax btw, thanks for releasing 2.10 code immediatly

Anything else is a workaround, not a solution.

Yeah, it doesn't seem to be the best for user experience considering some games require interpreter and/or real bios iirc.
FWIW, kronos had a similar glitch which was fixed by FCare@b978ca9 (that fix doesn't appear to do much in yabasanshiro though, so it could be unrelated)

[Cee123]

This issue still exists in the libretro version. And the standalone version. I'm not even sure why it was closed. Could this possibly be reopened?

[Cee123]

Not sure why the issue still persists, even in a standalone version of the emulator.

[Cee123]

@devmiyax Do you mind reopening this? The issue is still there... It hasn't been fixed.

[Cee123]

@fafling Well, I tried. I asked him to reopen this as the bug is still there on several versions of yaba sanshiro, but he's not listening. He's either not interested or just flat out ignores people who report bugs in his software. I just think that's kind of a dick move. I'm also done asking about this, can't even believe I donated to this project.

[devmiyax]

let's get started again.

[Cee123]

Bro the issue is still there with this game. It still glitches even on the latest Yaba Sanshiro version.

[Cee123]

Interestingly I've tried both with BIOS and without BIOS, both HLE and without HLE and the issue still persists. Just wondering is there a particular setting that will make this display normally? Because in its current state it's not playable.

[devmiyax]

@Cwiiis @fafling @barbudreadmon @corvusd Can you check this issue happens on the latest version(3.3.1). if not, I will close this issue.

[barbudreadmon]

i can't, you didn't publish the sources and i don't use windows/android

[fafling]

With v3.3.2 it's much better. With real bios, there only remains brief sprite flickering at some points of the game :

• At level start :
  
  Select the first level to reproduce :
  metal_slug_mission_select.zip

• At level end :
  
  metal_slug_end_level1.zip

• At high scores screen after game over :
  
  metal_slug_game_over.zip

Tested with the original CD.

[devmiyax]

@fafling Can you try this version? I believe I have fixed.
yabasanshiro-3.3.2-3c9ed7.zip

[fafling]

It's fixed, I haven't seen any sprite flicker left.

[devmiyax]

Thanks!

[Cee123]

If the issue is fixed, we can maybe close this. Actually i haven't noticed this issue on the later versions of yaba sanshiro. But ive been using the HLE bios setting, which i think fixed the garbled graphics somehow.