Previous Thread
Next Thread
Print Thread
Page 97 of 536 1 2 95 96 97 98 99 535 536
Joined: May 2009
Posts: 2,214
Likes: 382
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,214
Likes: 382
Originally Posted by R. Belmont
Yeah, this should happen in the core if the screen type is set to LCD, and there should be some way for drivers to "opt out" as well. Sega handhelds were notoriously smeary (playing Sonic 2 on a Nomad is a real experience for that reason), but others aren't so we don't want to pin drivers that don't have the effect with it.

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.

Joined: May 2004
Posts: 1,772
Likes: 34
H
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,772
Likes: 34
Originally Posted by R. Belmont
Yeah, this should happen in the core if the screen type is set to LCD, and there should be some way for drivers to "opt out" as well. Sega handhelds were notoriously smeary (playing Sonic 2 on a Nomad is a real experience for that reason), but others aren't so we don't want to pin drivers that don't have the effect with it.

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 ?!

Joined: Mar 2001
Posts: 17,215
Likes: 234
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 17,215
Likes: 234
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).

Joined: May 2004
Posts: 1,772
Likes: 34
H
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,772
Likes: 34
Originally Posted by Just Desserts
Originally Posted by R. Belmont
Yeah, this should happen in the core if the screen type is set to LCD, and there should be some way for drivers to "opt out" as well. Sega handhelds were notoriously smeary (playing Sonic 2 on a Nomad is a real experience for that reason), but others aren't so we don't want to pin drivers that don't have the effect with it.

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.

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)

Joined: May 2009
Posts: 2,214
Likes: 382
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,214
Likes: 382
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.

Joined: Mar 2001
Posts: 17,215
Likes: 234
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 17,215
Likes: 234
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.

Last edited by R. Belmont; 11/02/09 08:55 PM.
Joined: May 2004
Posts: 1,772
Likes: 34
H
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,772
Likes: 34
Originally Posted by R. Belmont
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.

Joined: May 2009
Posts: 2,214
Likes: 382
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,214
Likes: 382
Completely off-topic, but the topic's long enough as it is - how do I manually return data from an SMH_BANK handler?

Joined: Mar 2001
Posts: 17,215
Likes: 234
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 17,215
Likes: 234
Huh? I'm pretty sure asking that means you're doing something wrong. Explain smile

Joined: May 2009
Posts: 2,214
Likes: 382
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,214
Likes: 382
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.

Page 97 of 536 1 2 95 96 97 98 99 535 536

Link Copied to Clipboard
Who's Online Now
0 members (), 305 guests, and 1 robot.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,320
Posts121,923
Members5,074
Most Online1,283
Dec 21st, 2022
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com