The State of Emulation topic

[WelshMegalodon]

...

So... there's a new beta release of Mesen, another high-accuracy NES and Famicom emulator! Always good to have more of those. Nestopia Undead Edition may already have everything I could ask for in a Famicom emulator, but I know even it cannot run every single game in the system's library (to say nothing of mapper support). This looks like one to watch.

Link here.

Oh, and higan's hit v100, though most people appear to have stopped caring at this point. Incidentally, puNES also released their v0.100 earlier this year.

[copy-paster]

I'm planning to use MESS to play MSX2 and X68k games, does it runs well on the latest release?

[WelshMegalodon]

You really want either openMSX or blueMSX for MSX2 games. The former in particular is a very ambitious project aiming for 100% emulation of the MSX.

As for X68000 emulation, I haven't really tried it much, but MAME's X68000 driver is reported as 'Imperfect'.

On a related note, I remember MAME's Sharp X1 emulation being quite slow.

[trap15]

Not sure why you'd want to use MESS for either of those, since they're not great in MESS, and the stand-alone emus are quite good. Get XM6 TypeG for x68000.

[copy-paster]

Get XM6 TypeG for x68000.

The interface is all in Japanese language, does it have English release?

You really want either openMSX or blueMSX for MSX2 games.

I tried blueMSX once and it's good, not sure if MESS emulates the game better than blueMSX...

[WelshMegalodon]

I have yet to see a MESS* driver with better emulation than the most developed standalone emulator for any reasonably popular system. This holds true even for drivers marked as 'Good' - you won't find many people recommending MESS over Stella or Altirra, for example. I myself only use MESS for Apple II emulation and relatively obscure systems like the FM-7. People using MESS for the sake of convenience are missing out.

Speaking of MESS, I've found its Master System emulation rather lacking. The BIOS version of the Space Harrier theme doesn't sound right at all.

*MAME technically does both sides now, but the two guys above me said MESS, so whatever.

[WelshMegalodon]

Mednafen 0.9.39-UNSTABLE

This release adds experimental Sega Saturn emulation. It currently is x86_64-only, very CPU-intensive, lacking save state support, and not supporting PAL-region games. However, SSF("Saturn Sound Format") rip playback is not limited to x86_64 platforms.

http://forum.fobby.net/index.php?t=rvie ... 6#msg_4409

EDIT: Shienryu and Radiant Silvergun are full of slowdown and audio glitching, but they do run on my underpowered machine. Those with Dolphin-worthy setups are likely to have a better experience. It's too soon to give a complete assessment of the core's performance, but people are busy at work putting together lists of compatible games.

On a related note, there's a new build of BlastEm, the fast and accurate Genesis emulator:

http://rhope.retrodev.com/files/blastem.html

Spoiler

All Z80 instructions now implemented
Z80 half-carry flag is now fully implemented
Implemented undocumented Z80 flag bits
R register is now incremented appropriately
Redundant opcode prefixes are now handled properly
Z80 core now passes ZEXALL!

[null1024]

I have yet to see a MESS* driver with better emulation than the most developed standalone emulator for any reasonably popular system. This holds true even for drivers marked as 'Good' - you won't find many people recommending MESS over Stella or Altirra, for example. I myself only use MESS for Apple II emulation and relatively obscure systems like the FM-7. People using MESS for the sake of convenience are missing out.

Speaking of MESS, I've found its Master System emulation rather lacking. The BIOS version of the Space Harrier theme doesn't sound right at all.

*MAME technically does both sides now, but the two guys above me said MESS, so whatever.

MESS never got the TLC it needed. Loads of people saw it as a side-project to MAME, and then the various drama in MAME development pushed developers who'd focus on it away [since code is directly shared between both projects].
combine this with the fact that there are just flat out better, faster, easier to use/setup, and more accurate emulators for most systems people care about that MESS emulates, there's few who are qualified who will bother to work on it

[Ed Oscuro]

Even to a casual observer like me, MAME's crisis seems to have two hot spots: The treatment of individual developers / sub-projects and the goal of the program itself.

