GroovyMAME 0.171 - SwitchRes v0.015m

[Sledge]

Yep, Same result as me.

Calamity, i just had another look, and the video modes chosen between the 2 versions change..
Maybe that's got something to do with asteroids looking so bad?

[sean_sk]

Did you get my PM in regards to an issue I'm having with triple buffering causing missing polygons and textures in Ridge Racer and Rave Racer and all vector games being very dark?

Hi sean_skroht, yes I saw your message. Although I'm not seeing it here, I'd say it's caused by the multithreading associated to triple buffering causing graphic glitches. You may try enabling -video d3d for these particular games, keeping triple buffering on (multithreading) so it will bypass the half frequency issue when using d3d. If this doesn't help, I guess there's nothing we can do about it.

Thank you for your suggestions. I was able to fix the issue by forcing -video d3d in Hyperspin paramaters for all games. Thanks for that mate.

[Calamity]

Thank you for your suggestions. I was able to fix the issue by forcing -video d3d in Hyperspin paramaters for all games. Thanks for that mate.

I'm afraid that's an error my friend. Forcing -video d3d in the command line just overrides the fix that's been implemented right for you. You'll get 50% speed in any other game that is running with an interlaced mode and without triple buffering enabled.

The -video setting in mame.ini is not being ignored. It's just that now when the specific conditions are met (W7 & interlaced mode) direct draw is selected regardless the default setting that's specified in mame.ini. As with any of the automatic options set by SwitchRes, this is only a step of priority above mame.ini, but below any other .ini file or command line. So you can always force any setting by creating a game.ini, or driver.ini, or even horizont.ini or whatever.

[Calamity]

Calamity, i just had another look, and the video modes chosen between the 2 versions change..
Maybe that's got something to do with asteroids looking so bad?

Hi Sledge,

A different mode is picked because starting with v0.153 Asteroids is reported as having refresh of 61.xx. If you want GM to pick the old mode just let in know that the resulting frequency is acceptable:

crt_range0 15450.00-16250.00,50.00-65.00,3.910,4.700,6.850,0.190,0.191,1.018,0,0,192,288,448,576

Vector games look different probably because now DirectDraw is used insted D3D. Use the specific vector options to increase the beam width, brightness etc.

[Calamity]

Things improved a lot, BTW there are some strange behaviours that I can't explain:

Hi Haggar,

A couple of notes:

- Comparing 0.149 vs 0.153 is cheating because with 0.149 you have modeline generation enabled, so obviously the target refresh is achieved. If you enable modeline generation for 0.153 you'll get the exact same refresh... just forgot to mention this the other day

- It's very strange that GM runs snowbros at 104% when the it's actually picking a 57 Hz modeline. I'd suggest to repeat the test right after a fresh reboot without running any other version of GM before. I'll try to reproduce the problem here anyway.

[Haggar]

Hi Haggar,

A couple of notes:

- Comparing 0.149 vs 0.153 is cheating because with 0.149 you have modeline generation enabled, so obviously the target refresh is achieved. If you enable modeline generation for 0.153 you'll get the exact same refresh... just forgot to mention this the other day

Ah, ok sry for that.

- It's very strange that GM runs snowbros at 104% when the it's actually picking a 57 Hz modeline. I'd suggest to repeat the test right after a fresh reboot without running any other version of GM before. I'll try to reproduce the problem here anyway.

Ok, I'll try.
Thanks

[cools]

horizont.ini or whatever.

Is there a list somewhere of all the possible .ini files? I've been wondering for a while what the horizontal one was.

[Calamity]

Is there a list somewhere of all the possible .ini files? I've been wondering for a while what the horizontal one was.

You can check the code in emu_options::parse_standard_inis here: http://git.redump.net/mame/tree/src/emu/emuopts.c

 

[adder]

...starting with v0.153 Asteroids is reported as having refresh of 61.xx

cool im glad thats been officially changed now as asteroids doesnt run smooth otherwise
http://www.mameworld.info/ubbthreads/showflat.php?Number=2819540

[Haggar]

Hi Haggar,

A couple of notes:

- Comparing 0.149 vs 0.153 is cheating because with 0.149 you have modeline generation enabled, so obviously the target refresh is achieved. If you enable modeline generation for 0.153 you'll get the exact same refresh... just forgot to mention this the other day

Ah, ok sry for that.

- It's very strange that GM runs snowbros at 104% when the it's actually picking a 57 Hz modeline. I'd suggest to repeat the test right after a fresh reboot without running any other version of GM before. I'll try to reproduce the problem here anyway.

Ok, I'll try.
Thanks

Tried, but the problem remains.
I've also tried turning on modeline generation:

Code: [Select]

E:\EMULATORI\MAME>groovymame32_0153.015b.exe butasan

SwitchRes: [butasan] (1) horizontal (256x240@54.00)->(256x240@54.00)
Average speed: 110.92% (9 seconds)

