Home Page Forums MAME MAME SVN builds - new driver flood

Either you or Haze are more than welcome to fix it. In the meantime, I'm off. The level of ingratitude for trying to slog through a few old bugs is making my head spin.

Yep, and that way all the systems that need it benefit from it.

It's a common technique used on handhelds to overcome sprite limits and create transparent effects, so having it in the core means that any system that needs it can use it, having it in the drivers helps nothing in the longrun.

Is there any need for all the drama just because I disagree with something ?!

Like it or not, you two are the drama king and queen of emulation (you can fight on IRC over who's who, I won't allow it here).

Well it's the same in MAME really, there are lots of old bugs which can be fixed with a hack, as Mamesick often does, but doing it that way often doesn't really bring us closer to a real solution and can bloat the code and get in the way of figuring things out properly.

Here the path is more obvious tho, although it needs somebody who does core / video output to handle it, rather than the people who work on the drivers. (Just as fixing the bugs Mamesick hacks need somebody skilled / capable of testing on the hardware to fix them properly rather than attempting to by simply reverse engineering of unclear/ambiguous behavior)

What ever happened to hacks being acceptable as an interim solution on the way to a proper one, as long as they're marked as such in the source code?

I'd be more than happy to mark the code as a hack with some sort of a comment, but removing it entirely in favor of this non-existent core LCD persistence handling seems pointless.

On the topic of adding core support, the actual method of handling persistence is debatable. The Game Gear driver uses a flat 50/50 blend right now, but I expect other LCDs might have more or less persistence, so a two-frame average wouldn't work for those. Then, once it's supported by the core, what's the standard for determining the persistence value? Tweak it until it looks right? Write trojan code and use a high-quality camera to measure the persistence empirically?

Then, how do drivers specify persistence? Does it become a new MDRV parameter, MDRV_LCD_PERSISTENCE?

At any rate, I agree that it should eventually be moved into the core, but for heaven's sake, the bug has been there for 8 years, it's one of MESS's most long-standing bugs, and this is at least better than nothing.

I don't think this rises to the level of awfulness that Mamesick sometimes likes to perpetrate. At least the results are correct and pretty good looking, which I can't say for several Mamesick specials.

That said, this does clearly belong in the core as an optional attribute of screens that are type LCD.

ETA: Regarding tuning, I'm thinking you pass a struct that specifies how many frames to involve in the persistence and how much each contributes to the final image. It could be fiddly to tune, but you need that power.

Also, doing it in the core opens up the eventual possibility of having a pixel shader do it for you, which would be an obvious performance win.

There is a certain irony in the whole situation, that being the very first thing I ever did with MAME was release a couple of hacked builds which simulated an LCD screen for the output, by combining various amounts of the previous 2 screens. Of course, not having a clue how anything worked back then I destroyed all the normal output in the process, so it wasn't optional, but it was all good fun ;-) I mainly did it at the time as an example showing that it could be done and looked good, because none of the handheld emus had such a feature, and it was annoying me.

The pre-Aaron MAME D3D code actually had a 'feedback' option which could be used to give a similar effect, but it was ripped out along with everything else when Aaron added his own D3D implementation.

Completely off-topic, but the topic's long enough as it is - how do I manually return data from an SMH_BANK handler?

Huh? I'm pretty sure asking that means you're doing something wrong. Explain

True, it is probably wrong. I just don't quite understand in what way overlapping AM_RANGE macros override each other, so that's all I can go with right now.

Line 79, sms.c:

AM_RANGE(0x8000, 0x9FFF) AM_READWRITE(SMH_BANK(4), sms_cartram_w) /* ROM bank / on-cart RAM */

This will not work for Game Gear games that use the 93C46 EEPROM. The EEPROM lines are hooked up at 0x8000, and direct EEPROM access is also available from 0x8008 through 0x8088. I was considering making an sms_cartram_r, and optionally either reading from ROM or reading from EEPROM depending on both the address and whether or not it's a 93C46-using game.