settings to use in Mame with a VGA to CRT RGB connection

[churkus]

Hi,

Apologies if this has an answer already I couldnt see that.

So you have connected your VGA card to Scart TV and its working.

So in MAME, just what exactly do you have to choose for graphics settings.

I would think that most of the settings like Bilinear filtering, scanlines etc, should now be turned OFF, as they were used to emulate the CRT picture?.

So it will itself have natural bilinear filtering and scanlines as these is produced via the CRT tube?.

Thanks for your advice.

[rCadeGaming]

Churkus, do you mean you personally have connected your PC to your SCART TV and it's already working?  Have you already done something with the PC to enable low resolutions, like Soft15kHz, crtemudriver, ArcadeVGA etc?

The reason I ask is that if you have that's great, but if you haven't and it's already working on a normal desktop resolutions (640x480 progressive or more), the TV may not be suitable for 240p arcade stuff.

[churkus]

Hi rCade,

I should have clarified. I have indeed connected my PC to my Panasonic Scart TV succesfully using an ATI card and soft15khz and I get a good picture on the desktop. I am just wondering what settings I should or shouldnt have on in MAME, i.e vsync, triple buffering, hardware stretching, bilinear filtering etc. Should these be on or off when outputting to an "original" CRT display?. Oh and should i be using GDI, Directdraw or Direct3d?.

[rCadeGaming]

Ok, that's good.  Are you positive it's a 15kHz TV, meaning it will actually display 240p with real scanlines etc., without upscaling, etc.?  It sounds like it probably is, but just want to be sure.  What model is it?

Start reading the second thread in my signature, that should have all the answers you need, including MAME settings.  It's about using a US TV with a component input, but everything will apply to your case the exact same (provided you have a 15kHz TV), just ignore the part about the VGA to component transcoder, as you're able to connect the PC directly to the TV.

Please read that thread, as it should answer all of your questions so far.  Then post any additional questions about it there.

[ahofle]

Hi rCade,

I should have clarified. I have indeed connected my PC to my Panasonic Scart TV succesfully using an ATI card and soft15khz and I get a good picture on the desktop. I am just wondering what settings I should or shouldnt have on in MAME, i.e vsync, triple buffering, hardware stretching, bilinear filtering etc. Should these be on or off when outputting to an "original" CRT display?. Oh and should i be using GDI, Directdraw or Direct3d?.

You generally want hardware stretch off, video=directdraw, and switchres set to 1, then set the resolution to auto (assuming you have created a bunch of arcade resolutions with Soft15khz).  However, I recommend checking out Groovymame as it has some patches and works in conjunction to CRT Emu Driver that allows the games to run at the exact refresh rate and resolution, eliminating the need for things like vsync and triplebuffering.  It also contains a cleanstretch patch which lets you use direct3d without scaling.  I believe there is a thread in there about settings for a SCART TV too.

[rCadeGaming]

GroovyMAME is not necessary to run at the exact native res and refresh rate.  This can be done perfectly in vanilla MAME.  Yes, you use DirectDraw, but if you're going to mention specifics, then you need to mention that properly setting things up with syncrefresh is what eliminates the need for waitvsync and triplebuffering.  Yes, switchres should be on, but for best resolutions you need to tweak your resolutions and select them specifically.  Just setting resolution to auto will not produce the best results.

That thread I linked to has all the info on these settings, and how to adjust for proper refresh, and how to fix your geometry from the PC end.

The problem with GroovyMAME is that it uses automatically generated timing values, which works well sometimes but not others:

That's great, but does it have to use an automatically calculated timing value?  I prefer to adjust all the timing values myself in Powerstrip, so I can have both a correct refresh rate and the precise geometry that I want.  I do this starting with test patterns, and then adjust it for practical things in the game itself, like overscan cutting off health bars, highscore, etc. 

For example, could I tell GroovyMAME the exact timing values to use with 320x240 when it loads up a neogeo.c game?

That's not possible yet I'm afraid, the whole idea was to do everything automatically. But adding raw modeline support is something I wanted to have indeed, and it's not in this version just because I run out of time.

The main idea with GM is to give it the information (crt_range options) so it will create modelines that are perfectly centered, without the need of further tweaking. So your efforts are focused on finding these accurate timing specs that result in correct geometry, instead of manually adjusting hundreds of modes. Once you get this working, you never want to go back to the paleomethod.

However, the problem is, that's the theory. In the real world you find situations where creating general timing specs doesn't work so well, for instance with TVs that internally readjust their geometry (Sony, etc.). So for these cases, it would be nice to also accept a precalculated modeline. This way you have the best of both worlds.

Precalculated timing values could range from working very well, to having geometry that's not quite what you want.

However, in my conversation with Calamity there, I was asking if we'll be to use our own modelines (resolution setting as adjusted in the thread I linked to), and he says that it should be implemented in the next release:

http://forum.arcadecontrols.com/index.php/topic,128879.msg1318540.html#msg1318540

Once this happens, using GroovyMAME will be a no brainer.  Among many other advantages, you'll be able to use the automatic resolutions where they do work, and step in and correct things manually when they don't.