E:\EMULATORI\MAME>groovymame32_0153.015a.exe butasan

SwitchRes: [butasan] (1) horizontal (256x240@54.00)->(256x240@54.00)
Average speed: 100.01% (6 seconds)

Log attached

[cools]

Is there a list somewhere of all the possible .ini files? I've been wondering for a while what the horizontal one was.

You can check the code in emu_options::parse_standard_inis here: http://git.redump.net/mame/tree/src/emu/emuopts.c

Oh, its actually mame source? Thanks, useful info

As an on topic aside, I've seen similar weirdness as Haggar has with games not seeming to throttle properly with 153 15a and 15b. I've not had any time to do some diagnostics on it though so can't offer anything more than a me too.

[ozfalcon]

- It's very strange that GM runs snowbros at 104% when the it's actually picking a 57 Hz modeline. I'd suggest to repeat the test right after a fresh reboot without running any other version of GM before. I'll try to reproduce the problem here anyway.

Ok, I'll try.
Thanks

When I run snowbros @ 60hz I get Average speed: 104.38%
So It sounds like it may be picking it, But not switching to it?

<Modified: Removed redundant info>

[Haggar]

- It's very strange that GM runs snowbros at 104% when the it's actually picking a 57 Hz modeline. I'd suggest to repeat the test right after a fresh reboot without running any other version of GM before. I'll try to reproduce the problem here anyway.

Ok, I'll try.
Thanks

When I run snowbros @ 60hz I get Average speed: 104.38%
So It sounds like it may be picking it, But not switching to it?

I've tried changing refresh rates through mame sliders controls. Forcing games with this issue at 60Hz they all run at 100%.

[Calamity]

I've tried changing refresh rates through mame sliders controls. Forcing games with this issue at 60Hz they all run at 100%.

I spotted the problem last night, indeed it's caused by a change I introduced in the DirectDraw part. I'll have a fix today.

[Haggar]

Great! 

One quick question before updating my romset: I've read in the past that the triple buffer option is managed automatically by GM.
I know that this option introduces massive lags to controls, is there a way to force it off and be sure that it will not be activated?

[Sledge]

Calamity, i just had another look, and the video modes chosen between the 2 versions change..
Maybe that's got something to do with asteroids looking so bad?

Hi Sledge,

A different mode is picked because starting with v0.153 Asteroids is reported as having refresh of 61.xx. If you want GM to pick the old mode just let in know that the resulting frequency is acceptable:

crt_range0 15450.00-16250.00,50.00-65.00,3.910,4.700,6.850,0.190,0.191,1.018,0,0,192,288,448,576

Vector games look different probably because now DirectDraw is used insted D3D. Use the specific vector options to increase the beam width, brightness etc.

there's no brightness setting for Vector games?
under CORE options i've got:
antialias
beam
flicker

putting brightness 1.2 or 1.1 (under Core vector options) does make the screen brighter (and blurred)... but we just need the vector lines to be brighter rather than the whole screen?

[Calamity]

putting brightness 1.2 or 1.1 (under Core vector options) does make the screen brighter... but we just need the vector lines to be brighter rather than the whole screen?

Use the beam option.

http://forum.arcadecontrols.com/index.php/topic,118159.msg1254032.html#msg1254032

[Sledge]

putting brightness 1.2 or 1.1 (under Core vector options) does make the screen brighter... but we just need the vector lines to be brighter rather than the whole screen?

Use the beam option.

http://forum.arcadecontrols.com/index.php/topic,118159.msg1254032.html#msg1254032

yeah that does help a fair bit
Thanks !

[Calamity]

One quick question before updating my romset: I've read in the past that the triple buffer option is managed automatically by GM.
I know that this option introduces massive lags to controls, is there a way to force it off and be sure that it will not be activated?

You can control exactly when -triplebuffer is going to be used by means of the -syncrefresh_tolerance option. This option is set to 2.0 Hz by default. It means that when the difference between the native game's refresh and the modeline is higher than 2.0, -triplebuffer will be used instead of -syncrefresh, in order to keep the game speed deviation in a reasonable range. Of course you can increse the -syncrefresh_tolerance value as much as you like, e.g. if you set it to 10.0 Hz it probably won't use -triplebuffer in any situation. Of course there is a catch: games like galaga will run very slow on a horizontal arcade monitor.

That said, don't be too scared about triple buffering: the main source of input lag associated to triple buffering in the popular culture just does not happen with GroovyMAME. This is because we set things so that the frame queue arranged by DirectX is bypassed.

The obvious problem with triple buffering is the unavoidable loss of 1:1 frame mapping that leads to choppy scrolling. That's why it's just a last resource setting rather than a desirable feature.

Finally, for -triplebuffer to work in the intended way you need to have -multithreading enabled too.