The treatment of the program itself is easy enough. Originally the "MAME documents hardware and software" line appears intended as a musclebound defense of the program's worth, seeking to look like a kind of public history project (note how MAMEdev currently only mentions "arcade video games" as an afterthought in its homepage, with the language not clear whether arcade machines are even still one focus amongst others, as opposed to the Wikipedia entry on the project which still naively identifies MAME as being about playable arcade games). Why was this thought to matter? Was this the price of Gridlee? It doesn't seem to have anything to do with whether MAME was legal itself, except perhaps as a kind of talisman against futuristic anti-preservation bigots, perhaps, just as MAME wants to be FOSS, except not really. Next, MAMEdev's development seems to have expanded to fit that expanded rationale. Finally, we have come around to a point where the expanded development has to be raised to the same moral status as the original programs. Unfortunately this creates a much larger legal "attack surface" for MAME; after all, it's better to be the potential target of copyright holders in entirely different markets untested by the law, as opposed to just video arcades where the emulator/software distinction over copyrighted materials has already been decided in court almost two decades ago.

Ironically the response from a MAMEdev (if my memory's right) in a recent thread explodes almost the entire argument in dramatic fashion, and nobody noticed. A user asked for the ability to categorize games by type, so that certain types (like one-armed bandits) can be excluded from ROMsets. The response was that seeing their work cut from releases would harm the morale of developers focused on submitting non-video arcade-related drivers. Putting aside whether this is a brittle and thin-skinned response touching on an issue that should not be an issue at all, as public acclaim for the important things in life is always unreliable. Instead note the unlikely implication that big trackers would cease to offer full ROMsets (but note that some do split MAME ROMs and MAME software lists!), or that famous frontends would exclude fruits entirely. This is clearly a knee-jerk reaction not worth taking seriously, based more on understanding the basic reality that one-armed bandits are not at parity with video games like the Touchmaster series (and I'm saying this as a guy who didn't even know about the calculator emulations / simulations until now, and plans to check them out, and who enjoys having potentially unlimited racy Italian and Spanish synonyms for beautiful women showing up in the gamelist). While I have just argued that what The People want doesn't always matter, the MAMEdev-ish argument was originally about popularity - there is no question video games and gambling machines are far from equal in popularity, at least once you take the money out of the equation. Whether slots are wrong isn't the point. It's frustrating to see this kind of political showboating even in MAME. It may be intended to keep everybody hanging together, but it certainly has succeeded in frustrating testers and developers - and that's before asking whether MAME's future development team hasn't spread itself thin to the point of irrelevance.

It's actually worse than that, because it kills the argument that the functionality in MAME is meant for testing. Talk about tipping your hand! It seems pretty clear to me that the feature request was aimed at allowing a tester to more efficiently target certain games (and platforms, as in the discussion thread there was a lot of commentary on the size of the full ROMsets and the speed of updating a full UI view), wouldn't you agree? Certainly MAMEdev should be quick to agree since that is why they say they deign to make games playable at all. Bringing up random emotional appeals assuming devs are brittle, and using those appeals to differentiate between the rightness of implementing different types of feature requests, is irresponsible and will not work well.

I believe it's sad that MAMEdev passed on the chance to offer a much better argument: Attempting to categorize different games is simply beyond the scope and expertise of the project. I think this is fairly obviously true; many "games" in MAME don't fit clearly into one category or another. That trying to sort out what "type" of machine a game is would ultimately do nothing but give power back to anti-gambling powers is just one possible reason why this could be seen as bad, and perhaps not, but ultimately it ought to rest on what sort of determinations MAMEdev is in the business of doing. Not saying what of the machines does "good" or "bad" or whether testers ought to have the game list view set up a certain way or other. I'd much rather have some focus put back onto adding some features, like lag elimination and TAS type tools, which would grow interest in MAME again, and therefore the pool of people testing games for accuracy, and the suitability of the program to demonstrate this.

Meanwhile, RetroArch is focusing on bringing good emulation cores under one roof, so that more diverse needs are enabled, allowing their testers a wide range of useful functions while not having to worry about quirks of the program when using various emulation cores, and generally eating MAME's lunch as far as popularity and outlook goes. At the same time its development has a bunch of other positive effects outside gaming, and it is probably no coincidence that advances in N64 emulation are being reported there, and not at MAMEdev, all while RetroArch offers multiple MAME cores by default including old versions. No doubt we can soon look forward to a MAME core in RetroArch to appear which emulates an illegal coin-op RetroArch installation on obscure Chinese mobile-based gambling hardware, running a MAME core. Then all that steely determination will have paid off. But I dunno, maybe I'm way off base here.

[BPzeBanshee]

I see what you're trying to get at but I think you're off the mark on a few points.

Your argument on "testers" needing a game list view differentiating games by type frankly is bullshit. MAMEdev have had this request put to them many times and no matter which of the answers they give (and have given over the years) it's never satisfactory to the script kiddies so I'm not surprised the easy answer was given there. The SOURCES= function that is provided when compiling easily allows someone testing a driver to do so without having to compile the rest of the materials, so there's actually no need dev-wise to maintain a category list at all.
The only reason such a list is wanted is for ROM hoarders to get rid of or otherwise hide away fruit/non-arcade/pinball/computer/non-working titles from the list, and MAME has never supported that - remember it was only ever MAMEUI that provided such a feature in the first place which had been dis-endorsed as far back as 2007 when the last big core change started revealing how bitrotted the code had become.

The real "feature" problem I see comes from not MAME itself but the house of cards that was MAME Plus and because most variants were built from that they did not survive MAME's shift from "reinventing the wheel and rolling its own boilerplate code" to "roll the emulation and outsource anything else". Going FOSS clearly was meant to make this easier for MAMEdev but it was the straw that broke the camel's back for the singular devs of the frontend flavours and now if you want feature x implemented in your MAME play you're left with three options: using dated builds, writing new code yourself and submitting a pull request, or try to convince a MAMEdev to bring in said feature.

Nobody wants the first choice as the final solution. The second choice of that believe it or not is already being done - GroovyMAME's non-hacky changes last I checked were being incorporated into MAME, cross-platform future-proof filtering solutions previously only available as dodgy plugins for MAME Plus can be found via the BGFX renderer, and controlling MAME for TAS use via Lua is slowly but surely becoming more feasible. The third choice ties closely with the second - if the feature supports the likes of people who would abuse the program or compromise the code somehow even if you're written the code for them it'll get rejected. Asking a MAMEdev to do it makes no difference if the "feature" is not project-friendly, and I can't see the stuff being requested like supporting hacks and can-of-worms topics like "reducing lag" or "help me maintain my rom collection pl0x" making for very convincing arguments.

[Ed Oscuro]

Your argument on "testers" needing a game list view differentiating games by type frankly is bullshit.

I did write a wall of text, but I thought I made it clear I don't endorse that request, as I wrote that trying to categorize different types of hardware as game or fruit or whatever is beyond MAME's scope. They also could have simply stated that it's not a feature that helps MAME progress; but putting hyperbole aside, such features wouldn't have been the end of MAME any more than ShmupMAME or MAME Plus! were, and this kind of "you're just a leech, you're just hurting" attitude is why MAME has a PR problem. As for calling lag reduction "hacks," that's a strange assumption to make about what I'm calling for when you then mention the user-friendly improvements being rolled in from GroovyMAME. This is more in line about what's in my mind: http://libretro.com/forums/showthread.php?t=5428 is not at all about hacks. It's also probably no coincidence that such a discussion flourishes away from MAMEWorld or other MAMEdev related sites (though, to be reasonable, there's no sign that MAME suffers especially from input lag and a recent investigation showed RetroArch had further to go; on the other hand, LibRetro has a different focus than MAME).

To be sure the GroovyMAME additions are great and probably MAMEdev needs more credit, but I see the dogmatism of MAMEdev as being both a limitation and a benefit, while other projects are moving faster and getting better press. We'll certainly have to see how it all shakes out, but as long as MAMEdev's public face is defensive and dismissive there's a good chance that MAME's growth will be stunted. In any case though, you make a comment I find intriguing - outsourcing some features with the new FOSS code is probably going to be good for all MAME users compared to the mess of frontends before.

[Xyga]

Mamedev amazingly increasingly don't give a crap about what users want, in public they'll put all their strenght in making up any dishonest reason - typically against the user's requests or criticism, and they'll use a lot of contempt, to silence them. As far as it fits their schizophrenic policy/philosophy and insider's personal egos it's okay. Like a big trust or a government in the end they'll do what they want, even if it's shit people are massively against.
That, will never change.

Thankfully they're still the heroes of games preservation. And they give the world all that for free. It's their ultimate parade to justify telling everyone who's not happy to fuck off, and in a way they're damn right lol.

EDIT: about GM additions, there's been only integer scaling so far unless I've missed an episode, and afaik the way it deals with sync and lag is against mamedev's conception of 'accuracy' (they have it wrong though) so I'll believe it only when I see it. Don't forget GM isn't free of movement anymore.

[WelshMegalodon]

I did write a wall of text, but I thought I made it clear I don't endorse that request, as I wrote that trying to categorize different types of hardware as game or fruit or whatever is beyond MAME's scope.

Progetto EMMA has a search function that allows one to pull up all games of a certain genre or "category", including adult and non-adult casino games. Am I missing something?

There was this article online about someone (possibly a Hyperspin user) finding naughty romhacks in MAME and crying out for programs allowing a user to easily remove them, lest some small child be stripped of his innocence while browsing daddy's romset unsupervised. I found myself thinking, "What does it take for someone to even have that problem?". It would be perfect for mirkvid's "Funny Stuff" thread, if I could only find it.

EDIT: Managed to dig it up. Head to mirkvid's thread and feel the derision welling up inside you.

Just to clarify - while I don't support every decision made by the MAME devs (their approach to emulating 3D games, for example) I maintain that, for the most part, they are generally quite competent at what they do (game preservation) and their contributions to the emulation scene should not go unrecognized. One cannot deny that they have at the very least graced us with more accurate versions of 80s and 90s arcade games than anything most people were able to play at home.

[BPzeBanshee]

Ed I understand that request wasn't necessarily *your* request, but whether it's your's, mine, or the prime minister's, is irrelevant. What I was trying to get at is that the majority of MAMEdevs that have been with the project for a long time have heard it all before, seen all the ulterior excuses before, and said exactly the answer variants you said before, but people still ask.
You're right, it is effectively out of scope of mainline, but as long as people can't take "no" for an answer they will continue to stonewall this and no amount of whinging or negative PR will change that. Plus you have to understand these guys are in it for the long haul - a n00b's hurt feelings doesn't mean much when they just want to play the games, they can go to a standalone emu or to FBA and it'll all blow over in a matter of hours till the next dipshit asks the same question, but having the devs making things easier for ROM hoarders and collectors that work against their preservation efforts will hurt the project more in the long run. It might not kill the project but enough MAMEdevs believe catering to end-users in such a way will hinder it.

I think the nail you should really be putting your hammer on is not MAMEdev themselves as a whole but the MAMEWorld forums. Most of your complaints about bad PR points and people not wanting to post conclusive stuff towards MAMEdev can be traced back to a select few members there (like Ryan "Spew a toxic post for a spelling mistake" Holtz) and the head of the DU taking a more anarchistic approach to moderating in recent months. Over here on the other hand folks like Haze and etabeta have been welcoming as long as you treat them the same way. Furthermore there's even an official MAME forum now, but nobody wants to use it.

As for calling lag reduction "hacks," that's a strange assumption to make about what I'm calling for when you then mention the user-friendly improvements being rolled in from GroovyMAME. This is more in line about what's in my mind: http://libretro.com/forums/showthread.php?t=5428 is not at all about hacks. It's also probably no coincidence that such a discussion flourishes away from MAMEWorld or other MAMEdev related sites (though, to be reasonable, there's no sign that MAME suffers especially from input lag and a recent investigation showed RetroArch had further to go; on the other hand, LibRetro has a different focus than MAME).

Not everything Calamity tried to merge into mainline MAME was considered up to scratch for cross-platform solutions and certainly talks of overwriting the Windows USB driver to increase polling rates as covered on BYOAC forums is not something MAMEdev would endorse - this is the sort of programming "hack" I was talking about, as opposed to game-specific hacks like what ShmupMAME provides.

Input delay in itself is also a can of worms when you consider all the factors in place that could generate it and that most people like to just pitch in and go by their "feel" rather than any scientific method thus putting water into the fuel so to speak. I'd like to see more of GroovyMame's improvements brought to mainline as well but realistically it won't happen unless Calamity puts it in as an effectively bulletproof pull request. Nothing stopping him from doing so except time and effort.

[Xyga]

a n00b's hurt feelings doesn't mean much when they just want to play the games, they can go to a standalone emu or to FBA and it'll all blow over in a matter of hours till the next dipshit asks the same question, but having the devs making things easier for ROM hoarders and collectors that work against their preservation efforts will hurt the project more in the long run. It might not kill the project but enough MAMEdevs believe catering to end-users in such a way will hinder it.

Lol.

EDIT: Oh btw talking about GroovyMAME, it is back and rocking with a fresh 0.176 build, seems like Calamity managed to bring the magic to BGFX.
Dunno if it will end up in baseline, but personally I don't care as long as we have Groovy. Yesssss!

[Ed Oscuro]

Ed I understand that request wasn't necessarily *your* request, but whether it's your's, mine, or the prime minister's, is irrelevant.

We're here, talking, and I care not to have my views misrepresented.

We seem to basically agree about MAME's messaging problems but I think it requires more than just moving away from MAMEWorld. Considering people repeating requests, I'd wager things are asked repeatedly because there's no obvious place to look for info about the scope of MAME or a go-to FAQ covering these issues. It seems logical to assume some people stay away from contributing because of uncertainty. As our back-and-forth shows it's quite possible to watch MAME for years and not know about MAMEdev attitudes on some critical subjects! This is more problematic when you consider that if somebody asks the right question, on a good day they might get a real answer, and on a bad day they might get a completely irrelevant hand-wave that sends them screaming for the exit. People shouldn't be scolded for not knowing the secret knowledge that you only get by bothering somebody on IRC or finding obscure posts to get the right answer. That's simply not good for MAME. As you say, it's not a good thing that somebody must answer each and every question about things.

About input polling (I haven't been paying such close attention to the GroovyMAME-MAME side of things, my point was more along the lines that I didn't see the right conditions for this being discussed): It would be nice if the new forums are a place where some of the more serious and worthy attempts can be discussed. If the move to make MAME FOSS is meant to allow some changes to be outsourced, though, there ought to be more public discussion of what sorts of changes will be considered, else the effort is for nothing or it is only relegated to some unofficial build which may be sunk later on by core changes.

Haze actually has been at the center of a bunch of hard-to-fathom controversies within MAME over the years but I couldn't begin to try to unravel that mess, except to say that it is a pretty obvious example of prominent MAMEdev members being unable to get control over themselves for the sake of public perception. (Whether or not Haze is the hero isn't the point; there is hardly any decaffeinated source of MAME news besides the terse update summaries.) The official MAME forums announcement with .175 sounded good, but it is wishful thinking to assume that simply putting it out there will get people coming. I hope its moderation and role turn out differently from MAMEWorld, much differently, as you say.

[BPzeBanshee]

Puked out all the Hate-o-rade I drank yesterday, read through my post and it seems in trying to convey my points I brought a bit of that MAMEWorld toxicity over here too. That's no good at all! My apologies for that.

It seems while we disagree on some of the details I think we can both agree there is a problem of mixed messages. As for the roots and how to deal with them, we'll wait and see. I'm not convinced having a PR guy is necessarily the solution but some more concise documentation on what gets knocked out of MAME and what gets the green light rather than looking at the project history would be a good start.

[Ed Oscuro]

I'm not convinced having a PR guy is necessarily the solution but some more concise documentation on what gets knocked out of MAME and what gets the green light rather than looking at the project history would be a good start.

Yes, this is precisely what I'm calling for in my last post. Cheers

[Xyga]

Have you guys noticed a performance increase switching video from Direct3D to BGFX ?

I thought my somewhat wimpy laptop had no hope to run the Cave CV1K games at decent speeds, but now with BGFX to my surprise those do reach 100% save for the few seconds at the beginning of the stages and just before bosses, plus some swift hiccups here and there but nothing really breaking the pace.

Sure there's still the broken ingame speed compared to the real thing, and some input lag (though less so when using GroovyMAME), but it is a pleasing late realization for me (it's my first time really giving BGFX a try even though it's been around since 0.170 or so).
Don't know how many years it will be before CV1K's emulation is considered good-enough for actual gaming, but the current offers a glimpse/sample experience no longer requiring a semi-beast computer.

[copy-paster]

The newer version of ePSXe now has CPU overclock function.

I tried to test the function using G-Darius as the game, some sections that slowdowns really bad are now gone and runs at full speed.

[Xyga]

^ This is awesome.

[Xyga]

With GroovyMAME 0.176, BGFX, autosync, and xbr-hybrid shader
it's s pleasure shmupping even in yoko.
Seriously even DOJ feels and looks good. :p

[BPzeBanshee]

Yeah the BGFX performance now that the kinks are mostly removed it from seems to have really benefitted the project. Over on Bannister Forums I posted some figures some time back, perhaps its even better now.

Meanwhile over in mainline, this popped up: https://github.com/mamedev/mame/commit/ ... d0c7db876b

Haze said it years ago and if anyone doubted him this is more proof he was right - As I recall the last time this was brought up it was because DFK got dumped several times by different people and had a similar problem, and that was an even newer game. Clearly the chips used for the CV1K boards are rubbish and anyone keeping said boards should get their contents dumped ASAP before they go bad, Limited Home Special Elitist Hoarder Amish SJW Rainbow Caramel Swirl Vanilla Label Edition or not.

[Xyga]

Talking about CV1000 games I wasn't paying attention to DEmul but it seems they have fixed the garbled graphics.
(try the most recent 2016 Alpha builds)

Vsync works and the lag seems more acceptable than before.

There's only a single linear filter available and it looks worse than the bare thing lol.
Shader options are greyed-out for the moment.

The ingame speed though is still completely wrong as expected, I don't know of any blitter values that would help limit that overdose but hey, at least the thing runs considerably smoother (and lighter!) than even MAME with BGFX.

[Gespenst]

http://insertmorecoins.es/arcade-0-177- ... t-updated/

Looks like someone's carrying on Mameuifx torch after its misery. Good to see that.

[Obiwanshinobi]

Is either Kororinpa game fully playable (emulated) with a DualShock3, Sixaxis or a similar motion controller (other than actual Wii remote)? Since I don't have a computer powerful enough to emulate Wii properly, I would dearly appreciate it if someone gave it a serious* try and report back. Thanks in advance.
*) That is - played more than just one or two first stages, and explored those where mazes must be flipped over in order to complete them.

I am trying to determine whether or not those games can be kept alive detached from a physical Wii device.

[tomwhite2004]

How come you dont want to use a real wii remote with the emulation?

[Xyga]

btw GroovyMAME 0.177 is out. Fixes some scaling issues.
Still alpha though, I've noticed some unstable sync/sound when waitvsync is in charge.

Yet it's really great now only missing some hacks (toaplan samples etc), maybe people will share customized builds, later when they get around some compatibility issues.

One thing that's a little annoying is that apprently using BGFX it's become impossible to take screenshots when integer scaling that goes to overscan area is used.
Neither windows nor dedicated screen capture applications seem to 'understand' what's going on.
It used to work with D3D but since it's gone and BGFX is the new to-go video mode I'll have to think of something else or wait that someone else does...

[WelshMegalodon]

A new version of Atari 8-bit emulator Altirra was released just yesterday:

http://www.virtualdub.org/altirra.html

Tons of bugfixes, as is customary for releases of this highly accurate emulator. Great for all those games you've only been able to play on your boring old C64. :p

[soprano1]

http://insertmorecoins.es/arcade-0-177- ... t-updated/

Looks like someone's carrying on Mameuifx torch after its misery. Good to see that.

I switched to mameui after hearing about mameuifx's developer giving up because mame drama. Maybe i'll check this out, mamemui still has too much shit i hate.