search

libretro / mame2003-libretro

MAME 0.78 for libretro. Compatible with MAME 0.78 sets.
Other
90 stars 74 forks source link

[Bounty: $10] implement internal MAME 2003 video flip/mirroring #386

Closed markwkidd closed 5 years ago

markwkidd commented 5 years ago

Bounty contributions make a difference - please donate at this link today to support this feature

Current situation

There are a number of arcade games that projected their video by means of a mirror. In order to emulate this setup, MAME 0.78 incorporates video flip/mirroring code that has not yet been incorporated into MAME 2003 or MAME 2003-plus.

Lethal Enforcers is a good demonstration of the issue: img_20180527_155554194

@grant2258 spent time compiling a reference list of some affected games

There is a workaround: by using hunterk's RetroArch screen mirroring shader users can work around this bug, but of course that is only viable for users with shader support and those with a frontend like RA that supports shaders as well.

Resolution

This issue will be resolved when there is full flip/mirroring support in mame2003 (which will also get ported to mame2003-plus).

In terms of work to date, grant and @dankcushions have both put time into researching the solution. Their notes can be found here: https://github.com/libretro/mame2003-plus-libretro/issues/81

Some specific posts might be relevant:

markwkidd commented 5 years ago

@nayslayer you have already made at least two key bugfixes (that I know of) to longstanding mame2003 and RetroArch. So nice!

Don't take my tagging you in this issue, or any other, as pressure to take on a project. However based on your other contributions I thought this mirroring problem might be in your area of interest and expertise.

nayslayer commented 5 years ago

Okay, I'm on it. This is basically a libretro frontend shortcoming: the video subsystem is expected to handle such settings, but it doesn't. This one should be especially easy to fix, so I'll probably get it done in a day or so.

Don't hesitate to @ me, I read the notifications in bulk when I have time.

markwkidd commented 5 years ago

Fair enough, I'll try to use some discretion with tagging you but I won't hold off completely hehe.

The bottom half of yesterday's libretro blog post on MAME 2003-Plus is basically a list of all of the most significant known issues/opportunities I'm aware of for both versions of the core: https://www.libretro.com/index.php/introducing-mame-2003-plus-a-high-performance-libretro-arcade-emulator/

You've seen a few of those issues but that's the list if you'd like to see it in one place.

nayslayer commented 5 years ago

Whew, I'm finally done with it. As you may've guessed, I suck at estimates =/ What should've been a small tweak turned into a near-total rewrite of video.c and a hell of tinkering and off-by-one errors in loops. The performance also ended somewhat worse than it was - I posted some thoughts in the PR description. All in all, I hope the code isn't nearly as confusing to read as it was to write :) Please do some tests, then call me back, I'll port it over to mame2003plus myself.

I've read the blog post - great work, by the way - and I can probably do the lightgun support. The runahead bugfixing, not so sure. Analog controllers - no, I don't have a stick anyway. I'll keep those in mind, but there's some other libretro work I neglected so it won't be fast.

And if I may ask again - exactly which devices can't run the modern MAME? Can't it be optimized instead of maintaining a fork?

markwkidd commented 5 years ago

@nayslayer regarding performance. This core runs great on an rpi, an ARM S905-based set-top box, an Amazon Fire Stick, or a hacked SNES classic, but current MAME is unusable on those systems for performance reasons.

I don't think current MAME even builds right for android ARM devices after MAME 0.172 (which is why we have the MAME 2016 core) but try actually using MAME 2016 on a smartphone -- it's no good anyway.

Unless a user has a PC from the last two or three years, they going to have performance issues with iconic/classic games that run easily in this core.

In terms of improving performance in current MAME for low power devices, my understanding is that there are a few MAME developers who are willing and interested to do that, but that overall it is not supported by the MAME developers.

What I can say from direct experience since that blog came out is that there are also some MAME developers who are against libretro/RetroArch itself and who are vocally against the two projects working together. It's kind of nuts, but at least two of their developers have said antagonizing things to me personally this week. I had heard about this phenomenon but now I have experienced it myself. :sigh:

I have no idea what the decision making/leadership structure is within MAME but RetroArch developers (and me as a maintainer of this libretro repository) would not be able to get away with spreading FUD about other projects and their leaders for long without getting removed from the team. I've seen it happen several times and that's how it should be.

What would be nice is if MAME could get its own developers to be civil and then some kind of joint effort to 1) improve the integration of the current MAME core with libretro and 2) begin optimizing for low power devices. Maybe you can be that bridge!

UDb23 commented 5 years ago

@markwkidd

two of their developers have said antagonizing things to me personally this week...

Fully agree with your thoughts. That's really bad and unjustified behaviour. If there's anything that can be done to support you, just ask.

Wilstorm commented 5 years ago

there are also some MAME developers who are against libretro/RetroArch itself and who are vocally against the two projects working together.

I've read a few articles and some do feel very strongly about the subject.

1) improve the integration of the current MAME core with libretro and 2) begin optimizing for low power devices

Amen to that!

markwkidd commented 5 years ago

I do apologize for derailing this issue during the unpleasant communication with MAME last week. I appreciate that grant opened up an issue about the renaming request which is where future discussion can go.

Briefly, after a lot of bluster and complaints, the question of the name of this project seems to be the only thing that the folks over at MAME are -- as a group -- interested in talking with us about. The couple of devs who were so outspoken about all of those other issues have stopped posting about this emulator at all. End of derail!

dankcushions commented 5 years ago

Thas has been my experience with MAMEdev also. I did actually (informally) approach them some years back about what adjustments were needed to 2003 to make them happy - renaming, relicensing, whatever. silence.

i feel they are fundamentally opposed to retroarch forks: https://mamedev.emulab.it/haze/2018/01/03/welcome-to-2018-whats-going-on/

so, don't take it personally :) end of derail II.

nayslayer commented 5 years ago

@markwkidd Thank you for your detailed answer! Now that I'm done (for now) with the issue at hand, let me share some thoughts on the situation, without taking sides.

The practial thing. Recent MAME's tardiness can't be explained by emulation accuracy improvements alone. The 0.78 was already using the slowest possible emulation method, by driving the arcade machine at the core CPU clock rates. I didn't dig too deep, but the parts relevant to CPU and hardware seem to have mostly cosmetic differences. The graphics layer, however, was reworked completely since then, and it may just be the key of optimizing the thing, and probably retiring all older MAME cores. This is theoretical for now, as I have more than enough on my plate already.

Now, on MAME developers' rants. I can relate to at least some of their criticisms: libretro indeed breeds bogus error reports, and it does seem to gravitate towards a lowest common denominator (not userbase, but features), and its cores are often lagging behind upstream. But these problems can't exactly be fixed unless the original developers cooperate. I believe it's worth a try to make a completely non-invasive frontend that is always up-to-date with upstream, though mobile device issues must be sorted out first. But for now, getting older cores to work is more efficient, as most of the issues are low-hanging fruits anyway.

nayslayer commented 5 years ago

So, #391 resolves this for good I hope. I'll now move over to grant2258's domain to duplicate the fix for the Plus version, then I'll probably work on the input subsystem as it's the next greatest source of bugs in the core. I greatly appreciate your patience with me :)

markwkidd commented 5 years ago

That sounds great, take your time!