[Haggar]

Thanks.
Can you provide a list of reccomended settings to get less lag as possible (mantaining v-sync on of course)?

[Calamity]

Thanks.
Can you provide a list of reccomended settings to get less lag as possible (mantaining v-sync on of course)?

Check this: http://forum.arcadecontrols.com/index.php/topic,133194.msg1377633.html#msg1377633
In the attached picture, you'll see the settings I was using.

[Calamity]

The fix for 015b is ready: https://drive.google.com/#folders/0B5iMjDor3P__NTRMamY2Q0xjSFk

[Haggar]

Thanks!!

Thanks.
Can you provide a list of reccomended settings to get less lag as possible (mantaining v-sync on of course)?

Check this: http://forum.arcadecontrols.com/index.php/topic,133194.msg1377633.html#msg1377633
In the attached picture, you'll see the settings I was using.

So it's better using d3d instead of ddraw.

[Calamity]

So it's better using d3d instead of ddraw.

With -frame_delay enabled (any value above 0), d3d = ddraw
Without -frame_delay, d3d lags 2 frames more than ddraw.

[Haggar]

Thanks Calamity.
I've tried your new release, problems gone!! 

[cools]

Is it normal that the font rendering when "orientation vertical" is set does the attached?

I've tried with multiple games and fonts, including the fallback font as pictured - all the same unusable scale.

[Sledge]

How do the Cave games run for people in GM 153?
IE: Muchi Muchi Pork for me runs like a dogs breakfast... speed is all over the place even going down to about 54% at times..

[Ansa89]

For what I heard, cave sh3 games are very cpu-hungry, so it could be related to your hardware configuration.

[Calamity]

Is it normal that the font rendering when "orientation vertical" is set does the attached?

I've tried with multiple games and fonts, including the fallback font as pictured - all the same unusable scale.

Well that's not normal, or at least desirable. Please post a log, so I can use it to clone your system here and see why that happens.

I have a pending task regarding some aspect ratio & fonts issues, specially affecting SDL and -cleanstretch 2, which hopefully will get fixed soon, and probably looking inside this will help with with related problems like this one and the other one you posted.

[Sledge]

For what I heard, cave sh3 games are very cpu-hungry, so it could be related to your hardware configuration.

Yeah i just OC'd from 3.16Ghz to 3.8Ghz, and it went from a minimum of 52% to a minimum of 72% (demo play)
strange thing though.... if i press F10 to unthrottle mmpork.... it doesn't drop below 100%.. not even close, maybe 120% minimum

I can't actually get a credit in as it gives a COIN ERROR lol..

[Calamity]

Have you tried the blitter delay thing?
http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Board=mamechat&Number=324467&Forum=All_Forums&Words=Tafoid&Match=Username&Searchpage=0&Limit=25&Old=allposts&Main=324445&Search=true#Post324467

[cools]

Is it normal that the font rendering when "orientation vertical" is set does the attached?

I've tried with multiple games and fonts, including the fallback font as pictured - all the same unusable scale.

Well that's not normal, or at least desirable. Please post a log, so I can use it to clone your system here and see why that happens.

I've tried on different systems as well.

I'll grab a log of one of them shortly, along with the ini.

[cools]

Attached. Also tried "orientation rotate" and same issue.

Doesn't happen on galaga88, if that helps.

MAME.INI renamed to allow for upload.

[cools]

(cleanstretch 2 also breaks vector games really well  )

[Calamity]

(cleanstretch 2 also breaks vector games really well  )

Yes, I've seen very weird things with vector games lately. Have you tried it with -video ddraw?

BTW, the log correspoding with your picture would be the one I need.

[cools]

Right, hangon - I'll take a picture, the ini, and the log of it.

[Calamity]

Right, hangon - I'll take a picture, the ini, and the log of it.

I mean the one of the picture above http://forum.arcadecontrols.com/index.php/topic,135823.msg1437969.html#msg1437969

[cools]

I can't get you the log of that, it's in the past. I can reproduce the issue as much as you like though though with new picture(s) and associated logs.

All attached.

[cools]

Yes, I've seen very weird things with vector games lately. Have you tried it with -video ddraw?

Even more broken, just gives masses of "DirectDraw: Error 88760096 blitting to the screen" errors in the log.

[cools]

I have a pending task regarding some aspect ratio & fonts issues, specially affecting SDL and -cleanstretch 2, which hopefully will get fixed soon, and probably looking inside this will help with with related problems like this one and the other one you posted.

Cool. Definitely some weird behaviour. Don't really want to pepper you with logs, but another one I just spotted. If I change the ini I posted to "orientation horizontal" then galaga88 and invaders appear rotated vertically on the screen but fractionally stretched (filtered). ket is integer stretched. If I subsequently pass "-norotate" to galaga88, it appears in its natural orientation but it's running at 200%.