Previous Thread
Next Thread
Print Thread
Page 97 of 528 1 2 95 96 97 98 99 527 528
Re: SVN builds - new driver flood [Re: R. Belmont] #55952 11/02/09 08:37 PM
Joined: May 2009
Posts: 1,805
J
Just Desserts Offline
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,805
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.

Re: SVN builds - new driver flood [Re: R. Belmont] #55953 11/02/09 08:39 PM
Joined: May 2004
Posts: 1,592
H
Haze Offline
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,592
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 ?!

Re: SVN builds - new driver flood [Re: Haze] #55954 11/02/09 08:40 PM
Joined: Mar 2001
Posts: 16,305
R
R. Belmont Offline
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,305
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).

Re: SVN builds - new driver flood [Re: Just Desserts] #55955 11/02/09 08:42 PM
Joined: May 2004
Posts: 1,592
H
Haze Offline
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,592
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)

Re: SVN builds - new driver flood [Re: Haze] #55956 11/02/09 08:52 PM
Joined: May 2009
Posts: 1,805
J
Just Desserts Offline
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,805
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.

Re: SVN builds - new driver flood [Re: Haze] #55957 11/02/09 08:53 PM
Joined: Mar 2001
Posts: 16,305
R
R. Belmont Offline
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,305
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.
Re: SVN builds - new driver flood [Re: R. Belmont] #55958 11/02/09 09:25 PM
Joined: May 2004
Posts: 1,592
H
Haze Offline
Very Senior Member
Offline
Very Senior Member
H
Joined: May 2004
Posts: 1,592
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.

Re: SVN builds - new driver flood [Re: Haze] #55959 11/02/09 09:38 PM
Joined: May 2009
Posts: 1,805
J
Just Desserts Offline
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,805
Completely off-topic, but the topic's long enough as it is - how do I manually return data from an SMH_BANK handler?

Re: SVN builds - new driver flood [Re: Just Desserts] #55960 11/02/09 09:45 PM
Joined: Mar 2001
Posts: 16,305
R
R. Belmont Offline
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,305
Huh? I'm pretty sure asking that means you're doing something wrong. Explain smile

Re: SVN builds - new driver flood [Re: R. Belmont] #55961 11/02/09 09:49 PM
Joined: May 2009
Posts: 1,805
J
Just Desserts Offline
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,805
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 528 1 2 95 96 97 98 99 527 528

Who's Online Now
3 registered members (Vas Crabb, Heihachi_73, 1 invisible), 151 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,684
Posts114,041
Members4,863
Most Online510
Aug 26th, 2019
Powered by UBB.threads™ PHP Forum Software 7.7.3