Besides over-reddening Joust (though it seems to have gotten a little better), indytemp is another one.
Indy was difficult with the old rendering system, because there was some disparity between the intro 'level choose' screen and the mine, and the other screens. Mainly the bubbling pits and the mine walls, respectively, were very dim. Didn't matter what monitor I might be using, or at native resolution. A little contrast and brightness got it so the former were visible and the latter not very washed out.
Now it's impossible to get right. Without HLSL and brightness/contrast/gamma at default '1', the colors are pretty even, and everything on each screen is visible. Turn on HLSL, and it not only gets darker, but everything is redder, too, which makes it seems even darker.
This was on my (arguably a little worn) 22" CRT, but the same thing happens on my, bright as fuck and it ain't even as bright as it could get, 32" led-backlit LCD.
Perhaps regardless, the change from off to on is counter to past behavior.
HLSL does not change anything of the raw image unless you say so.
The settings in the raster.ini actually do change the color, yes. But these settings are not the default settings. The default settings are those in the mame.ini you create with the -cc option.
Given my lengthy and informative post, I don't see where complaint comes in. As to a solution, I don't see how I could offer one. I'll try again fresh with .180, though.
But, given the consistent-across-aeons issue with indytemp brightness between screens, there is likely something wrong with the driver.
> I think that HLSL is not a part of emulation and its only there as a makeup - completely unnecessary.
That's cute. Particularly given the conversation I started the other day and have been involved in with a female on a dating site whose pictures are all her wearing make-up, and I've told her exactly the same thing.
> HLSL does not change anything of the raw image unless you say so.
> The settings in the raster.ini actually do change the color, yes. But these settings are not the default settings. The default settings are those in the mame.ini you create with the -cc option.
I dunno. I have started from scratch. I'll try again.
> Given my lengthy and informative post, I don't see where complaint comes in. As to a > solution, I don't see how I could offer one. I'll try again fresh with .180, though. > > But, given the consistent-across-aeons issue with indytemp brightness between > screens, there is likely something wrong with the driver.
I want to point out. On my screen. The colors can be off because of the brightness and other settings isn't set right to where it can look wrong on MAME. Every screen that we buy isn't gonna look the same as the older ones. Same for the TV's. I'm sure that the arcade screens is the same way too.
> > Given my lengthy and informative post, I don't see where complaint comes in. As to > a > > solution, I don't see how I could offer one. I'll try again fresh with .180, > though. > > > > But, given the consistent-across-aeons issue with indytemp brightness between > > screens, there is likely something wrong with the driver. > > I want to point out. On my screen. The colors can be off because of the brightness > and other settings isn't set right to where it can look wrong on MAME. Every screen > that we buy isn't gonna look the same as the older ones. Same for the TV's. I'm sure > that the arcade screens is the same way too.
That's the culprit. Or, rather, the settings in it. Raster.ini is default in the baseline package - mame>ini>presets - and colors it weird. Get rid of that, and all's normal. Get about two or three times the performance, too. Below is the difference shown: with raster ini, and without, respectively. I dig the concept gone for in the former, but I think it's incorrect, and it dims it far worse.
(Something else I found in comparing baseline to MAMEUI: UI likes to put the mame.ini in the presets folder. Seems hard-coded, cos moving it back to ini and resetting dir ini back to ini has no affect, and UI puts another one in presets when closed, etc.)
I said it's the raster.ini, that changes the colors. What I didn't mention was, that all presets are included by default. Sorry, for the misunderstanding, but I thought it would be obvious by the default inipath setting .;ini;ini/presets.
I never saw this and many other games on a real CRT and the results also vary from CRT to CRT. But CRTs do not show the raw colors and I don't think the colors of the raster.ini are that bad compare to this example.
By the way, if you deactivated the bloom effect (bloom_scale at 0.0), the drastic performance gain you got is unsurprisingly, especially if you have an older graphics card.
> Because the raster.ini is wrong you've now learned something by playing with the > sliders. That's the idea
I got sick of messing with all those. I use the bgfx crt settings. Less to mess with. The colors are perfect. Only thing I mess with is the brightness and bloom. That it.
@B2K2K4: I didn't mess with the sliders; the place to mess with is the settings in the raster ini (or it must be removed, or?). I recall now in my similar-themed Joust thread a couple/few months ago how jezze talked about the raster ini settings, though I recall they didn't work for fixing Joust. Removing the ini has done that for it as well. Beauty.
( jezze ) > I said it's the raster.ini, that changes the colors. What I didn't mention was, that all presets are included by default. Sorry, for the misunderstanding, but I thought it would be obvious by the default inipath setting .;ini;ini/presets.
Looking back at your first response, I realize I just didn't register the first half of it, and I didn't really get the whole of it, instead thinking something else. I think because I had the intuition the raster ini wouldn't be read unless selected or something. I like the idea of preset (conceptions). I also think MAME is pretty accurate in basic color scheme and in most games I know and all. For example, Joust and Indy, of which I've recently seen in person.
In any case, that's an interesting CRT example of Indy. I think the monitor may've been old, combined with relative to the wear display settings. The image conception is pretty cool, too. The main thing for me is being able to see the details of each board - in particular the boiling pits in the intro screen, and the rock walls of the mine.
Here's a, rather old but still accurate-seeming to me, vid of Indy. Notice the shading of the mine walls, seeming to me to infer different shades from brown to black. The boiling pits are definitively brown, perhaps with spots, pixels dotted through the murk, of green. Like a boiling bog pit. This is how it looks with .104 and slight boosts to 1.15 of brightness and gamma. Pretty rich, a red-brown in fact, almost vibrant but for that outside of Windows my monitor is a little age-dimmmed. I'll try to get some external shots.
Hey Traso, I've brought this up before. The color changing matrix doesn't even change the colors in a way that makes sense for a CRT (look at some ramp test patterns). It seems like it's just not going to change though, unfortunately. Fortunately all you have to do is make the color matrix identity and you'll get MAME's standard (and generally accurate) colors.
Index 
Threaded 
I still say HLSL is coloring wrong.....
Reply
[Re: 