[ahofle]

I'm not sure what geometry problems you're having but the vast majority of games I've tried work perfectly with no screen tearing.  Perhaps your issues are due to the fact that you are using a TV without RGB input as Calamity stated?  The OP is using an RGB input (SCART).  I never said Groovymame was required, however 99.99% of people don't want to waste dozens of hours tweaking modelines and rebooting over and over again -- they just want the native resolutions to be calculated automatically.  Hence, resolution = auto works just fine. 

[Calamity]

Precalculated timing values could range from working very well, to having bad geometry, to not working at all.

No, no, no, that's not exact. 

I hate to say this, but GM/VMMaker's modeline generation is first class. It will always generate a *working* modeline with the right timings (i.e. geometry) to your specs.

What I meant is that most relatively modern SCART TVs have internal mechanisms to auto-adjust the geometry settings depending on the incoming signal, probably meant to deal with the different broadcast standards PAL/NTSC, etc. This results in a geometry that's way different to the theorical one (=if the TV didn't apply any adjustment). Usually, it's just a matter of entering the service menu and do a bit of tweaking to get things perfect, which is certainly an annoyance.  It's only for these TVs where it becomes handy to manually tweak your modelines, in order to compensate for the adjustments that the TV applies on its own.

On the other hand, most arcade monitors are "passive" on this regard, so they just show the signal without any adjustments (= the adjustments are static, and you tweak them via potentiometers). For these CRTs you can expect an absolutely deterministic behaviour with automatically generated modelines.

Finally, on the software side, you need a reliable method to achieve the desired pixel clock on your video card. ATI drivers are way more reliable than Powerstrip on this regard.

[rCadeGaming]

I'm not sure what geometry problems you're having but the vast majority of games I've tried work perfectly with no screen tearing.

Not sure what you're getting at here; when did I say anything about screen tearing?

Whether it's syncrefresh or waitvsync or triplebuffer, all three can cure screen tearing.  However, properly settings things up with syncrefresh is the way to do it while running at the original game speed without skipping frames or adding lag.

Perhaps your issues are due to the fact that you are using a TV without RGB input as Calamity stated?  The OP is using an RGB input (SCART).

RGB transcoded to component vs. straight RGB should not make a difference with what we're talking about.  Probably the only thing that would make a difference between our TV's is the auto geometry adjustment he describes.

99.99% of people don't want to waste dozens of hours tweaking modelines and rebooting over and over again

What rebooting?  Tweaking in Powerstrip is in real time.  Once you know what you're doing you can set up a game in five minutes.  Also, you don't usually need to adjust individual games unless you want to; it's usually on a hardware driver basis.

-

GM/VMMaker's modeline generation is first class. It will always generate a *working* modeline with the right timings (i.e. geometry) to your specs.

Correct me if I'm wrong, but isn't this only true if you have precisely setup your monitor parameters with GM?  I imagine this takes a good deal of tweaking if you're not using something with an available preset, which could be the case with these TV's.

Anyhow, if I'm wrong about precalculated timing values not possibly not syncing, I won't argue on this one.  I apologize for any misinformation and I'll correct my post.

Geometry that's not what you might want is totally possible though.  Even if the active pixels are perfectly centered, that doesn't necessarily mean it's the best position for a specific game if you have some overscan.  You might need to shift things a bit to give priority to being able to see important info like health bars and high score display and such.  This is like my R-Type example.

What I meant is that most relatively modern SCART TVs have internal mechanisms to auto-adjust the geometry settings depending on the incoming signal, probably meant to deal with the different broadcast standards PAL/NTSC, etc. This results in a geometry that's way different to the theorical one (=if the TV didn't apply any adjustment). Usually, it's just a matter of entering the service menu and do a bit of tweaking to get things perfect, which is certainly an annoyance.  It's only for these TVs where it becomes handy to manually tweak your modelines, in order to compensate for the adjustments that the TV applies on its own.

On the other hand, most arcade monitors are "passive" on this regard, so they just show the signal without any adjustments (= the adjustments are static, and you tweak them via potentiometers). For these CRTs you can expect an absolutely deterministic behaviour with automatically generated modelines.

My TV doesn't seem to have this problem.  In the US, any analog broadcast was held extremely strictly to the 262 and a half line per field NTSC standard timing values.

Makes perfect sense why European TV's would need this though.  Definitely something for the OP to watch out for.  I wonder if this could be disabled.  He hasn't said what model his set is, or if he can get into a digital service menu. 

Still there Churkus?

Finally, on the software side, you need a reliable method to achieve the desired pixel clock on your video card. ATI drivers are way more reliable than Powerstrip on this regard.

I haven't had much problem with this yet, but as I said I won't hesitate to swap my Geforce for an ATI if I run into any limitations.

-

I don't want anyone to think I'm saying anything bad about GroovyMAME.  I'm looking forward to using it very much.

using GroovyMAME will be a no brainer.  Among many other advantages, you'll be able to use the automatic resolutions where they do work, and step in and correct things manually when they don't.